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

[Marc-André Lureau]

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.