[Bug 57569] New: BeamNG.drive minimizes its window during startup, with UseTakeFocus set to false.
https://bugs.winehq.org/show_bug.cgi?id=57569 Bug ID: 57569 Summary: BeamNG.drive minimizes its window during startup, with UseTakeFocus set to false. Product: Wine Version: 10.0-rc2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: logos128(a)gmail.com Regression SHA1: 0cda91856138e1d49fcfd9b6c2c9328146616baa Distribution: ArchLinux Happens only with the default (d3d11) renderer in fullscreen mode. The UseTakeFocus option is set to 'N' in the registry (HKCU\Software\Wine\X11 Driver\UseTakeFocus). Since this option is turned on by default in Wine, normally it doesn't cause the aforementioned issue. Although, it would be a problem for Proton, where UseTakeFocus is tuned off by default (https://github.com/ValveSoftware/wine/commit/d30ce49ed8b40b9c29b5cc374987cac...), as it helps some games launch properly. I use it to run Forza Horizon 5, etc., (Wine-Staging + patches + Steam). I didn't notice this right away, as I use borderless in BeamNG, which works properly with UseTakeFocus=false. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 Ivo Ivanov <logos128(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |rbernon(a)codeweavers.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #1 from Rémi Bernon <rbernon(a)codeweavers.com> --- Could you make a log with WINEDEBUG=+timestamp,+pid,+loaddll,+x11drv,+event,+win ? FWIW I think UseTakeFocus=Y is better, especially with the window config refactoring, it gives us more control over focus and allows to workaround various broken WM behaviors (see https://gitlab.winehq.org/wine/wine/-/merge_requests/6944). Proton doesn't use it for historical reasons, and mostly because of WM bugs, hopefully it could change in the future. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #2 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 77672 --> https://bugs.winehq.org/attachment.cgi?id=77672 BeamNG_d3d11.tar.gz WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+event,+win Includes: -BeamNG_d3d11_issue.log (Wine 10.0rc2.r37.g027c2abe1ce), which shows the issue - the game window minimizes itself during startup - I maximized it to quit the game properly. -BeamNG_d3d11.log (Wine 9.21.r168.gd8b5a3ae129 - the commit before the regression), which launches the game without issue. Manjaro (Arch) Linux, Xfce (X11), Nvidia GTX 1080ti, 550.40.79 (Vulkan dev driver) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #3 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Rémi Bernon from comment #1)
FWIW I think UseTakeFocus=Y is better, especially with the window config refactoring, it gives us more control over focus and allows to workaround various broken WM behaviors (see https://gitlab.winehq.org/wine/wine/-/merge_requests/6944).
Thanks, I'll look the MR. I need UseTakeFocus=N only for Forza Horizon 5 - maybe I should file another bug report about it, although it needs some additional patches to run properly. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #4 from Rémi Bernon <rbernon(a)codeweavers.com> --- Looking at the logs there's nothing obviously wrong going on and it's maybe instead some timing difference that made the behavior to change: There's a (4,28)-(2556,1441) window that is created and initially mapped (I assume this is the game window as it is the only one that gets minimized at some point in the broken case) Then, another window is created, mapped and made fullscreen, then quickly gets destroyed. It only briefly exists but enough time for the window manager to try giving it focus. It is shown with SW_SHOW, so it is supposed to activate, nothing wrong about that. Still, as focus briefly changes the game window receives a FocusOut event shortly after, with a FocusIn shortly following it after the WM figured that the other window has been destroyed. From there, the two cases begin to differ: - In the working case, we ignore the FocusOut, probably because we check whether focus is still on another Wine window or not and, by chance, this happens to be the case as the WM already decided to give focus back to the game window. - In the broken case, the check fails, possibly because we don't block anymore waiting for map/unmap, and we check focus slightly before the WM decided to give it back. We then decide we've lost focus and apply the FocusOut even by changing the Win32 foreground window to the desktop window. This, in turn, causes the game window to lose focus on the Win32 side too, and it decides to minimize itself. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #5 from Rémi Bernon <rbernon(a)codeweavers.com> --- Now, each case seem to be correct in isolation, and with the information at hand, the decision to make the desktop window foreground is perfectly valid. I believe we could perhaps do something better if we can predict what events we're going to receive, similarly to what's been done for window configs. For instance, we know that mapping a window will cause a focus change, and we should also be able to tell that destroying a window will cause another focus change. Of course we won't be able to always exactly predict the WM decision about which window will get focus, but in most case and if we're right about our predictions, we can ignore the no-op events and avoid touching the Win32 state unnecessarily. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #6 from Ivo Ivanov <logos128(a)gmail.com> --- Both cases seem correct, and as you say the blocking probably helps the working case by chance. Since UseTakeFocus = 'Y' by default in Wine, IMO this is not a problem there. On Proton this can be sorted with an individual setting in BeamNG's AppDefaults, etc. I'll post a log with UseTakeFocus = 'Y' that works perfectly, just for clarity. IMO no need to do anything on this issue for now, since it won't be a problem at all for Wine users. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #7 from Ivo Ivanov <logos128(a)gmail.com> --- Created attachment 77691 --> https://bugs.winehq.org/attachment.cgi?id=77691 BeamNG_d3d11_UseTakeFocus.gz WINEDEBUG=-all,+timestamp,+pid,+tid,+loaddll,+x11drv,+event,+win BeamNG launches without issues. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #8 from Rémi Bernon <rbernon(a)codeweavers.com> --- I think the situation should have improved with UseTakeFocus = 'Y', since 3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8, could you check again? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #9 from Ivo Ivanov <logos128(a)gmail.com> --- BeamNG has always worked correctly with UseTakeFocus = 'Y'. In any case I tested it with the latest master 647004cd5d7ee93ad8b53abb8939da87be3e25a0 and it worked without any issues (d3d11, fullscreen). Tested UseTakeFocus = 'N' as well, and it also worked without any issues. Not sure if the mentioned commit has fixed it, or something else. I'll look into it when time permits. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57569 --- Comment #10 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Ivo Ivanov from comment #9)
BeamNG has always worked correctly with UseTakeFocus = 'Y'. In any case I tested it with the latest master 647004cd5d7ee93ad8b53abb8939da87be3e25a0 and it worked without any issues (d3d11, fullscreen).
Tested UseTakeFocus = 'N' as well, and it also worked without any issues. Not sure if the mentioned commit has fixed it, or something else. I'll look into it when time permits.
Can we close this? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57569 Ivo Ivanov <logos128(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Ivo Ivanov <logos128(a)gmail.com> --- (In reply to Hans Leidekker from comment #10)
Can we close this?
Yes, the issue is fixed. I'm not sure which commit exactly solved it. Maybe the aforementioned 3ae66c75cf443c0be403d9fe4e4da3c19b3ad9a8, or something between it and 647004cd5d7ee93ad8b53abb8939da87be3e25a0. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57569 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.19. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla