All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Paalanen <ppaalanen@gmail.com>
To: Zack Rusin <zackr@vmware.com>
Cc: "mripard@kernel.org" <mripard@kernel.org>,
	"airlied@linux.ie" <airlied@linux.ie>,
	"javierm@redhat.com" <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	Martin Krastev <krastevm@vmware.com>,
	Michael Banack <banackm@vmware.com>,
	"tzimmermann@suse.de" <tzimmermann@suse.de>,
	Ian Forbes <iforbes@vmware.com>,
	Maaz Mombasawala <mombasawalam@vmware.com>
Subject: Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots
Date: Thu, 29 Jun 2023 11:16:45 +0300	[thread overview]
Message-ID: <20230629111645.01611176@eldfell> (raw)
In-Reply-To: <9e7a97481d17439f81cf1126e497bf720638c5f0.camel@vmware.com>

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Wed, 28 Jun 2023 16:26:37 +0000
Zack Rusin <zackr@vmware.com> wrote:

> On Wed, 2023-06-28 at 14:15 +0000, Simon Ser wrote:
> > I think we should drop the CRTC_X/CRTC_Y properties for hotspot-aware cursor
> > planes.
> > The drivers aren't going to do anything with these, and exposing them to user-
> > space
> > makes it sound like user-space controls the position of the plane, but it really
> > doesn't.  
> 
> I think we talked about this before. The CRTC_X/CRTC_Y properties are absolutely
> being used and they're respected when the rendering is done guest-side - the system
> will be pretty broken if the client sets the crtc x/y properties to somewhere where
> the mouse isn't though.

Right, but it would be useful to hear more about the "why".

> An argument could be made that crtc x/y properties should be removed on the cursor
> plane in drivers for para-virtualized hardware and instead replaced with
> mouse_position x/y properties that do exactly what crtc x/y properties do but make
> it explicit what they really are on a cursor plane.

I suppose this is needed to support the guest OS warping the cursor position
while the viewer has a relative-motion pointer locked to it?

When the pointer is not locked to the VM viewer window, the pointer
sends absolute motion events? Which is necessary for the roundtrip
elision that the hotspot is needed for in the first place.

Btw. this is somewhat conflicting with what you wrote as the first UAPI
doc draft. I don't see how the viewer/host could independently position
the cursor image if the related pointer device is not also delivering
absolute motion events in the guest. Delivering relative motion events
would cause the guest and host opinion of pointer position to drift
apart primarily due to different acceleration curves.


Thanks,
pq

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-06-29  8:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28  5:21 [PATCH v4 0/8] Fix cursor planes with virtualized drivers Zack Rusin
2023-06-28  5:21 ` [PATCH v4 1/8] drm: Disable the cursor plane on atomic contexts " Zack Rusin
2023-06-28  5:21   ` Zack Rusin
2023-06-28  5:21 ` [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots Zack Rusin
2023-06-28  7:41   ` Pekka Paalanen
2023-06-28  7:54     ` Pekka Paalanen
2023-06-28  8:30       ` Javier Martinez Canillas
2023-06-28 19:54       ` Zack Rusin
2023-06-29  8:03         ` Pekka Paalanen
2023-07-03 21:06           ` Michael Banack
2023-07-04  8:08             ` Pekka Paalanen
2023-07-05 16:08               ` Michael Banack
2023-07-06  8:01                 ` Pekka Paalanen
2023-07-06 16:23                   ` Michael Banack
2023-07-07  8:38                     ` Pekka Paalanen
2023-07-07 20:54                       ` Michael Banack
2023-07-10  8:17                         ` Pekka Paalanen
2023-07-10 17:46                           ` Michael Banack
2023-07-11  7:14                             ` Pekka Paalanen
2023-07-18  8:41                               ` Javier Martinez Canillas
2023-07-18  9:27                                 ` Javier Martinez Canillas
2023-07-18  9:56                                 ` Pekka Paalanen
2023-06-28 14:15   ` Simon Ser
2023-06-28 16:26     ` Zack Rusin
2023-06-29  8:16       ` Pekka Paalanen [this message]
2023-07-03 21:15         ` Michael Banack
2023-06-28  5:21 ` [PATCH v4 3/8] drm/vmwgfx: Use the hotspot properties from cursor planes Zack Rusin
2023-06-28  5:21 ` [PATCH v4 4/8] drm/qxl: " Zack Rusin
2023-06-28  5:21 ` [PATCH v4 5/8] drm/vboxvideo: " Zack Rusin
2023-06-28  5:21 ` [PATCH v4 6/8] drm/virtio: " Zack Rusin
2023-06-28  5:21 ` [PATCH v4 7/8] drm: Remove legacy cursor hotspot code Zack Rusin
2023-06-28  5:21 ` [PATCH v4 8/8] drm: Introduce DRM_CLIENT_CAP_CURSOR_PLANE_HOTSPOT Zack Rusin

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=20230629111645.01611176@eldfell \
    --to=ppaalanen@gmail.com \
    --cc=airlied@linux.ie \
    --cc=banackm@vmware.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=iforbes@vmware.com \
    --cc=javierm@redhat.com \
    --cc=krastevm@vmware.com \
    --cc=mombasawalam@vmware.com \
    --cc=mripard@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=zackr@vmware.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.