http://bugs.winehq.org/show_bug.cgi?id=31370
Bug #: 31370 Summary: Commit brakes full screen functionality in any full screen program. Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv AssignedTo: wine-bugs@winehq.org ReportedBy: HASH.DuOrden@gmail.com Classification: Unclassified
Any programs which able to switch full screen is broken in full screen mode. As soon as it tries to switch in full screen and configured to displayed in desktop it switch to "window" with decorations and panel other it.
Regression test showed: 401d12085bc897e973badee3260aa41389c63c8e is the first bad commit commit 401d12085bc897e973badee3260aa41389c63c8e Author: Henri Verbeet hverbeet@codeweavers.com Date: Fri Jul 13 12:53:11 2012 +0200
winex11: Fix the virtual desktop check in update_desktop_fullscreen().
:040000 040000 7715ae1558216506b568d995076bf091e820d245 b518dc4d5c0d54f8038b9a57e6b3cdc774f595f5 M dlls
http://bugs.winehq.org/show_bug.cgi?id=31370
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Version|unspecified |1.5.8 Summary|Commit brakes full screen |Full screen functionality |functionality in any full |broken in full screen |screen program. |programs Regression SHA1| |401d12085bc897e973badee3260 | |aa41389c63c8e Severity|normal |minor
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #1 from Henri Verbeet hverbeet@gmail.com 2012-07-31 16:55:29 CDT --- (In reply to comment #0)
Any programs which able to switch full screen is broken in full screen mode. As soon as it tries to switch in full screen and configured to displayed in desktop it switch to "window" with decorations and panel other it.
Your description is somewhat lacking, perhaps a before and after screenshot would be clearer. From what I'm reading so far this sounds like an issue with your window manager or perhaps desktop environment though.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #2 from Goblinstomper@gmail.com 2012-07-31 17:47:13 CDT --- Created attachment 41219 --> http://bugs.winehq.org/attachment.cgi?id=41219 This is how my desktop normally looks, 1920x1080
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #3 from Goblinstomper@gmail.com 2012-07-31 17:48:17 CDT --- Created attachment 41220 --> http://bugs.winehq.org/attachment.cgi?id=41220 This is how my desktop looks after trying to launch Temple of elemental evil, fullscreen, in 1280x1024
http://bugs.winehq.org/show_bug.cgi?id=31370
Goblinstomper@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Goblinstomper@gmail.com
--- Comment #4 from Goblinstomper@gmail.com 2012-07-31 17:50:54 CDT --- Now if comment 0 isn't about the kde panel, but some other panel I apologize for the spam. But if it is about the kde panel, then I think it's a dup of Bug 26800 (where I first tried to describe the 'phenomena').
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #5 from Goblinstomper@gmail.com 2012-07-31 17:52:23 CDT --- Comment on attachment 41220 --> http://bugs.winehq.org/attachment.cgi?id=41220 This is how my desktop looks after trying to launch Temple of elemental evil, fullscreen, in 1280x1024
as you can see from the dimensions of the picture, the screen has taken on the dimensions the full screen application was meant to have.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #6 from hash HASH.DuOrden@gmail.com 2012-08-01 06:34:28 CDT --- Created attachment 41223 --> http://bugs.winehq.org/attachment.cgi?id=41223 Darkspore can't switch to full-screen and redraw it's screen for first time after start.
Yes, my initial bug report is really lucking in explanation because it was really late at night and I was in hurry to get some sleep. All problem arouse when you try to use "Emulate a virtual desktop" set to match your display resolution. Previously this wont try to display any decoration and behave as other windows, displaying tool-bar over it self. What now you can see in attached screen-shot of Darkspore. And one more thing, right after it switches in full-screen, program cannot redraw it's window for the first time, on screen-shot Darkspore is long launched but logon screen isn't shown, I need to minimize and then restore this "window" for game to start redraw it's screen.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #7 from Henri Verbeet hverbeet@gmail.com 2012-08-01 08:24:44 CDT --- (In reply to comment #6)
Yes, my initial bug report is really lucking in explanation because it was really late at night and I was in hurry to get some sleep. All problem arouse when you try to use "Emulate a virtual desktop" set to match your display resolution. Previously this wont try to display any decoration and behave as other windows, displaying tool-bar over it self. What now you can see in attached screen-shot of Darkspore. And one more thing, right after it switches in full-screen, program cannot redraw it's window for the first time, on screen-shot Darkspore is long launched but logon screen isn't shown, I need to minimize and then restore this "window" for game to start redraw it's screen.
So you're saying that on resolution changes to a resolution less than the screen size the virtual desktop acquires decorations, right? (I.e. this is essentially a duplicate of bug 31250.) That's how it's supposed to work, the virtual desktop should have the fullscreen state when its size matches the screen resolution, and decorations when it doesn't. If you want the virtual desktop window to never have decorations you should configure that in your window manager, bug 31250 has some instructions for Compiz, but in most window managers it's not very hard.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #8 from Henri Verbeet hverbeet@gmail.com 2012-08-01 08:29:08 CDT --- (In reply to comment #5)
Comment on attachment 41220 [details] This is how my desktop looks after trying to launch Temple of elemental evil, fullscreen, in 1280x1024
as you can see from the dimensions of the picture, the screen has taken on the dimensions the full screen application was meant to have.
That looks like a different issue to me, and since it seems to change the actual screen resolution, I'm not sure it really has anything to do with virtual desktop or this commit.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #9 from hash HASH.DuOrden@gmail.com 2012-08-01 08:48:05 CDT --- (In reply to comment #7)
(In reply to comment #6)
Yes, my initial bug report is really lucking in explanation because it was really late at night and I was in hurry to get some sleep. All problem arouse when you try to use "Emulate a virtual desktop" set to match your display resolution. Previously this wont try to display any decoration and behave as other windows, displaying tool-bar over it self. What now you can see in attached screen-shot of Darkspore. And one more thing, right after it switches in full-screen, program cannot redraw it's window for the first time, on screen-shot Darkspore is long launched but logon screen isn't shown, I need to minimize and then restore this "window" for game to start redraw it's screen.
So you're saying that on resolution changes to a resolution less than the screen size the virtual desktop acquires decorations, right? (I.e. this is essentially a duplicate of bug 31250.) That's how it's supposed to work, the virtual desktop should have the fullscreen state when its size matches the screen resolution, and decorations when it doesn't. If you want the virtual desktop window to never have decorations you should configure that in your window manager, bug 31250 has some instructions for Compiz, but in most window managers it's not very hard.
I didn't said that I change resolution to lower then actual desktop resolution or changed it at all, it is equal to actual desktop resolution! And I state so in my lats post.
All problem arouse when you try to use "Emulate a virtual desktop" set to match your display resolution.
To make it crystal clear: My display is 1600x1200 "Emulate a virtual desktop" is set to 1600x1200 Darkspore, as example here do not change resolution during it's start. Darkspore have it's launcher which check for updates and start as small window but it had to be set to use "Emulate a virtual desktop" and launcher starts in full-screen. Consequently that launcher starts the game which is set to use resolution 1600x1200 but as soon as game starts it fall out of full-screen in to decorated window.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #10 from Henri Verbeet hverbeet@gmail.com 2012-08-01 09:25:39 CDT --- Well, it works here for both cases. (DarkSpore set to the desktop resolution and DarkSpore set to a different resolution) Could you attach a +x11drv log?
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #11 from Goblinstomper@gmail.com 2012-08-01 09:36:57 CDT --- (In reply to comment #8)
(In reply to comment #5)
Comment on attachment 41220 [details] This is how my desktop looks after trying to launch Temple of elemental evil, fullscreen, in 1280x1024
as you can see from the dimensions of the picture, the screen has taken on the dimensions the full screen application was meant to have.
That looks like a different issue to me, and since it seems to change the actual screen resolution, I'm not sure it really has anything to do with virtual desktop or this commit.
yes I agree, I missed that comment 0 referenced virtual desktops and jumped to conclusions. is there a way for me to remove my comments etc from this bug?
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #12 from Henri Verbeet hverbeet@gmail.com 2012-08-01 09:42:32 CDT --- (In reply to comment #11)
yes I agree, I missed that comment 0 referenced virtual desktops and jumped to conclusions. is there a way for me to remove my comments etc from this bug?
Not really, but that's ok. You can obsolete attachments, and an admin could actually delete things, but it's not really worth it. That's mostly reserved for cases where someone attaches something we're not allowed to distribute.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #13 from hash HASH.DuOrden@gmail.com 2012-08-02 04:24:16 CDT --- Created attachment 41234 --> http://bugs.winehq.org/attachment.cgi?id=41234 Here is a log of DarkSpore as requested.
(In reply to comment #10)
Well, it works here for both cases. (DarkSpore set to the desktop resolution and DarkSpore set to a different resolution) Could you attach a +x11drv log?
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #14 from Henri Verbeet hverbeet@gmail.com 2012-08-02 07:34:25 CDT --- Created attachment 41236 --> http://bugs.winehq.org/attachment.cgi?id=41236 patch
(In reply to comment #13)
trace:x11drv:X11DRV_desktop_SetCurrentMode Resizing Wine desktop window to 1600x1200 trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1600,1200) work (0,0)-(1600,1200) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1600,1200) primary size: 1600x1200 trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1600,1200) work (0,0)-(1600,1200) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1600,1200) primary size: 1600x1200 trace:x11drv:X11DRV_resize_desktop desktop 0x10038 change to (1600x1200) trace:x11drv:update_desktop_fullscreen action=1 trace:x11drv:X11DRV_WindowPosChanged win 0x10038 window (0,0)-(1600,1200) client (0,0)-(1600,1200) style 96000000 flags 0000381f trace:x11drv:set_mwm_hints 0x10038 setting mwm hints to 3a,2c (style 96000000 exstyle 0) trace:x11drv:sync_window_position win 0x10038/5e00007 pos 0,0,1600x1200 after 33eac0 changes=c serial=70
Assuming that log is complete, update_desktop_fullscreen() certainly isn't adding any decorations, it's only setting _NET_WM_STATE_FULLSCREEN, which should already be set at that point anyway. I suppose there's a small chance the MWM hints are confusing the window manager, but those also should have been there before. Does the attached patch make any difference? Also, what window manager are you actually using?
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #15 from hash HASH.DuOrden@gmail.com 2012-08-02 10:20:48 CDT --- Created attachment 41240 --> http://bugs.winehq.org/attachment.cgi?id=41240 log of DarkSpore with patch to winegit from comment #14
(In reply to comment #14)
Created attachment 41236 [details] patch
(In reply to comment #13)
trace:x11drv:X11DRV_desktop_SetCurrentMode Resizing Wine desktop window to 1600x1200 trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1600,1200) work (0,0)-(1600,1200) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1600,1200) primary size: 1600x1200 trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1600,1200) work (0,0)-(1600,1200) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1600,1200) primary size: 1600x1200 trace:x11drv:X11DRV_resize_desktop desktop 0x10038 change to (1600x1200) trace:x11drv:update_desktop_fullscreen action=1 trace:x11drv:X11DRV_WindowPosChanged win 0x10038 window (0,0)-(1600,1200) client (0,0)-(1600,1200) style 96000000 flags 0000381f trace:x11drv:set_mwm_hints 0x10038 setting mwm hints to 3a,2c (style 96000000 exstyle 0) trace:x11drv:sync_window_position win 0x10038/5e00007 pos 0,0,1600x1200 after 33eac0 changes=c serial=70
Assuming that log is complete, update_desktop_fullscreen() certainly isn't adding any decorations, it's only setting _NET_WM_STATE_FULLSCREEN, which should already be set at that point anyway. I suppose there's a small chance the MWM hints are confusing the window manager, but those also should have been there before. Does the attached patch make any difference? Also, what window manager are you actually using?
No change in behavior at all. I use Compiz-0.8.8.
http://bugs.winehq.org/show_bug.cgi?id=31370
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41236|0 |1 is obsolete| |
--- Comment #16 from Henri Verbeet hverbeet@gmail.com 2012-08-02 10:29:37 CDT --- Created attachment 41241 --> http://bugs.winehq.org/attachment.cgi?id=41241 patch
Yeah, it doesn't look like the desktop's fullscreen state was properly detected. Could you try the attached patch instead? It adds a couple of extra traces.
http://bugs.winehq.org/show_bug.cgi?id=31370
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41240|0 |1 is obsolete| |
--- Comment #17 from hash HASH.DuOrden@gmail.com 2012-08-02 12:51:07 CDT --- Created attachment 41244 --> http://bugs.winehq.org/attachment.cgi?id=41244 log of DarkSpore with patch to winegit from comment #16
(In reply to comment #16)
Created attachment 41241 [details] patch
Yeah, it doesn't look like the desktop's fullscreen state was properly detected. Could you try the attached patch instead? It adds a couple of extra traces.
Well, first I'm sorry, my previous "log of DarkSpore with patch to winegit from comment #14" in reality wasn't [b]WITH[/b]that patch. Now this log is with one and it do fix half the problem, DarkSpore in full-screen not getting decorated. But it gets beneath system panel which cuts the point of full-screen, but the size of screen reported back to game is still 1600x1200 so there is a lost 20 pixels...
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #18 from hash HASH.DuOrden@gmail.com 2012-08-02 12:52:38 CDT --- Created attachment 41245 --> http://bugs.winehq.org/attachment.cgi?id=41245 screen-shot of DarkSpore with patch to winegit from comment #16
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #19 from Henri Verbeet hverbeet@gmail.com 2012-08-04 07:39:44 CDT --- Created attachment 41267 --> http://bugs.winehq.org/attachment.cgi?id=41267 set _NET_WM_STATE_ABOVE
Does the game have focus at that point? The attached patch may help, although it will create issues with switching to other windows.
http://bugs.winehq.org/show_bug.cgi?id=31370
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41244|0 |1 is obsolete| |
--- Comment #20 from hash HASH.DuOrden@gmail.com 2012-08-04 09:26:01 CDT --- Created attachment 41270 --> http://bugs.winehq.org/attachment.cgi?id=41270 log of DarkSpore with patch to winegit from comment #19
(In reply to comment #19)
Created attachment 41267 [details] set _NET_WM_STATE_ABOVE
Does the game have focus at that point? The attached patch may help, although it will create issues with switching to other windows.
Yes, it have focus, I Alt+Tab'ed several times and played a bit. patch from comment #19 haven't made any difference to the patch from comment #16. Picture all the same, as I posted in attachment #41245. No problems with switching to other windows.
PS: I am a bit curious, why this commit was made in a first place? It isn't like it fix anything at all and I haven't found a bug tired to it, it only brake stuff! What the purpose of this problematic commit?
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #21 from hash HASH.DuOrden@gmail.com 2012-08-12 17:05:12 CDT --- So? How about to fix this or at least temporally call off this bogus commit? Or at least some changes would be nice.
http://bugs.winehq.org/show_bug.cgi?id=31370
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |13820b6f948b4447ed8d73e2e69 | |75155441a8653 Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #22 from Henri Verbeet hverbeet@gmail.com 2012-08-14 06:24:02 CDT --- Commit 13820b6 should avoid the decorations, but you should probably file a bug with you window manager for adding decorations to _NET_WM_STATE_FULLSCREEN windows anyway. Similarly, you should file a bug for the panel being visible above _NET_WM_STATE_FULLSCREEN windows, and even ones that have _NET_WM_STATE_ABOVE in addition to that.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #23 from hash HASH.DuOrden@gmail.com 2012-08-14 09:21:31 CDT --- This I get with wine compiled without your commit: xprop _NET_WM_STATE _NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN And this with your commit in place: xprop _NET_WM_STATE _NET_WM_STATE(ATOM) = And so compiz cannot handle it like a normal fullscreen window because there is no _NET_WM_STATE_FULLSCREEN so it isn't a WM fault.
And I guess I know why it's all works for you, if you tested it under compiz then it is works when "legacy fullscreen workaround" in the workarounds plugin is set, but it shouldn't because this breaks practically all KDE4 applications.
PS: I've found this bunch of links: https://bugzilla.redhat.com/show_bug.cgi?id=623191 https://issues.apache.org/ooo/show_bug.cgi?id=110881 Please pay special attention to: https://issues.apache.org/ooo/show_bug.cgi?id=110881#c8 and to: https://issues.apache.org/ooo/show_bug.cgi?id=110881#c19
PPS: I still waiting to see explanation to why this commit have been made in first place.
http://bugs.winehq.org/show_bug.cgi?id=31370
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org 2012-08-17 13:54:48 CDT --- Closing bugs fixed in 1.5.11.
http://bugs.winehq.org/show_bug.cgi?id=31370
TestSubject sirbubbles01@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sirbubbles01@gmail.com
--- Comment #25 from TestSubject sirbubbles01@gmail.com 2012-10-25 13:30:21 CDT --- (In reply to comment #24)
Closing bugs fixed in 1.5.11.
Rather than marking it as fixed, wouldn't it be better to mark it as invalid? BTW, I followed the link that hash provided to that RedHat bugzilla page, and it describes it as a bug in gtk, not compiz or ubuntu. It does seem that until something changes in gtk, that this NotBug will still stand, as it were.
http://bugs.winehq.org/show_bug.cgi?id=31370
--- Comment #26 from TestSubject sirbubbles01@gmail.com 2012-10-25 13:39:23 CDT --- (In reply to comment #24)
Closing bugs fixed in 1.5.11.
Apologies, it would seem, upon reading that RedHat bugzilla link again, that compiz is to blame at least in part. Still, unless something changes in compiz, it seems as though this annoying behaviour won't change. Any chance that you could provide a way to switch off this full screen state behaviour?