X.org server should keep track of and restore its initial (desktop) resolution and refresh rate
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Wine |
Won't Fix
|
Wishlist
|
|||
X.Org X server |
Unknown
|
High
|
|||
xorg-server (Ubuntu) |
Triaged
|
Medium
|
Unassigned |
Bug Description
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#2 |
You need to file this feature request in the bugzilla of WM of your choice.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#3 |
Closing.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#4 |
(In reply to comment #2)
> You need to file this feature request in the bugzilla of WM of your choice.
Well it's not a matter of WM (for instance GNOME), nor of X server. I made a test (with Savage) and I can switch between my game in 1024x768 and my desktop in 1280x800, there is no problem !! Of course, when I switch to my desktop the game is not visible, just like windows !
This feature is called (I believe) "dynamic resolution changing", and as windows support it, Wine should support it. So I reopen this bug.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#5 |
(In reply to comment #4)
> (In reply to comment #2)
> > You need to file this feature request in the bugzilla of WM of your choice.
I believe he is referring to switching from a windowed virtual desktop, to a full screen virtual desktop.
>
> Well it's not a matter of WM (for instance GNOME), nor of X server. I made a
> test (with Savage) and I can switch between my game in 1024x768 and my desktop
> in 1280x800, there is no problem !! Of course, when I switch to my desktop the
> game is not visible, just like windows !
>
> This feature is called (I believe) "dynamic resolution changing", and as
> windows support it, Wine should support it. So I reopen this bug.
>
How does windows support this? I think you're confused. Windows has nothing like "virtual desktop". It's up to an app to determine how it is full screen or windowed. So if you are filing this bug based on dynamic resolution changing, wine supports it already like windows does.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#6 |
(In reply to comment #5)
> I believe he is referring to switching from a windowed virtual desktop, to a
> full screen virtual desktop.
No, I do NOT talk about virtual desktop. This bug is not related to this one :
http://
I talk about the fact that when I switch between an application in fullscreen run by Wine and my desktop, Wine force my desktop to the resolution of the application in fullscreen. As I made a tested with Savage, it's not a problem of Gnome or X.
> How does windows support this? I think you're confused. Windows has nothing
> like "virtual desktop". It's up to an app to determine how it is full screen or
> windowed. So if you are filing this bug based on dynamic resolution changing,
> wine supports it already like windows does.
Maybe I'm confused, maybe "dynamic resolution changing" refers to something else that I do not understand. But I have a pretty clear idea of what I request : I do not want Wine to force my desktop to have the resolution of a fullscreen application that is running through Wine.
Windows do not force its desktop to have the resolution of a fullscreen application. I can have my desktop in 1280x800 and run a game in 800x600, and if I switch between the both, each one have its own resolution. Of course if the game crashes, the desktop looses its resolution and you will have to restore it (which is an annoying problem, but still less annoying than having to deal with a desktop in 800x600 when a game is running through Wine).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#7 |
If the program does not restore display resolution when it's loosing focus, then Wine should do that (of course depends on the coop mode for ddraw, and fullscreen mode for d3d). Unless Wine doesn't tell program that they lost device (the d3d DEVICE_LOST).
Wine's x11drv indeed supports dynamic resolution changes. But something needs to ask to do so.
So do not mention virtual desktop - it's irrelevant here. This is about full screen mode only. And _ONLY_ if you have "managed" checked in winecfg (default configuration).
So Sébastien Bertrand <email address hidden> what is the program are you talking about? Is it using OpenGL/DDraw/D3D? What Wine version? What OS?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#8 |
Vitaliy, this is a rehash of bug 10839. He wants to run warcraft III (probably using opengl) without changing his wide-screen desktop resolution. The game does not officially support wide-screen and has to set a 4:3 resolution. He can get around this by hacking the registry entry for the game which I suggested to him earlier.
Anyway, wine DOES have to set your desktop to the resolution of the game while in the game. You can't get around this.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#9 |
(In reply to comment #7)
> If the program does not restore display resolution when it's loosing focus,
> then Wine should do that (of course depends on the coop mode for ddraw, and
> fullscreen mode for d3d). Unless Wine doesn't tell program that they lost
> device (the d3d DEVICE_LOST).
>
> Wine's x11drv indeed supports dynamic resolution changes. But something needs
> to ask to do so.
>
> So do not mention virtual desktop - it's irrelevant here.
I assume that I've been very unclear. I apologize for that. Your summary is far better.
> This is about full
> screen mode only. And _ONLY_ if you have "managed" checked in winecfg (default
> configuration).
That's ok, it's what I'm talking about.
> So Sébastien Bertrand <email address hidden> what is the program are you
> talking about? Is it using OpenGL/DDraw/D3D? What Wine version? What OS?
So I mainly use Wine for games. This problem appears with the following games (I'm not sure but I think it's OpenGL games) :
* Steam Games (Half Life, Day of Defeat, Team Fortress Classic)
* Warcraft III and his extension Frozen Throne
* World of Warcraft
Wine version : wine-0.9.51
OS : GNU/Linux (Ubuntu 7.10)
When I switch from the game to the desktop, it seems firstly that the desktop tries to restore its own resolution, but then, after many modification of the resolution (2 or 3), the desktop adopt the resolution of the game. It seems that there is also some differences between "wine Warcraft\ III.exe -opengl" and "wine Warcraft\ III.exe" commands, because with the second command, Warcraft III do not accept to lose focus, unless you switch to another "GNOME virtual desktop" (this time I'm speaking about GNOME virtual desktop, Wine have nothing to do with it). With the -opengl parameter, Warcraft III accept to lose focus inside a GNOME virtual desktop. In both case, the resolution of the desktop is the resolution of the game.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#10 |
> Anyway, wine DOES have to set your desktop to the resolution of the game while
> in the game. You can't get around this.
Well, but :
"Wine does not restore display resolution when it's looses focus"
Sorry, I've been very unclear. Especially because of what I expressed in the bug 10839. This summary is far better than everything I wrote to explain my problem.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#11 |
(In reply to comment #6)
> I talk about the fact that when I switch between an application in fullscreen
> run by Wine and my desktop, Wine force my desktop to the resolution of the
> application in fullscreen. As I made a tested with Savage, it's not a problem
> of Gnome or X.
Must be Savage is doing extra work to compensate for the X11/WM deficiency
of managing windows running in different resolution modes. Wine is not
a Window Manager of any kind, in order to properly fix this problem the fix
should be made on the X11/WM/OS side instead. You forget that OS *already*
manages switching display modes between X11 and text consoles, the same
thing should be done for X11 processes.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#12 |
(In reply to comment #11)
> (In reply to comment #6)
>
> > I talk about the fact that when I switch between an application in fullscreen
> > run by Wine and my desktop, Wine force my desktop to the resolution of the
> > application in fullscreen. As I made a tested with Savage, it's not a problem
> > of Gnome or X.
>
> Must be Savage is doing extra work to compensate for the X11/WM deficiency
> of managing windows running in different resolution modes. Wine is not
> a Window Manager of any kind, in order to properly fix this problem the fix
> should be made on the X11/WM/OS side instead. You forget that OS *already*
> manages switching display modes between X11 and text consoles, the same
> thing should be done for X11 processes.
Well, I do not think so, because when I launch Warcraft III in fullscreen, and switch to my desktop, firstly the desktop tries to restore its own resolution and then it switches to the resolution of the game. I assume that Wine forces the desktop to the resolution of the game. In fact there is a sort of "flash" in 1280x768 and the resolution of the desktop becomes 1024x768.
Nothing like this happens with Savage. I will try to find some open source Windows game to track this bug down.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#13 |
(In reply to comment #12)
> Well, I do not think so, because when I launch Warcraft III in fullscreen, and
> switch to my desktop, firstly the desktop tries to restore its own resolution
> and then it switches to the resolution of the game.
That's exactly the kind of the bug imposed by a WM.
> I assume that Wine forces
> the desktop to the resolution of the game. In fact there is a sort of "flash"
> in 1280x768 and the resolution of the desktop becomes 1024x768.
Wine doesn't "force" the resolution change, and couldn't do that. Wine
just uses public X11 APIs to switch the resolution on behalf of the Windows
application it runs.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#14 |
(In reply to comment #13)
> (In reply to comment #12)
>
> That's exactly the kind of the bug imposed by a WM.
>
> Wine doesn't "force" the resolution change, and couldn't do that. Wine
> just uses public X11 APIs to switch the resolution on behalf of the Windows
> application it runs.
Okay. You must have more experience than me on that subject, because I have none. We have to be sure, so I will do some test with others WM (KDE, …). If it's a problem with X, I do not know how to be sure…
Every tests I do will be reported here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#15 |
(In reply to comment #14)
> (In reply to comment #13)
> > (In reply to comment #12)
> >
> > That's exactly the kind of the bug imposed by a WM.
> >
> > Wine doesn't "force" the resolution change, and couldn't do that. Wine
> > just uses public X11 APIs to switch the resolution on behalf of the Windows
> > application it runs.
>
> Okay. You must have more experience than me on that subject, because I have
> none. We have to be sure, so I will do some test with others WM (KDE, …). If
> it's a problem with X, I do not know how to be sure…
>
> Every tests I do will be reported here.
I tested Warcraft III with KDE, IceWM and XFCE (and initially GNOME) : each times, this bug happens. So I think it's pretty sure it's not a WM bug. Why this could not be a bug of Wine ?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#16 |
(In reply to comment #15)
> I tested Warcraft III with KDE, IceWM and XFCE (and initially GNOME) : each
> times, this bug happens. So I think it's pretty sure it's not a WM bug.
Pretty much strange conclusion. To me it looks like that according to your
test none of the WMs above support X11 processes running in different screen
modes.
> Why
> this could not be a bug of Wine ?
Due to the reasons already explained in this bug.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#17 |
Dmitry, it might be a WM bug, but nothing stops us from putting a workaround in Wine related to resolution changes. Since all WMs behave the same.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#18 |
*** Bug 3230 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#19 |
*** This bug has been confirmed by popular vote. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#20 |
According to comment in 3230:
"alt-tab is caught by the window manager and it doesnt know that we switched
the resolution. :/ "
Which would make it tricky for us to solve. We probably should fix this in the window managers.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#21 |
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://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#22 |
I too am affected by this bug and find it quite annoying since it destroys the current desktop layout, especially with my two-monitor setup. Just some ideas/suggestions:
I find the way dosbox (http://
. You can switch between fullscreen and windowed modes by hitting <M-Ret>.
. In fullscreen mode, you cannot <M-Tab> out, it seems to circumvent the window manager. BTW: Many games don't allow you to <M-Tab> out in Windows too.
. Fullscreen mode resolution does not affect desktop resolution in any way. It is restored when switching between the modes and after exiting dosbox.
. In windowed mode, <M-Tab> works as expected.
Native linux games work in a similar way (powermanga, neverball, frozenbubble) and do not mess up your workspace. This seems to be pretty standard with most games I've tried so far.
Wine behaves different: It seems it does not provide a real fullscreen mode like native linux games or dosbox. If the wine application crashes, resolution is not restored. But worst: If it ends normally, it does not restore the resolution too. Additionally, if you <M-Tab> out to another application, often the wine window is not restored correctly if you want to switch back to it, though this might be a window-manager related bug.
The current way to deal/workaround with these problems are:
1. Use xrandr to remember and restore the resolution (aka wrapping wine in a script). Sometimes, this still messes up the workspace (e.g. I have to restart conky etc.).
2. Start a separate xserver which you can VT-switch to. I have not tried this yet, however, this certainly would prevent wine messing up your current workspace layout. I guess this would be quite complicated to set up for most users, and dealing with your X configuration is a delicate thing especially when it has been quite a hassle to set up.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#23 |
This bug appears since i use wine (about 2 years now).
Espacially if a game crashes, which is in "fullscreenmode" with a different resolution as the desktop, wine does not restore the resolution of the desktop.
(If gnome normally has a resolution of 1280x1024, the game 640x480 and the game crashes - the resoultion is still 640x480, so i have to restart gnome or change the resolution manually.
This is still a ugly bug and should be fixed soon. If this isn't caused by wine then this should reported to the x-server, gnome or kde developers. This bug is in my oppinion 1.0 critical !
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#24 |
Support for this being 1.0 crit.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#25 |
Pretty late to nominate for 1.0, but let's target for 1.2
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#26 |
Probably calling ChangeDisplaySe
on DLL_PROCESS_DETACH in user32 would do the trick, but it's not clear
if that's the right thing to do, especially if an exiting process is not
the one who has changed the resolution, or the resolution has been changed
on behalf of other process.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#27 |
Also, when you exit a full screen app (not just switch from it to the desktop), the resolution still isn't changed back.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#28 |
(In reply to comment #26)
> Also, when you exit a full screen app (not just switch from it to the desktop),
> the resolution still isn't changed back.
It would be helpful to at least name that app, Wine version tested, and
whether a demo of it is available.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#29 |
It seems to happen to all apps that go fullscreen (such as games). I'm using Wine 1.0-rc2.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#30 |
(In reply to comment #28)
> It seems to happen to all apps that go fullscreen (such as games). I'm using
> Wine 1.0-rc2.
Have a look at the bug 10929 for a possible reason.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#31 |
So you need wine-tools to fix it? Why can't regular wine be able to switch the resolution back?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#32 |
(In reply to comment #30)
> So you need wine-tools to fix it? Why can't regular wine be able to switch the
> resolution back?
You are confusing Wine Tools (an external, not WineHQ related Wine wrapper)
with wine-tools - a part of the Wine package. It's pretty questionable practice
of splitting Wine into packages though.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#33 |
(In reply to comment #28)
> It seems to happen to all apps that go fullscreen (such as games). I'm using
> Wine 1.0-rc2.
>
Looking over/grepping the code, Wine seems to ignore the CDS_FULLSCREEN flag. It *uses* it from within its d3d implementation, but the receiving code in winex11drv.dll doesn't pay any attention to this flag.
A well behaved application should react to loss of focus by restoring the desktop display mode, by calling ChangeDisplaySe
However, when an application switches the display mode using the CDS_FULLSCREEN flag, Windows itself will restore the desktop display mode when the application terminates. This makes it possible for applications that don't really abide by the rules to slip by on real Windows systems, but exhibit this issue on Wine.
I don't know whether your specific games fall into this category, or if there are maybe some other issues at work, but I'm quite sure that Wine's ignoring of the CDS_FULLSCREEN flag is at least a possible cause for the symptoms you're seeing.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#34 |
http://
CDS_FULLSCREEN behaviour, but says nothing whether Windows restores resolution
on the app's exit.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#35 |
So wine-tools is a separate package available from WineHQ? Where do I find the Suse version of it then?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#36 |
(In reply to comment #34)
> So wine-tools is a separate package
Yes.
> available from WineHQ?
No.
> Where do I find the Suse version of it then?
Ask the distributor of the package, not here.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#37 |
Well I can't find it... but you guys should really consider making this feature part of regular wine.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#38 |
And bug 10115 is directly related to this one.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#39 |
I'm adding my vote for fixing this bug. Pressing Alt-Tab (or Meta-Tab on some keyboards) to switch away from a fullscreen game, such as Warcraft 3 or Starcraft, that sets its own resolution, leaves the desktop set at that resolution.
Here are some simple steps to follow:
Legally obtain/borrow a Starcraft CD from someone
Run Starcraft (it uses a 640x480 resolution)
Press Alt-Tab
The GNOME/KDE/etc. desktop is at the resolution set by the game
I liked the behavior way back when Wine used XF86VM instead of XRandR to change resolutions. I don't want wine to change my desktop resolution, which is what XRandR does. I want it to create a window that's the appropriate size, and change the viewport resolution and position to match the window (which is what XF86VM does). When I press Alt-Tab, and the app running under wine loses focus, the resolution should be restored.
If this is a WM problem, and every major WM on the planet has the problem, then it's probably wine's job to work around it.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#40 |
(In reply to comment #38)
> I liked the behavior way back when Wine used XF86VM instead of XRandR to change
> resolutions. I don't want wine to change my desktop resolution, which is what
> XRandR does. I want it to create a window that's the appropriate size, and
> change the viewport resolution and position to match the window (which is what
> XF86VM does). When I press Alt-Tab, and the app running under wine loses
> focus, the resolution should be restored.
XF86VM is still available. See http://
But even if I set UseXRandR="N" and UseXVidMode="Y", resolution is not restored on Alt-Tab (Fedora 8, fglrx 8.08, Heroes of Might and Magic III).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#41 |
*** Bug 16396 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#42 |
*** Bug 16219 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#43 |
*** Bug 12386 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#44 |
This also affects World of Goo when you exit the game; tested with latest git.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#45 |
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
http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#46 |
I filed a KWin bug a while ago: https:/
But was told that it's not a WM bug:
"The resolution switching is done by the game, and it is not supposed to leave your screen in the wrong resolution. Moreover, if the game really changes the size of the desktop, then it's another wrong thing it does - it's supposed to only change the video mode."
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#47 |
Is this still an issue in current (1.1.31 or newer) wine?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#48 |
We discussed this a bit at wineconf and we need some Free Desktop support to do this properly. I'll see what I can do to get us some help.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#49 |
(In reply to comment #45)
> Is this still an issue in current (1.1.31 or newer) wine?
Yes it is. Tested with Ubuntu 9.10 and Wine 1.1.32. Fresh installation, no customization whatsoever.
After ending the full screen game orderly, the desktop shows the reduced resolution. This does not happen when I start the game with XP on the same machine.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#50 |
Created an attachment (id=24844)
user32: Recover display resolution when applications crash or when fullscreen apps change focus.
(In reply to comment #46)
> We discussed this a bit at wineconf and we need some Free Desktop support to do
> this properly. I'll see what I can do to get us some help.
Why can't we just do something like the attached? Note that if you read my wine-devel posting this is not the same thing, I misread what the issue was about.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#51 |
Wine explorer would be a better place for the fix. Still this needs some
testing, in particular CDS_FULLSCREEN behaviour. One of the questions is
what happens is the launcher has changed the screen resolution, then runs
a child and exits?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#52 |
Reading through the oldnewthing comments from http://
In addition, that article seems to be implying that CDS_FULLSCREEN suppresses a WM_DISPLAYCHANGE notification (this is because CDS_FULLSCREEN is saying that "this is a temporary resolution change, so an application -- such as explorer -- does not need to rearrange its layout").
What the article does not say is what happens in DirectX (2D and 3D) when fullscreen is requested -- does that restore resolution in all cases, giving a stronger guarantee than CDS_FULLSCREEN?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#53 |
*** Bug 20833 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#54 |
If this (bit messy) bug report is about problem: "when you exit the game the screen resolution doesn't switch back to normal but stays at the resolution used in game", than Need For Speed: Pro Street is also affected. Interesting, that a lot of other games correctly returns resolution back.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#55 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#56 |
(In reply to comment #52)
> If this (bit messy) bug report is about problem: "when you exit the game the
> screen resolution doesn't switch back to normal but stays at the resolution
> used in game", than Need For Speed: Pro Street is also affected. Interesting,
> that a lot of other games correctly returns resolution back.
So - only real conclusion - no matter what - is:
1. There is Design issue within some Wine component
2. There is issue withing some feature design in Microsoft Windows compatible game coding components ...
Simply put ... this is damn hard to be fixed ... I would think It would be more realistic if the reason ( which I think is more global than local - invalid parameters / etc. ) is is would to put some refund or prize or bounty to find best fix for these issues ...
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#57 |
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 address hidden>
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?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#58 |
Meanwhile bug https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
RussianNeuroMancer (russianneuromancer) wrote : | #59 |
Binary package hint: xorg
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.
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+5ubuntu1
ProcVersionSign
Uname: Linux 2.6.32-24-generic x86_64
NonfreeKernelMo
Architecture: amd64
Date: Mon Aug 30 00:33:01 2010
DkmsStatus:
nvidia-current, 195.36.24, 2.6.32-22-generic, x86_64: built
nvidia-current, 195.36.24, 2.6.35-
nvidia-current, 195.36.24, 2.6.32-24-generic, x86_64: installed
nvidia-current, 195.36.24, 2.6.32-23-generic, x86_64: built
InstallationMedia: Kubuntu 10.04 "Lucid Lynx" - Release Candidate amd64 (20100419.1)
MachineType: LENOVO 20017
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LANGUAGE=
LANG=ru_RU.utf8
SHELL=/bin/bash
SourcePackage: xorg
dmi.bios.date: 03/15/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 15CN35WW(V2.08)
dmi.board.name: KIWB1
dmi.board.vendor: LENOVO
dmi.board.version: REFERENCE
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: No Enclosure
dmi.chassis.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.name: 20017
dmi.product.
dmi.sys.vendor: LENOVO
glxinfo: Error: [Errno 2] Нет такого файла или каталога
system:
distro: Ubuntu
codename: lucid
architecture: x86_64
kernel: 2.6.32-24-generic
description: | updated |
tags: | removed: amd64 apport-bug lucid |
affects: | xorg (Ubuntu) → xorg-server (Ubuntu) |
Changed in xorg-server (Ubuntu): | |
status: | New → Confirmed |
Changed in wine: | |
status: | Unknown → Confirmed |
Changed in xorg-server: | |
importance: | Unknown → High |
status: | Unknown → Confirmed |
Changed in wine: | |
importance: | Unknown → Wishlist |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#61 |
*** Bug 25296 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#62 |
Scott, any word from FD.O?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#69 |
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.
Sigh.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#63 |
I have also noticed that the gamma levels often aren't reset either when an game crashes. Opening the nvidia-settings fixes it (even without choosing any options).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#64 |
> I have also noticed that the gamma levels often aren't reset either when an
> game crashes. Opening the nvidia-settings fixes it (even without choosing any
> options).
Yes. But under Windows (at least 95, XP and 2000) the behavior is the same. You have to open display properties to restore gamma levels.
Changed in xorg-server: | |
importance: | High → Unknown |
Changed in xorg-server: | |
importance: | Unknown → High |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#65 |
World of Goo (demo) also doesn't restore its resolution when it quits.
Changed in xorg-server (Ubuntu): | |
status: | Confirmed → Triaged |
importance: | Undecided → Wishlist |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Bryce Harrington (bryce) wrote : | #66 |
Still an issue in precise. This is one use case RAOF and I came up with for libxrandr-utils to handle.
tags: | added: precise |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
dronus (paul-geisler) wrote : | #67 |
Why is this wishlist only? This is clearly a bug. It is obvious that -with exception for the desktop setting programs-, the screen resolution is a temporary ressource like screen space and memory. If I kill an application, I expect that all temporary ressources are freed reliable. Failing of doing so gives horrible usability problems.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#68 |
*** Bug 29826 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#70 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#71 |
*** Bug 22700 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#72 |
*** Bug 28637 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#74 |
I finished checking the following games in fullscreen using Ubuntu 11.10 with Unity, Kubuntu 11.10 (KDE) and Ubuntu 11.10 with Gnome3:
+ Trine2
+ Half-Life 2 (PLus Ep1, Ep2 and TF2)
+ World of Goo
+ PLants Vs Zombies
+ Skyrim
+ Left4Dead
+ Left4Dead2
+ Prince of Persia (Sands of Time)
+ Prince of Persia (Warrior Within)
+ Prince of Persia (Forgotten Throne)
+ GTA San Andreas
+ GTA Vice City
+ Spore
+ Hitman: Blood Money
+ Penumbra: Overture
+ Amnesia: The Dark Descent
+ Warcraft 3 Frozen Throne
In ALL cases the problem is the same for all 3 desktops (KDE, Unity, Gnome3)
If you open the game in fullscreen (In this case my resolution is 1680x1050, but the fullscreen was tested in 1280x1024, 1024x768 and 1360x768) after exiting the game, 100% of the time the resolution of the system will turn into the resolution of the game. So if Ubuntu has 1680x1050 and you open a game in fullscreen with a resolution of 1024x768, after exiting the game Ubuntu will have the resolution the game has.
This was tested using an Nvidia 9500 card, Nvidia 440 card and an Intel 945. Did not have an Ati with me but I am guessing it will have the same result.
I spend about a week and half testing this to maybe find some workaround that could fix the problem. No luck. I also tested this on Windows 7 and this does not happen. You can exit the game and the resolution will be the correct one for the desktop.
Tried changing the Windows Version in Wine from XP, to 7, to 2003 and even tested Vista. Same result.
Games were tested with OpenGL if they had the option or DirectX. Same result.
The monitor I used was a Soneview 32' 16:10 TV 1080p just in case this has some influence.
There was also no output error. For what Wine could know after exiting the game, everything was perfect. But of course the resolution after exiting was not.
I also remember having this issue from 1.1.x, 1.2.x, 1.3.x and right now with the official 1.4.
This pretty much sums everything up. If affects any program that uses fullscreen or has the ability to use fullscreen. If any of the games I have mentioned are used in a windows resolution (less than the actual desktop resolution) then no problem shows up. It only reveals itself in fullscreen.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#75 |
Also like to add that, for some games that change the gamma, after exiting, the desktop apart from taking the games resolution, it also takes its gamma. It may also be taking anything else that was setup in the game.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
Luis Alvarado (luisalvarado) wrote : | #73 |
I finished checking the following games in fullscreen using Ubuntu 11.10 with
Unity, Kubuntu 11.10 (KDE) and Ubuntu 11.10 with Gnome3:
+ Trine2
+ Half-Life 2 (PLus Ep1, Ep2 and TF2)
+ World of Goo
+ PLants Vs Zombies
+ Skyrim
+ Left4Dead
+ Left4Dead2
+ Prince of Persia (Sands of Time)
+ Prince of Persia (Warrior Within)
+ Prince of Persia (Forgotten Throne)
+ GTA San Andreas
+ GTA Vice City
+ Spore
+ Hitman: Blood Money
+ Penumbra: Overture
+ Amnesia: The Dark Descent
+ Warcraft 3 Frozen Throne
In ALL cases the problem is the same for all 3 desktops (KDE, Unity, Gnome3)
If you open the game in fullscreen (In this case my resolution is 1680x1050,
but the fullscreen was tested in 1280x1024, 1024x768 and 1360x768) after
exiting the game, 100% of the time the resolution of the system will turn into
the resolution of the game. So if Ubuntu has 1680x1050 and you open a game in
fullscreen with a resolution of 1024x768, after exiting the game Ubuntu will
have the resolution the game has.
This was tested using an Nvidia 9500 card, Nvidia 440 card and an Intel 945.
Did not have an Ati with me but I am guessing it will have the same result.
I spend about a week and half testing this to maybe find some workaround that
could fix the problem. No luck. I also tested this on Windows 7 and this does
not happen. You can exit the game and the resolution will be the correct one
for the desktop.
Tried changing the Windows Version in Wine from XP, to 7, to 2003 and even
tested Vista. Same result.
Games were tested with OpenGL if they had the option or DirectX. Same result.
The monitor I used was a Soneview 32' 16:10 TV 1080p just in case this has some
influence.
There was also no output error. For what Wine could know after exiting the
game, everything was perfect. But of course the resolution after exiting was
not.
I also remember having this issue from 1.1.x, 1.2.x, 1.3.x and right now with
the official 1.4.
This pretty much sums everything up. If affects any program that uses
fullscreen or has the ability to use fullscreen. If any of the games I have
mentioned are used in a windows resolution (less than the actual desktop
resolution) then no problem shows up. It only reveals itself in fullscreen.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#76 |
(In reply to comment #63)
> This pretty much sums everything up. If affects any program that uses
> fullscreen or has the ability to use fullscreen. If any of the games I have
> mentioned are used in a windows resolution (less than the actual desktop
> resolution) then no problem shows up. It only reveals itself in fullscreen.
It's all very interesting but this bug is WONTFIX, as it's an issue in X.org server ( https:/
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#77 |
> It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> server ( https:/
This bug isn't WONTFIX, seems that someone has reopened the bug on X.org server…
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#78 |
(In reply to comment #66)
> > It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> > server ( https:/
>
> This bug isn't WONTFIX, seems that someone has reopened the bug on X.org
> server…
I meant that it's WONTFIX concerning Wine (and that has been repeated numerous times by different Wine developers).
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#79 |
(In reply to comment #67)
> (In reply to comment #66)
> > > It's all very interesting but this bug is WONTFIX, as it's an issue in X.org
> > > server ( https:/
> >
> > This bug isn't WONTFIX, seems that someone has reopened the bug on X.org
> > server…
>
> I meant that it's WONTFIX concerning Wine (and that has been repeated numerous
> times by different Wine developers).
UPSTREAM is the appropriate resolution. CLOSED UPSTREAM when it is fixed in X.org.
Changed in xorg-server (Ubuntu): | |
importance: | Wishlist → Medium |
Changed in wine: | |
status: | Confirmed → Won't Fix |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#81 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#82 |
The discussion linked to from comment #3 certainly suggests that this is in scope for x11/randr.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#83 |
(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?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#84 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#85 |
(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.)
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#86 |
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.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#80 |
*** Bug 18386 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#87 |
*** Bug 32814 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#88 |
A workaround/hack for this issue: http://
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#89 |
*** Bug 19641 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#91 |
Based on http://
Reverting back CLOSED to RESOLVED.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#92 |
*** Bug 42760 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#93 |
I am very interested in seeing this bug get fixed.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#94 |
I am also interested in the fate of this god, who gives me great discomfort.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#95 |
*** Bug 5282 has been marked as a duplicate of this bug. ***
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#96 |
There used to be cases where when the X server would crash it would fail to restore a usable resolution; these are mostly fixed now. But we still don't have temporary configuration changes for RANDR.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#97 |
It's XF86VidModeSwit
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#98 |
A memo to myself: reply for the question above from IRC
> [14:35:16] <ajax> Hi-Angel: the server-side dispatch functions are usually named ProcExtnameRequ
> [14:35:34] <ajax> Hi-Angel: in this case, xserver/
> [14:36:50] <ajax> of course then you're in c vtable hell, and you need to discover what fills in all the fptrs inside pVidMode... but at least gdb can tell you those answers if you debug it live
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#99 |
Closing.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#100 |
This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should only be closed when fixed upstream.
Setting back to RESOLVED NOTOURBUG.
Sorry for the spam.
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#101 |
Given the lack of any movement on the relevant feature request of Free Desktop in the almost *11* years since its filing, perhaps it's time to re-evaluate whether Wine should be made to replicate the behavior of Windows using the Free Desktop we have (and seemingly will continue to have for the indefinite future) rather than the Free Desktop we wish we had.
To be clear about the situation:
NOTOURBUG is a bit of a misnomer. This *is* a Wine bug, regardless of the strategy chosen for getting it fixed. Wine's mission is to replicate the behavior of Windows, and this issue represents a failure to do so. It may well be made much easier to fix if Free Desktop implemented a notion of temporary configuration changes like Windows has, but FD's mission is not to replicate Windows behaviors. For them it's merely a feature request. For Wine it remains a bug until the behavior matches that of Windows.
Asking FD to implement a feature rather than doing the work of making Wine mimic it seems to have been a reasonable approach to getting this bug fixed. But can that really still be said after 11 years of waiting?
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#102 |
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https:/
Changed in xorg-server: | |
status: | Confirmed → Unknown |
![](/+icing/build/overlay/assets/skins/sam/images/close.gif)
|
#103 |
(In reply to comment #0) bugs.winehq. org/show_ bug.cgi? id=10839
> …this bug…
http://