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

[Michel Dänzer]

On 09/11/17 03:06 PM, Hans de Goede wrote:
> On 09-11-17 02:34, Alex Goins wrote:
>> On Wed, 8 Nov 2017, Hans de Goede wrote:
>>
>>>> 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.
>>
>> In any case, I would like some means to bring back the pre-7b634067
>> functionality. In situations such as using UDL as a slave, it appears
>> as a
>> regression. An opt-in mechanism for drivers that support master-driven
>> cursor is
>> acceptable, I think. I'll follow up with a new patch set implementing the
>> feedback so far if you agree.
> 
> I'll leave further discussion of this between you and Michel Däzner. FWIW
> I do believe that Michel's suggestion to implement the master-driven cursor
> overlay in some generic place so it works with all the drivers is a better
> solution then allowing drivers to opt-out.

Unfortunately, that's not really possible, because at least
xf86-video-intel doesn't use PixmapSyncDirtyHelper. So even if that is
made to handle this transparently, there needs to be an opt-in mechanism.


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