Hi,
On 3/19/20 11:00 AM, Pekka Paalanen wrote:
On Wed, 18 Mar 2020 15:28:02 +0100
Hans de Goede <hdegoede@xxxxxxxxxx> 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.
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).
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.
Mutter used to do this, but mutter's internal API-s have been
reworked to closer match the atomic KMS API and as part of this
passing the hotspot coords was dropped, this is being fixed
for the legacy KMS API code-paths now (which atm are the only
code paths, atomic support has no landed yet):
https://gitlab.gnome.org/GNOME/mutter/merge_requests/1136
Regards,
Hans
1) 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
