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@winehq.org Reporter: streetwalkermc@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
https://bugs.winehq.org/show_bug.cgi?id=45690
Dan Elkouby streetwalkermc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |streetwalkermc@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45690
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
https://bugs.winehq.org/show_bug.cgi?id=45690
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd@gmail.com
--- Comment #1 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #2 from Dmitry Timoshkov dmitry@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #3 from Dan Elkouby streetwalkermc@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #4 from Dan Elkouby streetwalkermc@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #5 from Vincent Povirk madewokherd@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
--- Comment #6 from Dan Elkouby streetwalkermc@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.
https://bugs.winehq.org/show_bug.cgi?id=45690
futureisborn-adsjklu4893bnm@yahoo.co.jp changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |futureisborn-adsjklu4893bnm | |@yahoo.co.jp
https://bugs.winehq.org/show_bug.cgi?id=45690
junglerobba@jngl.one changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |junglerobba@jngl.one
-
wine-bugs＠winehq.org -
WineHQ Bugzilla