Re: [PATCH] winex11.drv: call XRRSetScreenSize when changing resolution
Oops, sorry, yes I did. How about the attached patch? It only calls XRRSetScreenSize if there's only one active CRTC. I've managed to scrounge another monitor now, and it works for me with both single and multiple monitors. On 20/11/14 13:19, Stefan Dösinger wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
Did you accidentally drop the wine-devel CC, or was this on purpose? I'd like to CC wine-devel on my reply but don't want to forward your mail without your consent.
Stefan
On 11/20/14 14:03, Mark Harmstone wrote:
Hi,
I tested this with KDE 4.14.3 and kwin 4.11.14, and it worked fine - if there's a KDE bug, it must have been fixed in the latest versions. I only have a single monitor to test with, though.
Setting crtc_info->x and crtc_info->y to 0 in XRRSetCrtcConfig does stop it from failing outright, but in my experience these are only non-zero when panning is already on. For the first resolution change, it won't prevent the drivers from going into panning mode, and won't (for instance) stop Icewind Dale from failing on startup on low resolutions.
Plus all this patch is doing is what xrandr is doing already - does that mean that xrandr also messes up multi-monitor setups, or would you need to pass it different arguments? And I'm not sure what the official Wine line is on this, but it seems to me sensible to prioritize simple common setups over complicated rare ones - I'm sure far more people use nvidia-drivers than have two monitors.
Mark
On 20/11/14 12:48, Stefan Dösinger wrote: On 11/20/14 13:11, Mark Harmstone wrote:
This changes xrandr12_set_current_mode so it behaves the same way as xrandr does in 1.2 mode (e.g, `xrandr --output HDMI-0 --crtc 0 --mode 640x480`). Before XRRSetCrtcConfig is called, the CRTC is temporarily disabled, then XRRSetScreenSize is called. (XRRSetCrtcConfig will fail if the CRTC isn't disabled first.) I've experimented with this a few weeks ago, and it drastically improves the usability of fullscreen applications on Metacity-based window managers. Unfortunately I'm afraid it is not quite that simple. It breaks KDE (may be a bug) and it breaks multi-monitor setups.
Testing on Windows (sorry, I did not write formal tests) shows that in single monitor setups the virtual screen size is adjusted to match the monitor's resolution when the resolution is changed. So the change is correct in single monitor setups, but needs tests.
In multi-monitor setups the virtual screen size is changed too, but it still takes both monitors into account. E.g. you had two monitors at 1920x1080, where one is to the right of the other. So you have a virtual screen of 3840x1080. If you change the res of the left monitor to 640x480 you get a virtual screen size of 2560x1080.
I hackily "fixed" the Nvidia panning bug by replacing crtc_info->x and crtc_info->y in pXRRSetCrtcConfig with 0, 0. That way the mode set succeeds and the CRTC is positioned correctly. The direct3d mouse grab takes care of the mouse moving outside the window, but only after clicking in the window once. The d3d grab is incorrect though as far as I can see. Windows doesn't grab the mouse in fullscreen d3d games in dual monitor setups.
Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the correct thing to do. It seems that the content of crtc_info->x and crtc_info->y depends on the mouse pointer location, which would be an odd thing for a mode change to depend on. May be an Nvidia bug.
Finally, there is a bug in all window managers forked from Metacity. If the new resolution is smaller in width or height than half the virtual screen size (= old resolution for single-monitor setups) then the WM places the window incorrectly. xwininfo reports where the window *should* be - at 0x0-WxH. But the real display location is something different, depending on the exact incarnation of the WM. In Unity it is shifted by 64x64 (unity bar I guess) and stretched to the virtual screen size. In MATE I think the window is centered. I suspect this is caused by the window positioning logic breaking. I have not been able to isolate the bug in the window manager code yet.
All in all I'm afraid we have a number of different bugs to fix in all Metacity forks, Wine, the Nvidia driver and maybe KDE.
Fwiw, KDE and FVWM place fullscreen windows properly. MATE and Unity also adjust their title bars and window maximization to match the new CRTC size, not the screen size.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJUbepaAAoJEN0/YqbEcdMwl0YP/2/QPABqbt3awjNBqQjAV7eA 0nH8AqvoaSCJ6Ecy3allYa8MC21RmyhK5mCa7e4yWnqTkOaOFCqgjnwPf7C1p7MO g/aGKsEFpHEM1YL1uvraKDVMeZGVXnSnE08eTrovNBvNvAhZn4Q/y6DZlOVjsJ44 djJA98/cYoditLcOVSmnqPv9hY85jQYTT2jduvZ7oMbRMhdjU5KZkyEMiCN83F/t iaY3IQfDzuoGBgH9/f+cSlNlNE8AJvXocJwOVfoW7FD/VU81N9jl5yMzujqEznos UquZ0CzBlyEWH7i0nxtjL/rfbc4giyF8aKByhSl9PS3k+DaKNsPtt6FWl4a/5+/i LJU4DQwdWFyQMtyR84kLvskPtNFB7ZNtzmPFvMtVBSziu0NvTGCEPTKKdPX+GgdP MiX3hSZFhkHzmoEEzfEGI0+j2Azj1RLi7xdVW/z/XIwhsPEd3dAytMaYWe8T05qI +ysOMuUGRz0tNVPSFiiO7FYcvsj4/o5la/fa0DbIh77GJvZqm8xHCHI6+Lf+Gx5N EurAoLaH+m8FTA5YRUoTKbxtVY/j+/B7LiTW5x53QcQH/Cb/B9Q2dcH5g/UGugDo eNm2ZFVqHkIRBa695sm4uTWZHj6RQUblBmLi2tIIdfIihiinZVDBci1CFua+Obsu p7VTdlbDMVuomwzPL7FA =DLsp -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-11-20 17:49, schrieb Mark Harmstone: > Oops, sorry, yes I did. > > How about the attached patch? It only calls XRRSetScreenSize if > there's only one active CRTC. I've managed to scrounge another > monitor now, and it works for me with both single and multiple > monitors. - From a usability point of view I'm for it, but (fortunately or unfortunately) this is not how we operate. Using such a workaround makes it less likely that the problem is fixed properly in a way that works on multi-monitor systems. To answer your previous points: On 11/20/14 14:03, Mark Harmstone wrote: > I tested this with KDE 4.14.3 and kwin 4.11.14, and it worked fine > - if there's a KDE bug, it must have been fixed in the latest > versions. I only have a single monitor to test with, though. I did not see a problem with my experimental hacks myself. Caron saw problems on KDE with some games. I've asked her if she remembers the details, and I'll grep my IRC logs. > Setting crtc_info->x and crtc_info->y to 0 in XRRSetCrtcConfig > does stop it from failing outright, but in my experience these are > only non-zero when panning is already on. For the first resolution > change, it won't prevent the drivers from going into panning mode, > and won't (for instance) stop Icewind Dale from failing on startup > on low resolutions. In which way does Icewind Dale fail? Thinking about it: What happens when the desktop is running at 640x480 and a game tries to set 1024x768 (and this is supported by the monitor). I'd expect this to fail with the current code, maybe this is what you mean with "Icewind Dale fails". > Plus all this patch is doing is what xrandr is doing already - > does that mean that xrandr also messes up multi-monitor setups, or > would you need to pass it different arguments? And I'm not sure > what the official Wine line is on this, but it seems to me sensible > to prioritize simple common setups over complicated rare ones - I'm > sure far more people use nvidia-drivers than have two monitors. This is a good question. I've experimented a bit with the xrandr command line tool and found it to be a pretty bad mess. Even if you don't pass - --q1 it handles the average mode setting cases with the Xrandr 1.0 functions. So it's either that different options are needed or that xrandr takes a different internal codepath. I'll have to do some tests again. Stefan > On 20/11/14 13:19, Stefan Dösinger wrote: Hi, > > Did you accidentally drop the wine-devel CC, or was this on > purpose? I'd like to CC wine-devel on my reply but don't want to > forward your mail without your consent. > > Stefan > > On 11/20/14 14:03, Mark Harmstone wrote: >>>> Hi, >>>> >>>> I tested this with KDE 4.14.3 and kwin 4.11.14, and it >>>> worked fine - if there's a KDE bug, it must have been fixed >>>> in the latest versions. I only have a single monitor to test >>>> with, though. >>>> >>>> Setting crtc_info->x and crtc_info->y to 0 in >>>> XRRSetCrtcConfig does stop it from failing outright, but in >>>> my experience these are only non-zero when panning is already >>>> on. For the first resolution change, it won't prevent the >>>> drivers from going into panning mode, and won't (for >>>> instance) stop Icewind Dale from failing on startup on low >>>> resolutions. >>>> >>>> Plus all this patch is doing is what xrandr is doing already >>>> - does that mean that xrandr also messes up multi-monitor >>>> setups, or would you need to pass it different arguments? And >>>> I'm not sure what the official Wine line is on this, but it >>>> seems to me sensible to prioritize simple common setups over >>>> complicated rare ones - I'm sure far more people use >>>> nvidia-drivers than have two monitors. >>>> >>>> Mark >>>> >>>> >>>> On 20/11/14 12:48, Stefan Dösinger wrote: On 11/20/14 13:11, >>>> Mark Harmstone wrote: >>>>>>> This changes xrandr12_set_current_mode so it behaves >>>>>>> the same way as xrandr does in 1.2 mode (e.g, `xrandr >>>>>>> --output HDMI-0 --crtc 0 --mode 640x480`). Before >>>>>>> XRRSetCrtcConfig is called, the CRTC is temporarily >>>>>>> disabled, then XRRSetScreenSize is called. >>>>>>> (XRRSetCrtcConfig will fail if the CRTC isn't disabled >>>>>>> first.) >>>> I've experimented with this a few weeks ago, and it >>>> drastically improves the usability of fullscreen applications >>>> on Metacity-based window managers. Unfortunately I'm afraid >>>> it is not quite that simple. It breaks KDE (may be a bug) and >>>> it breaks multi-monitor setups. >>>> >>>> Testing on Windows (sorry, I did not write formal tests) >>>> shows that in single monitor setups the virtual screen size >>>> is adjusted to match the monitor's resolution when the >>>> resolution is changed. So the change is correct in single >>>> monitor setups, but needs tests. >>>> >>>> In multi-monitor setups the virtual screen size is changed >>>> too, but it still takes both monitors into account. E.g. you >>>> had two monitors at 1920x1080, where one is to the right of >>>> the other. So you have a virtual screen of 3840x1080. If you >>>> change the res of the left monitor to 640x480 you get a >>>> virtual screen size of 2560x1080. >>>> >>>> I hackily "fixed" the Nvidia panning bug by replacing >>>> crtc_info->x and crtc_info->y in pXRRSetCrtcConfig with 0, >>>> 0. That way the mode set succeeds and the CRTC is positioned >>>> correctly. The direct3d mouse grab takes care of the mouse >>>> moving outside the window, but only after clicking in the >>>> window once. The d3d grab is incorrect though as far as I >>>> can see. Windows doesn't grab the mouse in fullscreen d3d >>>> games in dual monitor setups. >>>> >>>> Passing an offset of 0, 0 to pXRRSetCrtcConfig may be the >>>> correct thing to do. It seems that the content of >>>> crtc_info->x and crtc_info->y depends on the mouse pointer >>>> location, which would be an odd thing for a mode change to >>>> depend on. May be an Nvidia bug. >>>> >>>> Finally, there is a bug in all window managers forked from >>>> Metacity. If the new resolution is smaller in width or >>>> height than half the virtual screen size (= old resolution >>>> for single-monitor setups) then the WM places the window >>>> incorrectly. xwininfo reports where the window *should* be - >>>> at 0x0-WxH. But the real display location is something >>>> different, depending on the exact incarnation of the WM. In >>>> Unity it is shifted by 64x64 (unity bar I guess) and >>>> stretched to the virtual screen size. In MATE I think the >>>> window is centered. I suspect this is caused by the window >>>> positioning logic breaking. I have not been able to isolate >>>> the bug in the window manager code yet. >>>> >>>> All in all I'm afraid we have a number of different bugs to >>>> fix in all Metacity forks, Wine, the Nvidia driver and maybe >>>> KDE. >>>> >>>> Fwiw, KDE and FVWM place fullscreen windows properly. MATE >>>> and Unity also adjust their title bars and window >>>> maximization to match the new CRTC size, not the screen >>>> size. >>>> >>>>> >>>> > >> > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUbja3AAoJEN0/YqbEcdMwWagP/3wd0P4nmifoBdMk+ww6oPPN NctyL1cZzyAAKGlEzenu6W1UaCimEWbB4uy1qnCEv/vJSP6vn8cAD+5ry79jURWJ Oz98Uzefxih0cXVgru1MUcB2XQkq0eftOkCYVgl9zVqDSzcKWmJF/Adqowa9K6da 6FjtSsd/Xzi1HPe5xGyxXZ0oyKJdwwzyaYW7g+OWZMxgRSUu1jM1+MnWhSrmMirx fbiRUEK3az4ClLCVRT/d8zueePNK1YC4Dxz7uD/wo1KPW5W08C6JPft+YlLVv8XV 6MOHIZkBPH9anfBxWSe1cQUXDMwz5OaP4GXsTGO7LfgkIPw0S/Jg2OfNG53bddWN 8Owz6LlU6L8TXy0KRJEzJp4M53ML5yj32sEbiVTRq5CW0ZIaoB1sXd/W685ZDnjn 6eO0/zYBtDbEcekIKX5tN3Om5yEA/WM+nEuMz6W7lOo7DqzLvai2m5trf0SzlzA9 WhdqfgdnEoWwXm2RIRt7v7OSoikzUEZScqIQqUcJvVxC6tnlsRhg1R0Tva2Vl4h3 sqT7dsrMYbpcPxKc96nZqVg4sK3bYgTAjmcr+pJtyFxCRPWCBMP6LdTgGbzDdZHs mEgk3+KMydDt21ddDxKnyOdRa1kVRIbXGyQaqtOekwFR3EnIklTdd6Z4S8awkrWq Nwk2jDiUA0iT3LTWBoJH =rH6x -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I've done a bit more testing. As I suspected, increasing the resolution with Wine is indeed broken. With a single monitor set to 1024x768, running a d3d game in 1920x1080 sets the monitor to 1920x1080 but displays only the first 1024x768 pixels. The radeon driver doesn't enforce the monitor vs screen size restrictions properly, so we end up with this seemingly invalid configuration: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 DisplayPort-0 disconnected (normal left inverted right x axis y axis) HDMI-0 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.0*+ 50.0 50.0 50.0 59.9 I guess the Nvidia driver would abort with an error instead. For the rest of the testing I have attached a second monitor DVI-0. HDMI-0 1920x1080, absolute coordinate 0, 0. DVI-0 uses 1280x1024, right of HDMI-0. This gives a virtual screen size of 3200x1080. DVI-0 is at 1920x0 in absolute coordinates. When I change the resolution of HDMI-0 with xrandr --output HDMI-0 - --crtc 0 --mode 1024x768, DVI-0 stays at an absolute position of 1920x0. There is a gap between HDMI-0 and DVI-0 where windows and the mouse pointer can disappear. xrandr sets the screen dimensions to the smallest rectangle required for the active monitors, i.e. 3200x1024. (Down from 3200x1080). The logic for that appears to be in set_screen_size() in xrandr.c, in the "fit fb to output" path. KDE's screen setup tool uses the same logic as xrandr, but if you spend close attention to the preview you can see that it is going to create a gap between your monitors. Windows appears to use a slightly different logic. It changes the position of extra monitors to close the "gap" xrandr creates. The question is if we clone the behavior of Windows or the behavior of xrandr. From a testability point of view cloning the Windows behavior is probably better, but from a desktop integration point of view we may want to clone the xrandr behavior. With the xrandr behavior it is easier to restore the old screen setup once a fullscreen game exits. Writing tests for the single monitor case is the first step either way. A way to outsource the screen sizing logic would be nice - it would be nicer if we didn't have to bother about this. Stefan -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUcjWXAAoJEN0/YqbEcdMwUwcP/iJIR/NV7yEWhQs63lKkLHOw 3kek15ghTGgxqCvFugy9q9hzi3ulvVlS278p8jCQ39iWk3IUrGcDLk/7Cw9QwkSi q9QgqJJTuzRp7VsGJ+MdatLaUifcvxl0BfFNi5rrMePwfqOy0HwKRFIZGN1zSjgg FaC6EKN37ujlMi5f72FVtYH0R2O6v4ngPcd98TPSecSMs2bbRVpv3wnfq6qB5c8t WsnUKEWhFr+/74QoeyUYbWfvLNR7o3qVziBk0AI15V/8XhqomfK/oq3pNtHceqx+ hDn0JS0Xatrp0ZR1ToQs+fk5uo75QTbV5nFGE1RSSYrlawNAzhdfQkyXCdXVYRCt YEETDpSAyFMYBqqzcKsylfsfpQp2erLcKf1EvlyCZTWLm6JC6XL3l5YiJYoo/Y9a C/A1LF9MuqGOGRYexc9BAOu1wZbf5HEQcwJg2gfqM+2oL6+PPLkYZR/ahx9iFkKg d7nEmN7tVjof2TM2jNSJBmeh51AwS8CCw5Ro3ONZTGGioOCCyADMhFyI4uufD7M0 ReulEb88gNHRDCGmZiLYMZPu9fdE6xUOEYjaRTlttMKI6BKY68ClTWsfvFvxHG+t rmW2Wq7nRGV2RZ1o5rLWXSdSSti3ixo/k2RuqsEoPWA5VFTA/VyAMF3O6Yb3zS2J T2QR7BRqdSvfTcJuv2It =VvNQ -----END PGP SIGNATURE-----
participants (2)
-
Mark Harmstone -
Stefan Dösinger