Applications like games change desktop resolution (graphics mode) for their needs. Unfortunately when such applications crash then X.org server doesn't revert the resolution back to its initial mode.
It's a bug.
Please, consult with thus Wine bug for details: http://bugs.winehq.org/show_bug.cgi?id=10115
From my reading of the Wine bug report it doesn't seem clear if this is something which should be handled in the X server, or elsewhere like in the window manager.
Maybe you can bring this up on the xorg mailing list instead? See
I suppose this bug could be easily solved by keeping the log of applications which change desktop resolution and if any of them exits abnormally then desktop resolution should be changed to the previous active mode.
However it seems like no one is interested in Linux as a viable gaming platform, so I'm closing this bug.
I'm gonna reopen this, it's a bug that needs fixing. Where it needs fixing is the real issue...
Let me summarize the problem. Games regularly change the screen resolution, xrandr does this and it works, there are two issues though:
1. ALT+TAB away from the window doesn't restore the default resolution unless the application explicitly does it.
2. If the application crashes the user is left at a bad resolution.
MS Windows has a concept of a temporary resolution change. If a game crashes, and it marked the resolution change as temporary, the default resolution is restored. We really should have this behaviour, we cannot rely on an application to restore the resolution in a crash.
I started a discussion on the xorg-devel list over a year ago but it stagnated: http://email@example.com/msg00832.html
So, here are the questions. Is this something xrandr could implement? If not is it the window manager's job? If it *is* the window manager's job, how do we go about implementing this in a Freedesktop wm-spec so the window managers implement it across the board?
More than 2,5 years in making/thinking/or anything at all(?), well, one can conclude Linux and Open Source based OS'es are not for playing games.
That has nothing to do with gaming, even if games most often expose this behavior. If any application is dealing with unique ressources like the screen configuration, it should not be trusted in its behavior, like it is not trusted in its memory recycling. If a program quits, the kernel ensures it's memory is freed. So should X care about screen settings.
The only exception would be explicit screen setting tools that still must be able to change the resolution permanently.
This bug should be closed. X11 is not a platform for fullscreen applications that set their own resolution (like video games.) Please use Microsoft Windows for this kind of stuff.
The discussion linked to from comment #3 certainly suggests that this is in scope for x11/randr.
(In reply to comment #6)
> This bug should be closed. X11 is not a platform for fullscreen applications
> that set their own resolution (like video games.) Please use Microsoft Windows
> for this kind of stuff.
What are you on about?
He writes brilliant "interactive fiction". Or so he thinks :) But nobody wants to play what he makes. He blames the ubiquity of OpenGL. And struggles to spoil if for others. Jealous and selfish.
(In reply to comment #9)
> He writes brilliant "interactive fiction". Or so he thinks :) But nobody wants
> to play what he makes. He blames the ubiquity of OpenGL. And struggles to spoil
> if for others. Jealous and selfish.
My comment was perhaps a poor attempt at sarcasm. The point was to hopefully make at least one X.Org dev get interested in coming up with a solution to this very annoying problem.
(Btw, I don't write Interactive Fiction. I write software tools for it that run natively in Linux in order to avoid having to run the Windows ones in Wine.)
I'd like to add that this feature is also a must if you Alt-Tab applications, but I guess it's to early to request it to be implemented since this bug is only 4,5 years of age - it's not yet vintage.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.