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

[Michel Dänzer]

On 09/11/17 02:34 AM, Alex Goins wrote:
> On Wed, 8 Nov 2017, Michel Dänzer 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.
> 
> Yes, it's just left for the master screen the handle as if it were a hardware
> cursor.

Please provide an implementation of this as part of the series. In order
of my preference:

1. Make PixmapSyncDirtyHelper handle it automagically.

2. Add a helper function that drivers can call after
   PixmapSyncDirtyHelper.

I'm asking this to avoid ending up in a similar situation as with the
PRIME synchronization functionality, where it seems like the modesetting
driver still can't use it with itself as the peer.


>>> 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).
> 
> Really? I observe the same issue using mesa + modesetting + glamor + i915 +
> mutter. Dragging a window around with software cursor produces a square of
> corruption around the cursor.

That's a modesetting driver bug. It allows page flipping with SW cursor,
but that can't work correctly. At least xf86-video-amdgpu/ati don't have
this issue.


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