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@xxxxxxxxxx> 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
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel