[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS

[Albert Esteve]

On 6/10/22 10:59, Daniel Vetter wrote:
> On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> Kinda top post because the thread is sprawling and I think we need a
>> summary/restart. I think there's at least 3 issues here:
>>
>> - lack of hotspot property support, which means compositors can't really
>>    support hotspot with atomic. Which isn't entirely true, because you
>>    totally can use atomic for the primary planes/crtcs and the legacy
>>    cursor ioctls, but I understand that people might find that a bit silly :-)
>>
>>    Anyway this problme is solved by the patch set here, and I think results
>>    in some nice cleanups to boot.
>>
>> - the fact that cursors for virtual drivers are not planes, but really
>>    special things. Which just breaks the universal plane kms uapi. That
>>    part isn't solved, and I do agree with Simon and Pekka that we really
>>    should solve this before we unleash even more compositors onto the
>>    atomic paths of virtual drivers.
>>
>>    I think the simplest solution for this is:
>>    1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for these
>>    special cursor planes on all virtual drivers
>>    2. add the new "I understand virtual cursors planes" setparam, filter
>>    virtual cursor planes for userspace which doesn't set this (like we do
>>    right now if userspace doesn't set the universal plane mode)
>>    3. backport the above patches to all stable kernels
>>    4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
>>    and nothing else in the rebased patch series
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
> understanding of how this all works for commandeered cursors wrong?
>
>> - third issue: These special virtual display properties arent documented.
>>    Aside from hotspot there's also suggested X/Y and maybe other stuff. I
>>    have no idea what suggested X/Y does and what userspace should do with
>>    it. I think we need a new section for virtualized drivers which:
>>    - documents all the properties involved
>>    - documents the new cap for enabling virtual cursor planes
>>    - documents some of the key flows that compositors should implement for
>>      best experience
>>    - documents how exactly the user experience will degrade if compositors
>>      pretend it's just a normal kms driver (maybe put that into each of the
>>      special flows that a compositor ideally supports)
>>    - whatever other comments and gaps I've missed, I'm sure
>>      Simon/Pekka/others will chime in once the patch exists.
> Great bonus would be an igt which demonstrates these flows. With the
> interactive debug breakpoints to wait for resizing or whatever this should
> be all neatly possible.
> -Daniel

Hi all,

We have been testing the v2 of this patch and it works correctly for us.

First we tested with a patched Mutter, the mouse clicks were correct, 
and behavior was as expected.

But I've also added an IGT test as suggested above: 
https://gitlab.freedesktop.org/aesteve/igt-gpu-tools/-/compare/master...modeset-cursor-hotspot-test?from_project_id=1274

I could post the IGT patch upstream once Zack's patches land.

Hope that helps!

-Albert

>
>> There's a bit of fixing oopsies (virtualized drivers really shouldn't have
>> enabled universal planes for their cursors) and debt (all these properties
>> predate the push to document stuff so we need to fix that), but I don't
>> think it's too much. And I think, from reading the threads, that this
>> should cover everything?
>>
>> Anything I've missed? Or got completely wrong?
>>
>> Cheers, Daniel
>>
>> On Fri, Jun 03, 2022 at 02:14:59PM +0000, Simon Ser wrote:
>>> Hi,
>>>
>>> Please, read this thread:
>>> https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615
>>>
>>> It has a lot of information about the pitfalls of cursor hotspot and
>>> other things done by VM software.
>>>
>>> In particular: since the driver will ignore the KMS cursor plane
>>> position set by user-space, I don't think it's okay to just expose
>>> without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
>>>
>>> cc wayland-devel and Pekka for user-space feedback.
>>>
>>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin <zack at kde.org> wrote:
>>>
>>>> - all userspace code needs to hardcore a list of drivers which require
>>>> hotspots because there's no way to query from drm "does this driver
>>>> require hotspot"
>>> Can you elaborate? I'm not sure I understand what you mean here.
>>>
>>> Thanks,
>>>
>>> Simon
>> -- 
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch