[Bug 45690] New: Wine does not respect window managers that don' t support iconic state
https://bugs.winehq.org/show_bug.cgi?id=45690 Bug ID: 45690 Summary: Wine does not respect window managers that don't support iconic state Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs(a)winehq.org Reporter: streetwalkermc(a)gmail.com Distribution: --- Several window managers, such as i3, do not support iconized windows by design. However, Wine does not respect those window managers, and will internally go into iconic state despite the WM not granting its request. This results in unusable applications until the WM asks Wine to go back to its normal state again. An easy way to reproduce this is to launch a game that uses exclusive full-screen. When the game loses focus (e.g., by switching to another workspace), it will request iconization. Wine will then call XIconizeWindow, and immediately assume that the window has been minimized, instead of waiting for the WM to update the WM_STATE atom and then considering itself minimized. This will make the game unplayable until it is terminated externally, unless the WM implements a hack to get it out of that state. Related thread: https://github.com/i3/i3/pull/3370 -- 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=45690 Dan Elkouby <streetwalkermc(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |streetwalkermc(a)gmail.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=45690 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de -- 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=45690 Vincent Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com --- Comment #1 from Vincent Povirk <madewokherd(a)gmail.com> --- I don't see how we can fix this on our end. As soon as WS_MINIMIZE is set, the Windows program expects its window to be minimized and not receive any input or expose events. If we wait for the WM to change our window state, we would be waiting forever. Here's our WM_STATE-handling code: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/event.c#l... If a window is created minimized, it looks like we'll ignore the first WM_STATE change notification to work around another WM quirk. Other than that, I don't see why there would be a race condition when the WM sets WM_STATE from normal to normal. It's possible there's a race condition on the win32 side (in wine or the application). A +win,+x11drv log might shed more light on 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.
https://bugs.winehq.org/show_bug.cgi?id=45690 --- Comment #2 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Vincent Povirk from comment #1)
I don't see how we can fix this on our end. As soon as WS_MINIMIZE is set, the Windows program expects its window to be minimized and not receive any input or expose events. If we wait for the WM to change our window state, we would be waiting forever.
Here's our WM_STATE-handling code: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/winex11.drv/event. c#l1214
If a window is created minimized, it looks like we'll ignore the first WM_STATE change notification to work around another WM quirk.
Other than that, I don't see why there would be a race condition when the WM sets WM_STATE from normal to normal. It's possible there's a race condition on the win32 side (in wine or the application). A +win,+x11drv log might shed more light on this.
Please add +event to the proposed debug flags to make the log slightly more verbose. -- 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=45690 --- Comment #3 from Dan Elkouby <streetwalkermc(a)gmail.com> --- (In reply to Vincent Povirk from comment #1)
I don't see how we can fix this on our end. As soon as WS_MINIMIZE is set, the Windows program expects its window to be minimized and not receive any input or expose events. If we wait for the WM to change our window state, we would be waiting forever.
This is indeed a compelling argument. However, rather than having to implement a hack in every WM that doesn't support iconic state, I think it should be up to Wine to provide an escape hatch for its non-standard behavior. The window regaining focus should be enough of an indicator that it should no longer be minimized. -- 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=45690 --- Comment #4 from Dan Elkouby <streetwalkermc(a)gmail.com> --- An i3 maintainer has pointed out that it doesn't claim support for WM_CHANGE_STATE in _NET_SUPPORTED, and suggests using that to prevent applications from iconizing: https://github.com/i3/i3/pull/3421#issuecomment-424320343 I'm not sure how that impacts the Wine side of things, what do you think? On a side note, I can't reproduce the supposed race condition when resetting WM_STATE, it might have been a transient issue in the Wine build bundled with recent versions of Steam. -- 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=45690 --- Comment #5 from Vincent Povirk <madewokherd(a)gmail.com> --- I don't see anything in EWMH to indicate that _NET_SUPPORTED is intended to be used in this way. A quick check with 'xprop -root' shows that the WM I'm using, metacity, doesn't include this atom in _NET_SUPPORTED either, but it definitely supports minimization. -- 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=45690 --- Comment #6 from Dan Elkouby <streetwalkermc(a)gmail.com> --- Yeah, another comment corrected this. WM_STATE is an ICCCM feature and therefore i3 must handle it, and it has no reason to be listed in _NET_SUPPORTED. -- 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=45690 futureisborn-adsjklu4893bnm(a)yahoo.co.jp changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |futureisborn-adsjklu4893bnm | |@yahoo.co.jp -- 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=45690 junglerobba(a)jngl.one changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |junglerobba(a)jngl.one -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla