Atomic KMS API lacks the ability to set cursor hot-spot coordinates

[Daniel Vetter]

On Wed, Mar 18, 2020 at 3:29 PM Hans de Goede <hdegoede at redhat.com> wrote:
>
> Hi All,
>
> I'm not sure if $subject was a conscious design decision, or an oversight,
> but that does not really matter.
>
> ATM the Atomic KMS API lacks the ability to set cursor hot-spot
> coordinates. Mutter (and Weston) have tried to emulate this by shifting
> the coordinates for where to draw the cursor by the hotspot-coordinates
> and always using 0x0 for the hotspot.
>
> But this breaks the so called "seamless mouse mode" for virtual-machines
> and there really is no way to fix this but to allow passing the proper
> hotspot coordinates to the virtual gfx-card.

Fully aware, we simply never had userspace for this. So
- type weston patch
- type kernel patch (iirc this might be some work of moving the
hotspot coordinates from struct drm_plane to drm_plane_state)
- wire up atomic property (it'd just do "CURSOR_HOT_X/Y" and be done
with it, only attached to cursor planes that support it ofc)
- I think all drivers supporting vm cursor hotspot are now atomic, so
would be good to garbage-collect the old legacy infrastructure
completely. legacy cursor ioctl will remap to the atomic call
transparently like we do now already for everything else
- type igt
- get it all reviewed and merged.

0 design reasons for omitting this, simply Not Yet Done (tm).

Cheers, Daniel

> Seamless-mode consists of 2 parts:
>
> 1) Letting the VM-viewer window-system draw the cursor as it normally
> would draw it.
>
> 2) Giving absolute coordinates of the mouse to the VM by e.g. emulating
> an USB drawing tablet. These coordinates come from translating the
> coordinates where the VM-viewer window-system is drawing the cursor
> to an absolute position using the top left corner of the view as 0x0
> and the bottom right corner as max-abs-x,max-abs-y.
>
> 2) Means that any coordinates the window-system inside the VM passes to
> the VM's gfx-card for where to draw the cursor are basically totally
> ignored to avoid lag / flicker (and to not have to grab the cursor /
> confine it to the VM-viewer window and to not have to warp the
> pointer).
>
> This means that the offset added to the coordinates by e.g. mutter to
> emulate the hotspot are ignored. For Seamless mouse mode to keep working
> properly the window-system inside the VM need to pass the VM's gfx-card
> the correct hotspot when setting the cursor. Which currently is not
> possible when restricting oneself to the atomic APIs.
>
> Also see: https://gitlab.gnome.org/GNOME/mutter/issues/1094
> Where this is currently being tracked from the mutter side. Mutter
> internally has both atomic and legacy paths. The plan for now is to
> push the hotspot-emulation by shifting coordinates thing into the
> atomic path, fixing seamless mouse mode when running in legacy mode,
> combined with blacklisting vboxvideo, vmwgfx, qxl and cirrus from
> using atomic mode.
>
> This is of course a workaround, eventually we would like to see
> the atomic API extended to allow passing the cursor hot spot.
>
> I'm not really familiar enough with the atomic API to come up with
> an API design for this, but if there are suggestions on how this
> should look like from the uAPI side then I can take a shot at
> implementing this (and hooking it up in mutter's atomic code
> paths to test it).
>
> Regards,
>
> Hans
>
>
>
> p.s.
>
> Before people start discussing how the VM / VM-viewer is broken here and
> the VM needs to be fixed. Seamless mouse mode exists for at least a
> decade and has worked fine during this entire decade. It also works
> fine when using the legacy (non atomic) DRM_IOCTL_MODE_CURSOR2 ioctl;
>
> Also this problem reproduces with 2 completely independent VM code-bases,
> it has been seen on both qemu-kvm VMs and on VirtualBox VMs and I would
> not be surprised if other hypervisors are also affected.
>
> And on the API consumer side this problem has been triggered by both
> mutter and Weston.
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch