http://bugs.winehq.org/show_bug.cgi?id=58443
Bug ID: 58443 Summary: x11 'minimized' windows not re-fullscreening (fallout 3 / new vegas) Product: Wine Version: 10.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: zlice@crtdrift.us Distribution: ---
c67bfdbeba1860c891e53c64379f5e86d8e8b664 / https://gitlab.winehq.org/wine/wine/-/commit/c67bfdbeba1860c891e53c64379f5e8...
reading the title of the mr makes sense, however this completely breaks fullscreen for fallout 3 and new vegas, and im sure other older games
as mentioned https://bugs.winehq.org/show_bug.cgi?id=58442 - there have been a lot of fullscreen/focus/window bugs so it's hard to tell what all is what
i spent a bunch of time to just bisect so i'll have to look for what is going on tomorrow
http://bugs.winehq.org/show_bug.cgi?id=58443
zlice zlice@crtdrift.us changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |c67bfdbeba1860c891e53c64379 | |f5e86d8e8b664
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #1 from zlice zlice@crtdrift.us --- for reference, fluxbox and openbox both were refusing to bring this back from being minimized
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #2 from zlice zlice@crtdrift.us --- 3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8 also contributes to this behavior
https://gitlab.winehq.org/wine/wine/-/commit/3ae66c75cf443c0be403d9fe4e4da3c...
i am question a lot of it ?
in event.c : window_set_wm_state - `set_focus` - it looks like it should be `if _NET_ACTIVE_WINDOW - return` or something
in window.c : `if (data->hwnd == foreground || data->is_fullscreen) activate = TRUE;`
makes no sense? fullscreen does not imply active in linux/x11? i have mpv fullscreened in the background all the time while i look stuff up. or may have something fullscreen on another monitor that is not active.
even then, why try to activate a foreground window? that should mean it's active?
seeing that window_set_wm_state is called on state change notifiy's and WindowPosChanged, that seems wrong
event.c has another 'check if foreground && active) - set_net_active ... which seems weird
idk the wine code that well, so this is probably beyond me. but it definitely breaks even without the previous MINIMIZE check previously bisected
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #3 from zlice zlice@crtdrift.us --- so dlls/winex11.drv/window.cc -- X11DRV_GetWindowStateUpdates
is the part that seems to juggle old/new foreground and causes something to go fubar
reverting that bit makes fallout 3 stay active while alt tabbing, which i personally love but isn't exactly what the game does in windows (but then again f windows behavior, like-for-like means a lot of shit breaks anyway)
AND it comes back from being manually minimized
this ALSO works with the original MINIMIZE check in set_window_pos() left in
hopefully that helps. will comment it out for myself and if i notice anything else breaking because of it i'll update here
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #4 from zlice zlice@crtdrift.us --- after some short testing, i don't think this would work for most people. openbox and jwm do seem to think fullscreen implies above all windows and maximized, but change focus and then you are lost.
these games on fluxbox will behave like normal sane windows and stay up on alt+tab, which again i cannot stress enough how much i love
fallout 3 fallout nv mass effect 1 kotor spec ops the line prey fallout 4 (has bAlwaysActive ini setting for this, which pretty much means it's forced on?)
watch dogs seems to see it's not focused and minimizes
http://bugs.winehq.org/show_bug.cgi?id=58443
zlice zlice@crtdrift.us changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |winex11.drv
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #5 from zlice zlice@crtdrift.us --- still broke in 10.13
http://bugs.winehq.org/show_bug.cgi?id=58443
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |rbernon@codeweavers.com
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #6 from Rémi Bernon rbernon@codeweavers.com --- Is this still happening with Wine 10.19?
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #7 from zlice zlice@crtdrift.us --- won't be able to test until a week or so
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #8 from zlice zlice@crtdrift.us --- Created attachment 79786 --> http://bugs.winehq.org/attachment.cgi?id=79786 fo3-10.19-crash.txt
so... 10.19 doesn't seem to even run. wow64.
new bug?
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #9 from Rémi Bernon rbernon@codeweavers.com --- Yeah sorry, 10.19 had other issues. It should be fixed in git now so if you can try with latest git revision instead I would greatly appreciate.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #10 from zlice zlice@crtdrift.us --- 548ee6cc0f6fec0acd88218700b2d50cddbf0630
worse. flickers the screen black for a second instead of just once failing to go fullscreen. didnt try openbox which is the best luck to work usually.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #11 from Rémi Bernon rbernon@codeweavers.com --- Hmm, thanks. Could you attach a log with WINEDEBUG=+pid,+loaddll,+seh,+wgl,+x11drv,+event,+win environment variable set?
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #12 from zlice zlice@crtdrift.us --- Created attachment 79787 --> http://bugs.winehq.org/attachment.cgi?id=79787 fo3-dbg-fluxbox
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #13 from zlice zlice@crtdrift.us --- Created attachment 79788 --> http://bugs.winehq.org/attachment.cgi?id=79788 fo3-dbg-openbox
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #14 from zlice zlice@crtdrift.us --- Created attachment 79789 --> http://bugs.winehq.org/attachment.cgi?id=79789 fo3-dbg-jwm
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #15 from zlice zlice@crtdrift.us --- attached logs for fluxbox(shynebox fork), openbox and jwm. openbox and jwm dont even pass the initial window and make it into fullscreen and the game's startup menu.
another question... why do i always have to click on 'login' on the top of the page in the bar with intro/news/etc and then it takes me to another loging page. if i type the wrong pw it doesnt even take me to the other login page so i effectively have to login twice.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- Regarding the logs with openbox and jwm, it looks like some window manager bug. The trace:
0134:0138:trace:x11drv:window_set_wm_state window 0x20060/1a00001, requesting WM_STATE 0 -> 0x1 serial 115, foreground 0x10020, activate 1
Indicates that we request a WM_STATE property change from Withdrawn to Normal to it, to show the game window, but it never replies with the expected WM_STATE property change and we're unable to assume that the window has been shown and continue requests.
This is basic ICCCM protocol, and we can only work with mostly compliant window managers (or you need to uncheck "Allow the window manager to control the windows" in winecfg.
I'm actually surprised if openbox doesn't work, because I've even been testing our code with it and it should be behaving correctly, at least for this step.
In the log with fluxbox this works as expected:
0138:013c:trace:x11drv:window_set_wm_state window 0x20060/5200001, requesting WM_STATE 0 -> 0x1 serial 115, foreground 0x10020, activate 1 ... 0138:013c:trace:x11drv:handle_state_change window 0x20060/5200001 WM_STATE 0x1/138, expected 0x1/115
but then it looks like there's some shenanigans happening with active window:
0138:013c:trace:x11drv:set_net_active_window requesting _NET_ACTIVE_WINDOW 0x20060/5200001 serial 161 ... 0138:013c:warn:x11drv:handle_state_change Ignoring old _NET_ACTIVE_WINDOW 0x20060/5200001 serial 139 time 5971560, expected 0x20060/5200001 serial 161 ... 0138:013c:warn:x11drv:handle_state_change mismatch _NET_ACTIVE_WINDOW 0x10020/4000009 serial 221 time 5980319, expected 0x20060/5200001 serial 161
We requested activation of the game window, (in addition and after it being shown, which triggers the first _NET_ACTIVE_WINDOW we ignore), but the window manager decides to give focus to another window instead, and we translate this to a focus change to the desktop (0x10020/4000009) window as we always do when Wine lose focus.
On the Win32 side, games often handle focus loss by minimizing themselves, which is what the game is doing there:
0138:013c:trace:x11drv:X11DRV_GetWindowStateUpdates hwnd 0x20060, returning state_cmd 0, swp_flags 0, rect (0,0)-(2560,1440), foreground 0x10020 ... 0138:013c:trace:x11drv:window_set_wm_state window 0x20060/5200001, requesting WM_STATE 0x1 -> 0x3 serial 228, foreground (nil), activate 0 ... 0138:013c:trace:x11drv:handle_state_change window 0x20060/5200001 WM_STATE 0x3/232, expected 0x3/228
Then I'm not sure what happens next, but it looks like we fall into a focus restoration / loss loop, causing endless window minimization / restoration. I'm suspecting maybe some requests we do to focus the desktop/root window should be avoided, I'll try making a patch for this.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #17 from zlice zlice@crtdrift.us --- i know Withdrawn stuff was changed by a hack for cinnamon a while back, and it doesn't check if the window manager is cinnamon through xdg env vars or anything like firefox does for example, it just does it (withdraws windows).
from what i remember, the person who investigate the withdraw hack breaking fluxbox submitted a patch to fluxbox and said it wasn't "exactly a X spec but many WMs withdraw when iconified". although i'm not sure what common practice was for old style iconify being "add icon on the desktop".
the fluxbox bit you mentioned with active window _NET_ACTIVE_WINDOW being changed:
other bugs ive witnessed what seems like thread races for conditions like this. wine says "focus me" or whatever state change - then if you add prints or turn on debug which slows things down - whatever issue with focus/active window/state change goes away.
other changes like the watch_dogs QS_POSTMESSAGE adding(or-ing) QS_SENDMESSAGE seem to mess with focus too but i really dont understand what that is in windows world, but it seems like that is a wait for focus. im sure that plays in somehow.
have never really tested "Allow the window manager to control the windows" - but i assume it will completely change how things behave. may check it out just for curiosity, but i can see it introducing more weirdness.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #18 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 79790 --> http://bugs.winehq.org/attachment.cgi?id=79790 Don't activate desktop window
Could you try if this patch helps with fluxbox?
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #19 from zlice zlice@crtdrift.us --- Created attachment 79793 --> http://bugs.winehq.org/attachment.cgi?id=79793 fo3-dbg-fluxbox-doublerun
running with that patch and running the fallout3 exe again pops up the dialog box about it already running and then focuses. but i'm not sure it has anything to do with that patch, because it behaves the same otherwise.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #20 from zlice zlice@crtdrift.us --- Created attachment 79794 --> http://bugs.winehq.org/attachment.cgi?id=79794 fo3-dbg-fluxbox2
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #21 from zlice zlice@crtdrift.us --- meant to add a comment - that fluxbox2 log i tried to re-focus a few times. flickers, single flash, flicker - i think
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #22 from zlice zlice@crtdrift.us --- Created attachment 79795 --> http://bugs.winehq.org/attachment.cgi?id=79795 fo3-dbg-fluxbox-noallowwmctrl
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #23 from zlice zlice@crtdrift.us --- Created attachment 79796 --> http://bugs.winehq.org/attachment.cgi?id=79796 fo3-dbg-openbox-noallowwmctrl
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #24 from zlice zlice@crtdrift.us --- OH! - so i DO have the "allow the window manager to control" setting on
on fluxbox - tabbing from fullscreen just leaves a completely black screen with the fo3 logo at the top left.
openbox - still doesnt pass the initial window creation and make it to fullscreen / game start menu.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #25 from zlice zlice@crtdrift.us --- fwiw - that was with the previous 1 line patch.
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #26 from zlice zlice@crtdrift.us --- also, possibly another bug? or wm quirk idk. 'allow control' seems to imply 'allow decorate' ?
'allow decorate' ONLY does not decorate the window (SSD vs CSD, wines blue windows like titlebar)
'allow decorate' + 'allow control' does have WM titlebar (SSD)
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #27 from Rémi Bernon rbernon@codeweavers.com --- Have you set the "UseTakeFocus" registry option to "N" by any chance? Could you try with "UseTakeFocus" set to "Y" instead? With `wine reg add "HKCU\Software\Wine\X11 Driver" /t REG_SZ /v UseTakeFocus /d Y /f`
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #28 from zlice zlice@crtdrift.us --- UseTakeFocus = Y does make it only toggle once with the above patch instead of strobe.
Also have 'decorated = y' and 'managed = y' (maybe that's related to the win-decore i mentioned?)
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #29 from Rémi Bernon rbernon@codeweavers.com --- Thanks, yes the three options set to Y should be the default and what should be working best.
Could you make the same log as above if it still toggles back and forth?
http://bugs.winehq.org/show_bug.cgi?id=58443
--- Comment #30 from zlice zlice@crtdrift.us --- Created attachment 79799 --> http://bugs.winehq.org/attachment.cgi?id=79799 fo3-dbg-notakefocus-yes
sorry forgot to attach
-
WineHQ Bugzilla