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

[Daniel Vetter]

On Thu, Mar 19, 2020 at 1:58 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 19 Mar 2020 12:49:27 +0100
> Hans de Goede <hdegoede at redhat.com> wrote:
>
> > Hi,
> >
> > On 3/19/20 11:00 AM, Pekka Paalanen wrote:
> > > On Wed, 18 Mar 2020 15:28:02 +0100
> > > Hans de Goede <hdegoede at redhat.com> wrote:
> > >
> > >> 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.
> > >>
> > >> 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.
> > >
> > > Hi,
> > >
> > > is the VM-viewer then hiding or autonomously moving what the display
> > > server inside VM has put on the KMS cursor plane?
> >
> > Yes and no, it is not the VM-viewer which is hiding what the
> > display-server inside the VM has put on the KMS cursor plane,
> > the VM-viewer negotiates seamless mouse mode with the hypervisor
> > and then the hypervisor just ignores the cursor-plane except for
> > sending "sprite" changes to the VM-viewer.
>
> Hi,
>
> I don't think I understand what you're saying, but I assume that I was
> right in that the VM cursor plane content will not be shown always
> exactly in the very position the compositor inside the VM puts it.
> Maybe the example further below explain the issue I envision.
>
> > > If so, sounds like hilarity would ensue with Weston.
> > >
> > > Weston does not actually know what a cursor is. Weston will happily put
> > > any arbitrary non-cursor content onto the KMS cursor plane if it happens
> > > to fit. It's just that usually there is a small surface top-most that
> > > ends up on the cursor plane, and that surface accidentally happens to
> > > be a cursor by Wayland protocol.
> > >
> > > It's not difficult to get e.g. weston-simple-shm window to be shown on
> > > the KMS cursor plane: just hide the real cursor from the client.
> > >
> > > No, it's not an oversight. It is called "making maximal use of the
> > > available KMS resources" by using KMS planes as much as possible to
> > > avoid compositing by rendering with Pixman or OpenGL.
> >
> > Yes it sounds like this will break with Weston, note that it already
> > is broken in Weston, if you run e.g. Fedora 32 beta + its Weston
> > package inside a VirtualBox VM then start gnome-terminal (so
> > that you get a caret cursor instead of the default one) and try to
> > select text. This will result in the wrong text being displayed
> > because Weston does not relay cursor hotspot info to the GPU,
> > also see:
> > https://gitlab.gnome.org/GNOME/mutter/issues/1094
> >
> > Where the symptoms of this are described in more detail
> > (they are identical for Weston and mutter).
>
> Right, that's the problem with the hotspot.
>
> > Fixing this will require the discussed KMS atomic API changes
> > and also changes on the Weston and mutter side to pass through
> > the hotspot info.
>
> The problem I am referring to is that to the user looking at the
> VM-viewer, suddenly an arbitrary application window (e.g.
> weston-simple-shm) starts to act as if it was the cursor, when there is
> no real cursor shown. You have a random window unexpectedly moving
> around, as if you had started dragging it around with your mouse.
>
> The only way to fix that is to stop Weston from putting non-cursor
> content on the cursor plane.
>
> It sounds like your VM-viewer makes the assumption that the pointer
> input device it delivers to the VM is the one that will control the KMS
> cursor plane position inside the VM. Is that right?
>
> What if the desktop inside the VM is controlled by a remote, e.g. VNC?
> Then the input events to the VM are completely unrelated to the
> expected motion of the cursor. Do you just tell the users to stop using
> the seamless mode in that case?
>
> What if display servers stop using the cursor plane completely, because
> people may hit a case where a VM-viewer makes the wrong assumption about
> which input device is associated to which cursor plane inside the VM?

Hm that sounds like we should have an additional flag with atomic that
enables/disables the hotspot functionality. Then compositors can
decide what they want to do with that thing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch