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

Thu Nov 20 06:48:27 CST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.