On Thu Jan 23 12:38:42 2025 +0000, William Horvath wrote:
> ~~I just tested this again on swaywm (recent git version), and it only
> fixes the issue the first time the minimize-to-tray action is performed.
> Once the floating tray icon is clicked and the window is restored, on
> subsequent attempts, the game window is no longer unmapped/hidden. It
> remains as an empty black window on screen (but the tray icon does show
> up again).~~
> ~~This is different from how this patch affects i3 (where I tested
> before), because on i3 it fixes the issue no matter how many times the
> minimization/restoration is done. Before the async request patches, the
> functionality worked identically on i3 and sway.~~
> ~~Sorry I didn't catch that earlier. It's still interesting, because it
> means that the outdated workaround/hack I pointed out in i3's source is
> not the only thing to blame here. I looked around for something like
> that in sway/wlroots' xwayland interop and couldn't find anything as
> suspicious like that.~~
> Ignore this. The difference where the window is a black rectangle on
> consecutive attempts is not a regression due to the async requests
> commit, it's a separate bug. This patch does restore the behavior to how
> it was before the async requests change on both i3 and sway.
Thanks for checking this, reading the edited comment I understand this actually works and everything is fine.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7121#note_92585
I just tested this again on swaywm (recent git version), and it only fixes the issue the first time the minimize-to-tray action is performed. Once the floating tray icon is clicked and the window is restored, on subsequent attempts, the game window is no longer unmapped/hidden. It remains as an empty black window on screen (but the tray icon does show up again).
This is different from how this patch affects i3 (where I tested before), because on i3 it fixes the issue no matter how many times the minimization/restoration is done. Before the async request patches, the functionality worked identically on i3 and sway.
Sorry I didn't catch that earlier. It's still interesting, because it means that the outdated workaround/hack I pointed out in i3's source is not the only thing to blame here. I looked around for something like that in sway/wlroots' xwayland interop and couldn't find anything as suspicious like that.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7121#note_92582
This confuses mutter and it manifests with spurious IconicState WM_STATE
change when it decides to try managing the window, but it also makes it
randomly lose focus or even fail to map the window back on screen.
Adding the flag after the window has been created fixes the issue.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7181
In cases where MF is already shut down, simply forwarding MFShutdown() to
RtwqShutdown() will corrupt the Rtwq lock count if async result objects
still exist, because they hold a lock. JR East Train Simulator does this.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7174