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

Greg Sheremeta gshereme at redhat.com
Fri May 2 09:15:37 PDT 2014


I opened a BZ already, https://bugs.freedesktop.org/show_bug.cgi?id=78131

----- Original Message -----
> From: "David Mansfield" <spice at dm.cobite.com>
> To: spice-devel at lists.freedesktop.org
> Sent: Friday, May 2, 2014 8:52:04 AM
> Subject: Re: [Spice-devel] [PATCH] how can i trace monitor change	(etc)	events
> 
> 
> On 04/23/2014 09:45 AM, David Mansfield wrote:
> >
> > 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.
> >
> 
> FYI: I have been running with the attached patch (not the inline above)
> to spice-gtk for one week now, and so has my colleague.  Dual monitor
> works perfectly.  There is one other crash scenario (xorg in guest
> crashes and won't restart) which sometimes happens consistently upon
> logging in.  This can be "fixed" by removing the file
> ~/.config/monitors.xml (in the guest).
> 
> I recommend strongly that the attached fix be included. I understand it
> is a "band-aid" but so is "fixme: goto whole" (see source code) which is
> broken by definition.
> 
> I'm going to open a bug now on bugzilla with all my collected
> information - I can proceed no further with this without any assistance.
> 
> --
> Thanks,
> David Mansfield
> Cobite, INC.
> 
> 
> _______________________________________________
> 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