[PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

[Javier Martinez Canillas]

Pekka Paalanen <ppaalanen at gmail.com> writes:

Hello Pekka,

> On Wed, 28 Jun 2023 10:41:06 +0300
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
>> On Wed, 28 Jun 2023 01:21:27 -0400
>> Zack Rusin <zack at kde.org> wrote:
>> 
>> > From: Zack Rusin <zackr at vmware.com>
>> > 
>> > Atomic modesetting code lacked support for specifying mouse cursor
>> > hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
>> > the hotspot but the functionality was not implemented in the new atomic
>> > paths.
>> > 
>> > Due to the lack of hotspots in the atomic paths userspace compositors
>> > completely disable atomic modesetting for drivers that require it (i.e.
>> > all paravirtualized drivers).
>> > 
>> > This change adds hotspot properties to the atomic codepaths throughtout
>> > the DRM core and will allow enabling atomic modesetting for virtualized
>> > drivers in the userspace.
>> > 
>> > Signed-off-by: Zack Rusin <zackr at vmware.com>
>> > Cc: Maarten Lankhorst <maarten.lankhorst at linux.intel.com>
>> > Cc: Maxime Ripard <mripard at kernel.org>
>> > Cc: Thomas Zimmermann <tzimmermann at suse.de>
>> > Cc: David Airlie <airlied at linux.ie>
>> > Cc: Daniel Vetter <daniel at ffwll.ch>
>> > Reviewed-by: Javier Martinez Canillas <javierm at redhat.com>  
>> 
>> Hi Zack,
>> 
>> I still do not see any UAPI docs for the new properties in this patch?
>
> If you are wondering what there could be to write about, maybe this can
> give a good mindset:
>
> Let's assume that I am a Wayland compositor developer who has never used
> "hotspots" with KMS UAPI before. As I have never tested anything in a
> VM, I have no idea why the kernel would ever want to know about cursor
> hotspots. Display hardware never does anything with that, it just puts
> the cursor plane where I tell it to and composes a single image to be
> sent to the sink. The virtual driver VKMS does the same. To me, a
> cursor plane is just another universal plane that may have weird
> stacking order, pixel format, and size limitations.
>
> Ideally the doc for HOTSPOT_X and HOTSPOT_Y documents not only their
> possible existence and allowed/expected values, but also the reasons
> to have them and what they are used for, and that if the properties
> are exposed they are mandatory to program in order to use the plane.
>

Agreed with you that this documentation would be very useful. When I first
noticed that the virtio-gpu was in a deny list for atomic KMS, it took me
some time to understand that this was related to the lack of support for
cursor hotspots in the atomic API.

Another thing that could include this document is how user-space usually
deals with the lack of cursor hotspot properties in drivers that need it
(i.e: falling back to software cursor rendering as Weston does). And that
for this reason the cursor plane is disabled on these drivers, unless the
client advertises support for it with DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT.

I think though that this could be added as follow-up and not block this
series, which IMO are already in a good shape to be merged.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat