[Bug 37937] New: Fullscreen applications are minimized when switching virtual desktops / workspaces
https://bugs.winehq.org/show_bug.cgi?id=37937 Bug ID: 37937 Summary: Fullscreen applications are minimized when switching virtual desktops / workspaces Product: Wine Version: 1.7.32 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: winehq(a)tibit.com Distribution: --- A recent wine release broke my ability to easily switch between a full-screen game and other tasks, because it now forcibly minimizes the game when it loses focus. I used to be able to quickly flip back and forth between the game and a strategy guide, documentation, text editor full of notes on my progress, email, etc, using my desktop software's hot keys for switching workspaces. Now, returning to my game involves the incredibly irritating experience of having to find the game's icon on the task bar, grab my mouse, move it toward the task bar icon, aim, and click, every single time I want to return to the game. On top of being quite frustrating, this makes it very difficult to do things like compare what's on screen in the game to screenshots or maps, which are common operations when troubleshooting graphics issues or exploring an open world game. A git bisect reveals the problem commit: 45d530461bf29c953f5f4532cc0e917b4c4fc296 is the first bad commit commit 45d530461bf29c953f5f4532cc0e917b4c4fc296 Author: Stefan Dösinger <stefan(a)codeweavers.com> Date: Thu Nov 13 20:39:25 2014 +0100 This has effectively broken the utility of virtual desktops / workspaces. Would someone revert this, please? Or make it configurable? Or at the very least, make it smart enough to avoid minimizing the game when a focus loss is due to a workspace switch instead of something like alt+tab? For the record, I'm running xfce on linux. -- 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=37937 Béla Gyebrószki <gyebro69(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression CC| |gyebro69(a)gmail.com, | |stefan(a)codeweavers.com Regression SHA1| |45d530461bf29c953f5f4532cc0 | |e917b4c4fc296 --- Comment #1 from Béla Gyebrószki <gyebro69(a)gmail.com> --- Can you try attachment #50455 from bug #37716 to see if the patch fixes the issue for you? -- 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=37937 --- Comment #2 from Forest <winehq(a)tibit.com> --- I tried the patch, and it doesn't fix the problem. -- 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=37937 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #3 from Sebastian Lackner <sebastian(a)fds-team.de> --- Could you please give a couple of examples for apps which are affected? Maybe not every app is affected, at least I have no bad experience with the specific commit, and I am also using XFCE. -- 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=37937 --- Comment #4 from Stefan Dösinger <stefan(a)codeweavers.com> --- I think running the game in a virtual desktop at the size of your real screen will do what you need. If the desktop size matches the screen resolution Wine will disable the desktop borders, essentially giving you a fullscreen game that is impervious to focus loss. If you need a resolution switch at the same time things get more difficult though. @Sebastian: I think Forest's use case is a bit non-standard, though I can understand the reasoning behind it. In the past I have used multiple KDE desktops (not wine virtual desktop) as a workaround for Wine's lack of fullscreen focus loss handling, Forest has just taken it one step further. -- 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=37937 --- Comment #5 from Forest <winehq(a)tibit.com> --- Every full-screen game that I've tried exhibits the problem. Here are a few: Guild Wars 2 Civilization IV Torchlight -- 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=37937 --- Comment #6 from Forest <winehq(a)tibit.com> --- Created attachment 50571 --> https://bugs.winehq.org/attachment.cgi?id=50571 Screenshot: my wine graphics/desktop settings Here are my graphics/desktop settings from winecfg. Note that I am not using the "virtual desktop" setting. -- 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=37937 --- Comment #7 from Stefan Dösinger <stefan(a)codeweavers.com> --- I think running the game in a virtual desktop will give you back the original behavior. At least it works for me on KDE, tested with World in Conflict. You'll have to set the game to your desktop's resolution to make the virtual desktop borders go away. The resolution of the virtual desktop doesn't matter. -- 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=37937 --- Comment #8 from Forest <winehq(a)tibit.com> --- Stefan, I tried running some games with "emulate virtual desktop" at the size of my real screen, and it did get rid of the auto-minimize behavior, but created to new problems: It temporarily filled my screen with a Windows desktop while starting the games. This didn't really break the game, but it sure was ugly, and IMHO a step backwards in terms of integration. For games that don't run at my desktop's native resolution, it ran the game in a window, defeating the purpose of running full-screen. (I guess this is what you expected would happen.) -- 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=37937 --- Comment #9 from Stefan Dösinger <stefan(a)codeweavers.com> --- (In reply to Forest from comment #8)
It temporarily filled my screen with a Windows desktop while starting the games. This didn't really break the game, but it sure was ugly, and IMHO a step backwards in terms of integration. Ya, it's probably not ideal, but I don't see this as a huge problem since your desktop will be filled by the game in a few seconds anyway.
For games that don't run at my desktop's native resolution, it ran the game in a window, defeating the purpose of running full-screen. (I guess this is what you expected would happen.) Yes. You can try to set your screen resolution to the game res before starting Wine with xrandr (e.g. with a startup script). I haven't tested it myself, but I think it'll do what you want.
In your use case you have a problem in the old way as well. E.g. I'm running Starcraft 1 at 640x480. Now I switch to desktop 2 to check the strategy map, and I'm happy it stays at 640x480 to match maps. Now I receive a mail and want to access my Thunderbird on desktop 3. In 640x480? Minimizing the game and restoring the screen resolution on focus loss is what Windows does. We don't have to copy every user interface design decision from Windows, but in this case it is required (see e.g. the Thunderbird(a)640x480 case, also some games wait for the unminimize message to resume operation, bug 23745 may be related to that) and a feature users generally ask for (bugs 15357, 18027). Thus reverting the patch is not the way to go. Making this a registry key or winecfg option is potentially possible, but we'll need a bigger number of requests for this to justify adding an option, especially since the virtual desktop feature provides this pretty well. -- 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=37937 --- Comment #10 from Forest <winehq(a)tibit.com> --- (In reply to Stefan Dösinger from comment #9)
In your use case you have a problem in the old way as well. E.g. I'm running Starcraft 1 at 640x480. Now I switch to desktop 2 to check the strategy map, and I'm happy it stays at 640x480 to match maps. Now I receive a mail and want to access my Thunderbird on desktop 3. In 640x480?
I don't, really. The games I play that don't support my desktop resolution do come close enough to it that switching workspaces to do something else works well. For example, Sid Meier's Pirates does support 1920x1200, but it does support 1600x1200. Switching between the two was painless until this change went into wine.
some games wait for the unminimize message to resume operation
I don't follow. They wait for the unminimize message even when they weren't minimized in the first place?
a feature users generally ask for (bugs 15357, 18027).
For bug 15357 and bug 18027, perhaps it would make sense to minimize on alt+tab but not when the desktop workspace is switched? That would solve the problem described in those bug reports without creating the new one described in this one.
Making this a registry key or winecfg option is potentially possible, but we'll need a bigger number of requests for this to justify adding an option, especially since the virtual desktop feature provides this pretty well.
Well, thanks for the partial workaround, at least. I guess I'll just have to hope more people experiencing the new problem will notice and report it. Regressions make me sad. -- 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=37937 --- Comment #11 from Forest <winehq(a)tibit.com> ---
For example, Sid Meier's Pirates does support 1920x1200, but it does support 1600x1200.
That should have read, "Pirates doesn't support 1920x1200, but it does support 1600x1200. -- 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=37937 --- Comment #12 from Stefan Dösinger <stefan(a)codeweavers.com> --- (In reply to Forest from comment #10)
I don't follow. They wait for the unminimize message even when they weren't minimized in the first place? Yes. There are other ways to find out that the game lost focus, e.g. by listening to WM_ACTIVATEAPP messages or checking the d3d state after IDirect3DDevice9::Present. Games can in practise use way A to detect focus loss and way B to detect focus regain.
For bug 15357 and bug 18027, perhaps it would make sense to minimize on alt+tab but not when the desktop workspace is switched? That would solve the problem described in those bug reports without creating the new one described in this one. Unfortunately d3d9 cannot separate those two cases. In both cases the window manager tells us that we have lost focus. The message wined3d receives is the same in both cases.
You could consider filing a feature request with xfce to request better isolation of workspaces and e.g. keep track of the foreground window per workspace rather than per X server. But this again has problems. E.g. games throttle their framerate on focus loss or pause the game, which may be intended behavior. I suspect the xfce devs will just tell you to run two X servers, as this will also take care of resolution differences. Also the situation with the Linux games I tested on kde is a lot worse: With etracer or ut2004 running I can't change workspaces at all. (In reply to Forest from comment #11)
That should have read, "Pirates doesn't support 1920x1200, but it does support > 1600x1200. This is just another partial workaround, but it may help in a few more games: Some games are just happy with the existing 1920x1200 resolution if it is the only supported resolution. You can achieve that by setting UseXRandr and UseXVidMode to false. See http://wiki.winehq.org/UsefulRegistryKeys for more details. Of course this only works in some games - others just crash when they can't get the resolution they want.
Also I think using xrandr (or any other tool) to pre-adjust the X server's resolution before starting the game. I'll try this after my wine compile is finished. -- 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=37937 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #13 from Stefan Dösinger <stefan(a)codeweavers.com> --- I'm resolving this as INVALID because the new behavior (games minimize on focus loss) is intended. It's a bit unfortunate that we broke this user's workflow, but workarounds exist for most (but not all) cases. -- 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=37937 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Austin English <austinenglish(a)gmail.com> --- Closing. -- 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)
-
wine-bugs＠winehq.org