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

[David Mansfield]

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)

In reality, all surfaces (that are used in this context) have a non-zero 
surface_id inside qxl.ko. These two things seem to get confused.

> Hopefully Alon or Dave can shed some light here.
>
Yes, please!

-- 
Thanks,
David Mansfield
Cobite, INC.