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

[Simon Ser]

On Saturday, June 4th, 2022 at 23:19, Hans de Goede <hdegoede at redhat.com> wrote:

> >>> My proposal was:
> >>>
> >>> - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better name). Only
> >>> user-space which supports the hotspot props will enable it.
> >>> - By default, don't expose a cursor plane, because current user-space doesn't
> >>> support it (Weston might put a window in the cursor plane, and nobody can
> >>> report hotspot).
> >>> - If the KMS client enables the cap, advertise the cursor
> >>> plane, and make it so the plane doesn't have the CRTC_X/CRTC_Y properties
> >>> since the driver will pick the position.
> >>>
> >>> That way both old and new user-space are fixed.
> >>
> >> I don’t think I see how that fixes anything. In particular I don’t see a way
> >> of fixing the old user space at all. We require hotspot info, old user space
> >> doesn’t set it because there’s no way of setting it on atomic kms.
> >
> > Old atomic user-space is fixed by removing the cursor plane. Then old
> > atomic user-space will fallback to drawing the cursor itself, e.g. via
> > OpenGL.
>
> That is just a terrible idea, the current situation is that userspace has a
> hardcoded list of drivers which need hotspots, so it uses the old non-atomic
> APIs on that "hw" since the atomic APIs don't support hotspots.

*Some* user-space does this (Mutter, KWin). There is also user-space which
doesn't (Weston, wlroots).

> The downsides I see to your proposal are:
>
> 1. Falling back to sw cursor rendering instead of using the old APIs would
> be a pretty significant regression in user experience. I know that in theory
> sw rendering can be made to not flicker, but in practice it tends to be a
> flickery mess.

Old Mutter/KWin with the deny-lists cannot be updated and will still use the
legacy uAPI. New Muter/KWin with support for atomic hotspot will not need a
deny-list anymore. No breakage here.

> 2. It does not help anything since userspace is still hardcoded to use
> the old, hotspot aware non-atomic API anyways. So it would only make things
> worse since hiding the cursorplane for userspace which does not set the CAP
> would mean the the old non-atomic API also stops working. Or this would add
> extra complications in the kernel to still keep the old APIs working.

The cursor plane would only be hidden when user-space has enabled
DRM_CAP_UNIVERSAL_PLANES. IOW, user-space only supporting the legacy uAPI will
still work as it does today.