Hi ----- Original Message ----- > > On 05/08/2014 10:59 AM, Marc-André Lureau wrote: > > Hi > > > > Thanks a lot for your analysis so far! > > > > Adding David Airlie in CC > > > > ----- Original Message ----- > >> I have an explanation for this, but not a fix. The fix needs to be made > >> by the owner of this code (Alon or Dave according to the header!) > >> > >> The bug lies in qxl_display.c:qxl_crtc_mode_set. In this method, there > >> is a conditional termed "recreate_primary". The logic for this is based > >> on qcrtc->index. In other words, the "recreate_primary" branch is taken > >> only on the first head. In this case, the surface_id is FORCED to 0, > >> and for all other heads, the actual surface_id is used. > >> > >> However, no _actual_ surface_id's are 0. See above. All surfaces > >> (valid for this context) have surface_id >0. So it is IMPOSSIBLE for > >> the monitor_config for the second monitor to have surface_id = 0. > > Ok > > > >> So you may be asking yourself (or me) - so how is it working (in > >> gnome3)? Well, that is funny. It's just "working by coincidence" for > >> gnome3, but broken by design. > >> > >> Here's how that works. When the bo is created, it _initially_ gets > >> surface_id = 0. The actual surface id (assigned by qxl_bo_check_id) > >> isn't assigned until the qxl_update_area_ioctl is called (by userspace). > > (there seems to be other paths to get surface checked/allocated, > > with the qxl_release stuff. But I have no idea how this works) > > > >> In gnome3, this ioctl is called AFTER setting the mode on the 2nd > >> monitor, so the second branch above which returns the "actual" > >> surface_id still returns 0 because the surface hasn't been "checked" > >> (whatever that means). In MATE and other xrandr environments, the ioctl > >> is called right BEFORE setting the mode, so the actual surface_id is > >> assigned and we get the trap in spice-widget.c (which I have worked > >> around). > >> > >> Thoughts? > >> > > How come gnome3 (and mate) draw correctly all the monitors on the surface 0 > > (that's the only things spice-gtk shows, even with your patch), since the > > crtc seems to be associated with a different surface?.. > AFACT, there's no such thing as surface 0, at least not in qxl.ko. > That's a fabrication used to connote two completely different things. > surface_id = 0 can mean: > > - a "bo" that hasn't been "checked" yet > - a substitute for the actual surface_id when "primary" is trying to > be conveyed to downstream (spice-server/spice-widget) It seems to me surface 0 is the primary surface, it is associated with crtc 0 (kernel and userspace). In xf86-video-qxl, crtc_resize() allocates a primary surface with the _whole virtual size_, on crtc 0. In drmmode_set_mode_major(), all crtc seems to share the same primary fb (except when rotated?): fb_id = drmmode->fb_id; if (drmmode_crtc->rotate_fb_id) { fb_id = drmmode_crtc->rotate_fb_id; x = y = 0; } ret = drmModeSetCrtc(drmmode->fd, drmmode_crtc->mode_crtc->crtc_id, fb_id, x, y, output_ids, output_count, &kmode); That would explain why the surface 0 has the right size, and the right content. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel