[PATCH] winex11.drv: call XRRSetScreenSize when changing resolution

[Stefan Dösinger]

-----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-----