[PATCH xserver 3/3] ramdac: Handle master and slave cursors independently

[Michel Dänzer]

On 08/11/17 05:15 AM, Alex Goins wrote:
> Change 7b634067 added HW cursor support for PRIME by removing the
> pixmap_dirty_list check from xf86CursorSetCursor() and making the requisite
> cursor functions set/check the cursor both on master and slave.
> 
> However, before this change, drivers that did not make use of pixmap_dirty_list
> to implement PRIME master were able to pass this check. That may have been a
> bug, but in effect it allowed hardware cursor to be enabled with PRIME, where
> the master composites the cursor into the shared pixmap.
> 
> Naturally, the slave driving an actual hardware cursor is preferable to the
> master compositing a cursor into the shared pixmap, but there are certain
> situations where the slave cannot drive a hardware cursor (certain DRM drivers,
> or when used with a transform). In these cases the master may still be capable
> of compositing a cursor,

How and where exactly would this "compositing the cursor into the shared
pixmap" happen? Looks like this is just left for the master screen
driver to handle? If so, there probably needs to be a mechanism for the
master screen driver to opt into this.


> and that would be preferable to using the server's software cursor (due
> to the fact that it's unsynchronzied by OpenGL rendering to the root
> window, it can cause corruption with certain compositors).

Frankly, that sounds like an issue with your direct rendering
infrastructure. We used to have the same issue with DRI1, but no more
with DRI2/DRI3 (we still have an intermittent cursor flickering issue
though, but not corruption).


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer