On Saturday, June 4th, 2022 at 23:19, Hans de Goede <hdegoede@xxxxxxxxxx> 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.
