[Spice-devel] New xrandr multi-mon / arbitrary resolution support issues

[Hans de Goede]

Hi,

On 08/27/2012 09:36 AM, Marc-André Lureau wrote:
> On Sun, Aug 26, 2012 at 5:29 PM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>> On 08/26/2012 03:48 PM, Hans de Goede wrote:
>>>
>>> Hi,
>>>
>>> As part of integrating the spice-vdagent xrandr patches
>>> (done, as there were many other patches pending, so fixes
>>> can just be applied on top), I've been testing the new
>>> xrandr multi-mon / arbitrary resolution support.
>>>
>>> With single monitor setups, things work fine, but with
>>> multiple monitor setups things don't work as advertised.
>>>
>>
>> Ok, so the problem was thatI thought that all changes except for
>> the xorg-x11-drv-qxl changes were upstream, and thus having the latest
>> master from all was enough, that is not the case, I needed to
>> pull in the qemu changes, then all the problems I was seeing are
>> gone, but instead there are some new ones:
>>
>> 1) when enabling a new display through remote-viewer the initial
>> resolution is no good, it should be something sensible, maybe the
>> same size as the existing display?
>
> What is sensible?

Well anything would be better then the current default for a new
display which seems to be "stamped-size". A more sensible default
would be 1024x768, as that is what the guest drivers default to if
nothing is specified, so what the primary display window defaults
to more or less. As said another option would be to make it the
same size as the primary display window.

> Can you explain your reasoning?

The current behavior (very small window) sucks, sorry I've no better
way to describe it. We must be able to come up with something better.

>> 2) When using --full-screen=auto-conf both windows get shown
>> on the same real monitor, so the user in essence sees only one
>> as they cover eachother, also to match, they both get
>> send to the guest as being 1920x1080+0+0 for both, making the
>> guest think they are in clone mode, even if you leave fullscreen,
>> and reposition the windows to have one on each monitor
>
> I suppose the client has multiple monitors.

Yes my main workstation has 2 monitors now a days (a change I initially
made mainly for spice testing, but it is really nice in general, so
I can advice using 2 monitors in general, and we've hardware budget ...

> That might be a bug (we
> have similar issues with existing code), I will try to look at it.

Great, thanks!

>> 3) When making resolution changes from within the guest,
>> remote-viewer resizes then sends a resolution change event to
>> the guest, which can lead to getting another resolution then
>> requested. I believe that remote-viewer should not send
>> monitorinfo messages when receiving a resize over the display
>> channel.
>
> There are 2 schools:
> 1. allow window resizing, in which case, the guest can reconfigure the
> window size any time (can lead to very large windows, or intermittent
> resizes etc.)
 >
> 2. never resize client window automatically, and avoid scaling: the
> client will try to resize-guest whenever it doesn't fit well
>
> In general, the GNOME guideline follows 2: only the user is managing
> the windows size.

What we are currently doing in remote-viewer seems to be a mix of
the 2, and I think that is a good idea, since things like for
example SDL-games running fullscreen will change the guest
resolution to say 800x600, and then expect it to change that way,
so currently, with us resizing the window to 800x600 when this
happens, things will work (until the user resizes the display ...).

>
> However, I think we should improve the fullscreen case, and allow
> scaling when the guest change resolution. But it will be more
> difficult to deal with cases where user switches between window and
> fullscreen, as we will have to try to restore the same resolution
> somehow.

Yes, the SDl-game example will break currently in fullscreen mode,
what we should do in fullscreen mode IMHO is:

1) remember the window size
2) send a monitorsconfig message when going fullscreen, and don't
send any other monitorsconfig messages while we are fullscreen
3) when leaving fullscreen see if the resolution of the guest ==
the resolution we send in 2, if it is restore the window size,
if it is not, size the window to match the current guest resolution.

Regards,

Hans





>