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