Re: how can i trace monitor change (etc) events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.


_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]