Hi, On 6/3/22 17:22, Simon Ser wrote: > On Friday, June 3rd, 2022 at 17:17, Zack Rusin <zackr@xxxxxxxxxx> wrote: > >> >>> On Jun 3, 2022, at 10:56 AM, Simon Ser <contact@xxxxxxxxxxx> wrote: >>> ⚠ External Email >>> >>> On Friday, June 3rd, 2022 at 16:38, Zack Rusin <zackr@xxxxxxxxxx> wrote: >>> >>>>> On Jun 3, 2022, at 10:32 AM, Simon Ser <contact@xxxxxxxxxxx> wrote: >>>>> >>>>> ⚠ External Email >>>>> >>>>> On Friday, June 3rd, 2022 at 16:27, Zack Rusin <zackr@xxxxxxxxxx> wrote: >>>>> >>>>>>> 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. >>>>>> >>>>>> I think Thomas expressed our concerns and reasons why those wouldn’t >>>>>> work for us back then. Is there something else you’d like to add? >>>>> >>>>> I disagreed, and I don't understand Thomas' reasoning. >>>>> >>>>> KMS clients will need an update to work correctly. Adding a new prop >>>>> without a cap leaves existing KMS clients broken. Adding a cap allows >>>>> both existing KMS clients and updated KMS clients to work correctly. >>>> >>>> I’m not sure what you mean here. They are broken right now. That’s what we’re >>>> fixing. That’s the reason why the virtualized drivers are on deny-lists for >>>> all atomic kms. So nothing needs to be updated. If you have a kms client that >>>> was using virtualized drivers with atomic kms then mouse clicks never worked >>>> correctly. >>>> >>>> So, yes, clients need to set cursor hotspot if they want mouse to work >>>> correctly with virtualized drivers. >>> >>> 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. 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. 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. I do think that a CAP might be a good idea, but the disabling of the cursor plane based on the CAP does not sound like a good idea to me. Regards, Hans
