[Bug 51230] New: winecfg: Graphics tab - Per application settings don't work
https://bugs.winehq.org/show_bug.cgi?id=51230 Bug ID: 51230 Summary: winecfg: Graphics tab - Per application settings don't work Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: jkfloris(a)dds.nl Distribution: --- "Wine can mimic different Windows versions for each application. This tab is linked to the Libraries and Graphics tabs to allow you to change system-wide or per-application settings in those tabs as well."
From this I understand that it should also be possible to also set the DPI or a virtual desktop per application. Unfortunately, this does not work.
For example: winecfg Applications tab -> Add application -> "notepad.exe" (select notepad.exe) Graphics tab -> Select "Emulate a virtual desktop" (click "Apply" and "OK") wine notepad.exe Now I expect notepad to run in a virtual desktop. -- 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=51230 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang(a)codeweavers.com --- Comment #1 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Settings in the Graphics tab are global. -- 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=51230 --- Comment #2 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- There are indeed some wording errors in the Applications tab. It should also be possible to implement the per-app graphics settings. -- 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=51230 Robert Walker <bob.mt.wya(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya(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=51230 subgraph93(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |subgraph93(a)gmail.com --- Comment #3 from subgraph93(a)gmail.com --- This appears to be a 6.5 regression. Per-application overrides in winecfg ignore the options "Emulate a virtual desktop" and "Automatically capture the mouse in full-screen windows", apparently always using prefix defaults. Disabling window manager decoration still works. Didn't test or notice issues with any other options. 6.18 is still affected. My hopefully correct bisection points to: commit 28fe84da45bea7de56539b50eac8ebcec54342de Author: Alexandre Julliard <julliard(a)winehq.org> Date: Wed Mar 24 10:53:53 2021 +0100 ntdll: Load the main image from the Unix side. Steps to reproduce: 1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for winecfg and change it to use a virtual desktop. 4) Apply the change, close winecfg and restart it. Note how it's not using a virtual desktop. I'm not sure where the comment about the settings being global comes from, these options worked per-application before the listed commit. For example, on unaffected versions after step 4 above you would see winecfg use a virtual desktop, while notepad wouldn't use a virtual desktop. Even on affected versions the window manager decoration option works with per-application overrides. (You can have winecfg use WM decoration and have notepad use Wine decoration at the same time.) -- 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=51230 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #4 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I see possible issue with per application virtual desktop setting. Case A (multiple application using virtual desktop): 1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for winecfg and change it to use a virtual desktop. 4) Add a per-application override for notepad and change it to use a virtual desktop. 5) Apply the change, close winecfg and restart it. 6) Open another terminal and start notepad from same prefix. Case B (application spawning child application): 1) Create a new prefix with an affected Wine version. 2) Launch winecfg. 3) Add a per-application override for Steam (or a file manager) and change it to use a virtual desktop. 4) Apply the change, close winecfg and start Steam (or a file manager). 5) Launch a game from steam (or any other application, from the file manager). What do you expect from those scenario? A: One virtual desktop with both notepad and winecfg, or two independent virtual desktops? B: The main application in a virtual desktop and the other application managed by the WM, or both the main app and the child app in the same virtual desktop? My opinion is that having per application virtual desktop will cause more trouble/confusion for users than a simple all-or-nothing global virtual desktop setting. For DPI, i think that it doesn't matter if child/concurrent apps have different settings than the main app, so it makes sense to be a per-application setting like window decorations are. Regards. -- 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=51230 --- Comment #5 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Also, in case A, what about the size of the virtual desktop? Let say winecfg set a virtual desktop of 800x600 and notepad a virtual desktop of 1024x768? Regards. -- 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=51230 --- Comment #6 from subgraph93(a)gmail.com --- Scenario A: Two independent virtual desktops. I think all winecfg VD parameters are already stored in the registry as expected (and if I'm not mistaken, the program name is used as the VD name). The option to provide a common virtual desktop for two programs via command line parameters is still present, for example wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test,1024x768 winecfg and because the name "test" is the same, winecfg launches in the same virtual desktop. Scenario B: I think the actual behavior is that child processes of a process that uses a VD launch in the same VD. Example: wine explorer /desktop=test,1024x768 wineconsole (then in the console) notepad this will open notepad in the same virtual desktop. Virtual desktop sizes were (and I believe should be) independent, you could have wine explorer /desktop=test,1024x768 notepad wine explorer /desktop=test2,800x600 winecfg and it would launch two virtual desktops with different sizes -------- I believe you can set per-application settings in new (affected) versions and revert to an older (unaffected) version to see them work, which means the corresponding registry entries are stored as expected. I am not sure why it is being presented as if it were an intentional change. "Automatically capture the mouse in full-screen windows" is another regressed aspect. Another mitigation strategy could be to allow to set up all these options in command line parameters (like desktop, its name and size). Maybe some of them already exist as command line options (I only learned about /desktop relatively recently), but even if so, I don't know what they are. So the way I see it, there are several separate issues here: 1) Regression: the settings winecfg stores in the registry per-application aren't respected since 6.5 2) It's impossible to use just winecfg to set up a common virtual desktop for two separately launched programs 3) It's impossible to use winecfg or just about anything to force a child process out of its parent's virtual desktop 4) For advanced use cases, it's not clear whether it's possible to provide all winecfg option equivalents via command line parameters. Maybe they exist, but aren't prominently documented, or maybe they are missing. I believe the original issue reported (and the one I reported) is only [1]. [2] can be resolved with different launch commands, I personally don't know a use case for [3], and a use case for [4] could be a backup against issues like [1]. -- 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=51230 --- Comment #7 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I'm not saying that it is a change at all. I never knew that it worked like that, so, to me, it has always been global settings. I'm interested to see how that feature is implemented in the code and how it plays out in actual use. While the feature makes sense from a technical perspective, now I wonder what realistic scenario would depend on mixing WM managed windows with multiple virtual desktops of various sizes, or mixing DPI/capture mouse settings within the same prefix. I usually put each application in its own prefix and never met an application that had a dependency on another that had incompatible requirements in the settings. Do any of you happen to have such dependent applications with incompatible requirements? Otherwise, could you each explain your actual need for that feature? The problem is that the devs won't put effort into fixing this feature if there isn't a reasonable need for it. The fact that the feature existed at some point and is now broken won't be sufficient. They may even decide that it's too much effort to maintain and make the settings global. Regards. -- 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=51230 --- Comment #8 from subgraph93(a)gmail.com --- As for virtual desktops, in my personal experience, most programs either need a virtual desktop or don't have any requirements either way. Programs that absolutely must be outside a virtual desktop are not things I encountered. However, I'd say virtual desktops are necessarily more disruptive to user experience than WM-decorated windows (especially for windowed applications), and there are circumstances where having multiple programs per prefix is needed, sometimes even concurrently running (not to mention multi-program prefixes are usually not an issue, at least in my experience), so for multi-program prefixes I prefer to default to "no virtual desktop" and set virtual desktops only when needed. Unfortunately, apparently due to difficulties in adapting Windows "language" to non-Windows window systems, there are some input issues with Wine and multiple windows, such as clicks on one window passing through to another or not working at all if there's another window behind it. Most of the time virtual desktops help me work around them. Otherwise, my use case for VDs is mostly for games (especially older games) that behave weirdly without them. Sometimes it's older games that also do weird things with screen resolution, so they may even need to have special VD sizes. I don't have DPI requirements at all, so I can't comment about DPI. I don't have much information about when the mouse control feature needs to be on or off, except that it's useful to have it on in some games for proper input handling (sometimes only if the game is set to use virtual desktop, which is needed for unrelated reasons). As for feature removal, I am aware this is a hypothetical possibility in the abstract. Do you believe it's a practical possibility for this specific feature? Also, should the author of the commit that introduced the regression be added to the CC list? I'm kind of confused regarding what the answer to that is. -- 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=51230 --- Comment #9 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, I tested per-application virtual desktop with different sizes with wine 6.17 and it works like you described, but with a limitation. The per-application VD settings are recognized only if the full path is provided. I tested with: - VD disabled globally; - 800x600 VD for iexplore.exe (from C:\\Program Files\\Internet Explorer); - 1024x768 VD for winecfg.exe (from C:\\Windows\\System32); - 1200x900 VD for notepad.exe (from C:\\Windows); (I didn't test the other settings) Those settings were set from the winecfg GUI. Then I launched those, each in a different terminal, from the .\drive_c of the prefix: wine iexplore.exe → doesn't use VD winecfg → doesn't use VD wine notepad → doesn't use VD So I thought of a possible path matching issue, so I tried: wine C:\\Program\ Files\\Internet\ Explorer\\iexplore.exe → use 800x600 VD wine C:\\Windows\\System32\\winecfg.exe → use 1024x768 VD wine C:\\Windows\\notepad.exe → use 1200x900 VD I also tried with unix-style path with identical result. Then, I cd'ed each terminal in the executable directories and ran: wine iexplore.exe → use 800x600 VD wine winecfg.exe → use 1024x768 VD wine notepad.exe → use 1200x900 VD So, the path is not required when in the right directory. Then I tried the shorter commands: wine iexplore → doesn't use VD winecfg → use 1024x768 VD wine notepad → doesn't use VD So there is a problem when translating the path/name from the command-line to the one that would match the registry key. the winecfg command seems to be treated specially, as it behaves like wine winecfg.exe. I guess the /desktop option doesn't work for the same reason. Now I see in the commit diff that the logic that added ".exe" to a filename without '.' in get_image_path() was removed from ntdll/env.c. That may explain why 'wine whatever' doesn't match 'whatever.exe' since that commit. Regards. -- 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=51230 --- Comment #10 from subgraph93(a)gmail.com --- Thank you for the research. Unfortunately, it appears there was a bit of miscommunication: the /desktop option actually still works, I guess my comments just weren't clear enough about that. -- 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=51230 --- Comment #11 from Alexandre Julliard <julliard(a)winehq.org> --- When launching the app without a full path, we now launch it through start.exe, which is most likely why explorer doesn't match it to the app settings. explorer will require some extra magic to figure out the real exe name. -- 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=51230 --- Comment #12 from subgraph93(a)gmail.com --- There appears to be a staging-specific aspect, maybe (speculation) due to new start.exe-related changes in server-default_integrity in 6.9-staging. On 6.18-staging with that patchset not even full paths work, while a compiled version of 6.18-staging with "-W server-default_integrity" works with the full path (but still has the other aspects of this issue). Should I report the staging-specific aspect as a separate bug? -- 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=51230 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Component|-unknown |programs --- Comment #13 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, (In reply to subgraph93 from comment #10)
the /desktop option actually still works, I guess my comments just weren't clear enough about that.
Oh, that's right. I missed that. Wine doesn't have to lookup the name of the application as the desktop name is directly taken from the option. (In reply to subgraph93 from comment #12)
Should I report the staging-specific aspect as a separate bug?
Please, yes. It's better to separate staging bugs from upstream bugs. It's clearer and easier to track for the staging team. (In reply to Alexandre Julliard from comment #11)
When launching the app without a full path, we now launch it through start.exe, which is most likely why explorer doesn't match it to the app settings. explorer will require some extra magic to figure out the real exe name.
Marking the bug confirmed. Setting the affected component to 'programs'. Regards. -- 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=51230 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #14 from Zebediah Figura <z.figura12(a)gmail.com> --- Actually, in this case I don't think filing a new bug would help anything. The only thing wine-staging does differently is to start *all* new processes with start.exe, which I believe means that if the root cause of this bug is fixed, then it will be fixed for wine-staging as 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=51230 imecth(a)outlook.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |imecth(a)outlook.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=51230 Todd Chester <ToddAndMargo(a)zoho.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ToddAndMargo(a)zoho.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.
http://bugs.winehq.org/show_bug.cgi?id=51230 Zdeněk Kopřivík <zdenek.koprivik(a)post.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zdenek.koprivik(a)post.cz -- 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=51230 --- Comment #15 from Zdeněk Kopřivík <zdenek.koprivik(a)post.cz> --- Hello, I've just came here to create a bug report for per application "virtual desktop" option being broken, if the application is started via "wine start", but it seems you already know. In my case: wine Empires.exe -> launch Age of Empires in VD as expected wine start Empires.exe -> launch AoE without the VD -> broken You wanted a real world use case for a mixed VD settings, so here you are: I'm using system wide WINEPREFIX to launch most of my old games and some network management tools, mostly running the executables directly from Dolphin (which is using the "wine start" command). For old games without native "window mode" support and also without native FullHD resolution support, you'll get a black screen and a small rectangle with the game in the top left corner, because the game is not allowed to switch to its fullscreen resolution on wayland. So, for such games it is prefferable to use the VD to simulate windowed mode, but for the rest of my apps I prefer the default setting without VD. Until recently I've been using the same setup on my old PC with Wine 1.6 without any issues. Now I've upgraded the PC and updated my system and the same setting doesn't work anymore. -- 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