All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Hans de Goede <hdegoede@redhat.com>
Cc: "Jonas Ådahl" <jadahl@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: Atomic KMS API lacks the ability to set cursor hot-spot coordinates
Date: Wed, 18 Mar 2020 16:09:53 +0100	[thread overview]
Message-ID: <CAKMK7uFo67jkgnDFb5Gs02CCkTVCe11ieqp6jeEZjJUjpF8Ssg@mail.gmail.com> (raw)
In-Reply-To: <9d86bbe4-70cf-273d-4d61-aec06011d441@redhat.com>

On Wed, Mar 18, 2020 at 3:29 PM Hans de Goede <hdegoede@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2020-03-18 15:10 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 14:28 Atomic KMS API lacks the ability to set cursor hot-spot coordinates Hans de Goede
2020-03-18 14:38 ` Simon Ser
2020-03-18 15:04   ` Hans de Goede
2020-03-18 15:22     ` Simon Ser
2020-03-19 11:35       ` Michel Dänzer
2020-03-19 11:52         ` Hans de Goede
2020-03-19 12:54           ` Pekka Paalanen
2020-03-19 13:51             ` Michel Dänzer
2020-03-19 14:48               ` Pekka Paalanen
2020-03-19 15:01                 ` Hans de Goede
2020-03-19  9:57   ` Pekka Paalanen
2020-03-19 10:00     ` Simon Ser
2020-03-18 14:39 ` Hans de Goede
2020-03-18 15:09 ` Daniel Vetter [this message]
2020-03-18 22:20   ` Hans de Goede
2020-03-19 10:00 ` Pekka Paalanen
2020-03-19 11:49   ` Hans de Goede
2020-03-19 12:58     ` Pekka Paalanen
2020-03-19 13:16       ` Daniel Vetter
2020-03-19 13:24         ` Simon Ser
2020-03-19 14:30       ` Hans de Goede
2020-03-19 15:16         ` Pekka Paalanen
2020-03-19 18:18           ` Hans de Goede
2020-03-19 20:14             ` Simon Ser
2020-03-19 20:49               ` Hans de Goede
2020-03-19 21:07                 ` Simon Ser
2020-03-19 22:57                   ` Thomas Hellström (VMware)
2020-03-20  9:13                     ` Pekka Paalanen
2020-03-20 10:59                       ` Thomas Hellström (VMware)
2020-03-20 11:27                         ` Simon Ser
2020-03-20 11:47                           ` Thomas Hellström (VMware)
2020-03-21  8:56                             ` Thomas Hellström (VMware)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKMK7uFo67jkgnDFb5Gs02CCkTVCe11ieqp6jeEZjJUjpF8Ssg@mail.gmail.com \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=jadahl@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.