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

Greg Sheremeta gshereme at redhat.com
Wed Apr 30 12:26:38 PDT 2014


I opened.

https://bugs.freedesktop.org/show_bug.cgi?id=78131

----- Original Message -----
> From: "Greg Sheremeta" <gshereme at redhat.com>
> To: "David Mansfield" <spice at dm.cobite.com>
> Cc: spice-devel at lists.freedesktop.org
> Sent: Monday, April 28, 2014 9:53:15 AM
> Subject: Re: [Spice-devel] [PATCH] how can i trace monitor	change	(etc)	events
> 
> Hi David,
> 
> Did you open a BZ for this yet? It'll help the issue get more visibility.
> 
> Thanks,
> Greg
> 
> ----- Original Message -----
> > From: "David Mansfield" <spice at dm.cobite.com>
> > To: spice-devel at lists.freedesktop.org
> > Sent: Wednesday, April 23, 2014 9:45:46 AM
> > Subject: Re: [Spice-devel] [PATCH] how can i trace monitor change	(etc)
> > 	events
> > 
> > 
> > On 04/21/2014 01:23 PM, David Mansfield wrote:
> > >
> > > On 04/21/2014 12:02 PM, Greg Sheremeta wrote:
> > >>>> In particular, with MATE we get a bunch of:
> > >>>>
> > >>>> (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:
> > >>>
> > >>> diff -ur spice-gtk-0.23.orig/gtk/spice-widget.c
> > >>> spice-gtk-0.23/gtk/spice-widget.c
> > >>> --- spice-gtk-0.23.orig/gtk/spice-widget.c    2014-02-06
> > >>> 06:07:13.000000000 -0500
> > >>> +++ spice-gtk-0.23/gtk/spice-widget.c    2014-04-17
> > >>> 16:46:20.204422442 -0400
> > >>> @@ -325,7 +325,7 @@
> > >>>    whole:
> > >>>        g_clear_pointer(&monitors, g_array_unref);
> > >>>        /* by display whole surface */
> > >>> -    update_area(display, 0, 0, d->width, d->height);
> > >>> +    update_area(display, c->x, c->y, c->width, c->height);
> > >>>       set_monitor_ready(display, true);
> > >>>   }
> > >>>
> > >>> Can someone explain why this would not be better than the currently
> > >>> broken behavior?
> > >>>
> > >>> Note that after this patch, the code above the 'goto' label and the
> > >>> code
> > >>> below are basically the same.
> > >>>
> > >>> It's very curious that running MATE in the VM triggers this but running
> > >>> GNOME3 does not, but nevertheless the bug is clearly in spice-gtk.
> > >>>
> > >>> --
> > >>> Thanks,
> > >>> David Mansfield
> > >>> Cobite, INC.
> > >> David, did you open a bug on this anywhere? I have the same problem
> > >> going on with LXDE. Cinnamon works great.
> > >>
> > >>
> > > I'm planning to open a fedora bug for it, but I'm doing a bit more
> > > debugging first in the client... I'm not certain I understand how the
> > > above change (which has serious problems) is working.  I'll send email
> > > to the list when I've got more figured out.
> > 
> > [ resent with gzipped logs ]
> > 
> > I have captured some logs, both from remote-viewer (--spice-debug) and
> > from qxl.ko (with drm.debug=14).  I have modified spice-gtk to log when
> > non-primary "canvas" is created (see attached patch), and BOTH gnome3
> > and mate create a secondary "canvas" with surface_id #2, however in MATE
> > case, this happens right before the monitor config events, and for
> > GNOME3 it happens after.  In both cases the secondary surface is exactly
> > the dimensions of the primary surface and happens after the primary
> > surface has changed size.
> > 
> > I have attached the logs.  The spice.log.* are the debug output from
> > remote-viewer (which was modified with the attached patch).  The dmesg.*
> > logs are the dmesg output in guest with drm.debug=14 set on kernel
> > command line.
> > 
> > Each test was performed on a freshly "powered on" machine. Login through
> > GDM into desktop of choice. Both are F20 host, F20 guest, F20 client
> > (modified).
> > 
> > If anyone else has any suggestions for progressing on this, I'd
> > appreciate it.
> > 
> > --
> > Thanks,
> > David Mansfield
> > Cobite, INC.
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Spice-devel mailing list
> > Spice-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/spice-devel
> > 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 


More information about the Spice-devel mailing list