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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-winex11.drv-call-XRRSetScreenSize-when-changing-reso.patch
Type: text/x-patch
Size: 3531 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20141120/7230a436/attachment.bin>