On 04/18/2014 01:01 PM, Marc-André Lureau wrote:
Hi
----- Original Message -----
(remote-viewer:12916): GSpice-WARNING **: FIXME: only support monitor
config with primary surface 0, but given config surface 5
Which seems suspicious to me, given that these are followed
immediately by incorrect behavior and don't happen in GNOME3.
Ok. This is worse than suspicious. It's the bug. In the source
gtk/spice-widget.c, right after this "FIXME" we goto "whole". Maybe a
guru can explain why we need to bail out here and display the whole
framebuffer on the second monitor *on purpose*. However, the following
patch works for me:
The code goto "whole" when the monitor configuration is invalid, because in this case, we don't know what to display, so we just display the "whole" primary surface 0.
Somebody needs to figure out why the monitor surface is 5, and if the server config is correct, then spice-gtk needs to learn to switch primary surfaces, which is currently not supported.
Can you explain briefly what a "surface" represents? How do multiple
surfaces get created in the first place? Is the primary surface (which
should be surface 0 I suppose) the "entire framebuffer" and the
secondary (non 0) surfaces are just subsections of it? Seems this must
have something to do with GNOME3 use of 3d engine to do compositing vs
MATE use of 2d and the fact that all of GNOME3 desktop is rendered
through dri.
Is there a way to dump the state of surfaces in spice (I assume these
"live" in spice-server at this point) periodically?
I'm happy to compile from source, run gdb debug c code etc, but I need
some direction.
Seems first question is:
Is this an issue only for spice-gtk (ie. client) or is there an actual
spice-server / qemu / qxl.ko / xorg-qxl bug?
--
Thanks,
David Mansfield
Cobite, INC
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel