I opened. https://bugs.freedesktop.org/show_bug.cgi?id=78131 ----- Original Message ----- > From: "Greg Sheremeta" <gshereme@xxxxxxxxxx> > To: "David Mansfield" <spice@xxxxxxxxxxxxx> > Cc: spice-devel@xxxxxxxxxxxxxxxxxxxxx > Sent: Monday, April 28, 2014 9:53:15 AM > Subject: Re: [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@xxxxxxxxxxxxx> > > To: spice-devel@xxxxxxxxxxxxxxxxxxxxx > > Sent: Wednesday, April 23, 2014 9:45:46 AM > > Subject: Re: [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@xxxxxxxxxxxxxxxxxxxxx > > http://lists.freedesktop.org/mailman/listinfo/spice-devel > > > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel