[Spice-devel] [PATCH] how can i trace monitor change (etc) events

[David Mansfield]

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