From: Albert Esteve <aesteve@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>, Simon Ser <contact@emersion.fr>
Cc: krastevm@vmware.com, David Airlie <airlied@linux.ie>,
javierm@redhat.com, dri-devel@lists.freedesktop.org,
Gurchetan Singh <gurchetansingh@chromium.org>,
Hans de Goede <hdegoede@redhat.com>,
Pekka Paalanen <ppaalanen@gmail.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
wayland-devel <wayland-devel@lists.freedesktop.org>,
mombasawalam@vmware.com
Subject: Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
Date: Fri, 9 Jun 2023 17:20:13 +0200 [thread overview]
Message-ID: <3ef205a7-f418-e22d-6bae-7be08f60d2f8@redhat.com> (raw)
In-Reply-To: <YqMH14MEqGZtujfk@phenom.ffwll.local>
On 6/10/22 10:59, Daniel Vetter wrote:
> On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote:
>> Hi all,
>>
>> Kinda top post because the thread is sprawling and I think we need a
>> summary/restart. I think there's at least 3 issues here:
>>
>> - lack of hotspot property support, which means compositors can't really
>> support hotspot with atomic. Which isn't entirely true, because you
>> totally can use atomic for the primary planes/crtcs and the legacy
>> cursor ioctls, but I understand that people might find that a bit silly :-)
>>
>> Anyway this problme is solved by the patch set here, and I think results
>> in some nice cleanups to boot.
>>
>> - the fact that cursors for virtual drivers are not planes, but really
>> special things. Which just breaks the universal plane kms uapi. That
>> part isn't solved, and I do agree with Simon and Pekka that we really
>> should solve this before we unleash even more compositors onto the
>> atomic paths of virtual drivers.
>>
>> I think the simplest solution for this is:
>> 1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for these
>> special cursor planes on all virtual drivers
>> 2. add the new "I understand virtual cursors planes" setparam, filter
>> virtual cursor planes for userspace which doesn't set this (like we do
>> right now if userspace doesn't set the universal plane mode)
>> 3. backport the above patches to all stable kernels
>> 4. make sure the hotspot property is only set on VIRTUAL_CURSOR planes
>> and nothing else in the rebased patch series
> Simon also mentioned on irc that these special planes must not expose the
> CRTC_X/Y property, since that doesn't really do much at all. Or is our
> understanding of how this all works for commandeered cursors wrong?
>
>> - third issue: These special virtual display properties arent documented.
>> Aside from hotspot there's also suggested X/Y and maybe other stuff. I
>> have no idea what suggested X/Y does and what userspace should do with
>> it. I think we need a new section for virtualized drivers which:
>> - documents all the properties involved
>> - documents the new cap for enabling virtual cursor planes
>> - documents some of the key flows that compositors should implement for
>> best experience
>> - documents how exactly the user experience will degrade if compositors
>> pretend it's just a normal kms driver (maybe put that into each of the
>> special flows that a compositor ideally supports)
>> - whatever other comments and gaps I've missed, I'm sure
>> Simon/Pekka/others will chime in once the patch exists.
> Great bonus would be an igt which demonstrates these flows. With the
> interactive debug breakpoints to wait for resizing or whatever this should
> be all neatly possible.
> -Daniel
Hi all,
We have been testing the v2 of this patch and it works correctly for us.
First we tested with a patched Mutter, the mouse clicks were correct,
and behavior was as expected.
But I've also added an IGT test as suggested above:
https://gitlab.freedesktop.org/aesteve/igt-gpu-tools/-/compare/master...modeset-cursor-hotspot-test?from_project_id=1274
I could post the IGT patch upstream once Zack's patches land.
Hope that helps!
-Albert
>
>> There's a bit of fixing oopsies (virtualized drivers really shouldn't have
>> enabled universal planes for their cursors) and debt (all these properties
>> predate the push to document stuff so we need to fix that), but I don't
>> think it's too much. And I think, from reading the threads, that this
>> should cover everything?
>>
>> Anything I've missed? Or got completely wrong?
>>
>> Cheers, Daniel
>>
>> On Fri, Jun 03, 2022 at 02:14:59PM +0000, Simon Ser wrote:
>>> Hi,
>>>
>>> Please, read this thread:
>>> https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615
>>>
>>> It has a lot of information about the pitfalls of cursor hotspot and
>>> other things done by VM software.
>>>
>>> In particular: since the driver will ignore the KMS cursor plane
>>> position set by user-space, I don't think it's okay to just expose
>>> without opt-in from user-space (e.g. with a DRM_CLIENT_CAP).
>>>
>>> cc wayland-devel and Pekka for user-space feedback.
>>>
>>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin <zack@kde.org> wrote:
>>>
>>>> - all userspace code needs to hardcore a list of drivers which require
>>>> hotspots because there's no way to query from drm "does this driver
>>>> require hotspot"
>>> Can you elaborate? I'm not sure I understand what you mean here.
>>>
>>> Thanks,
>>>
>>> Simon
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
next prev parent reply other threads:[~2023-06-09 15:23 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 15:42 [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS Zack Rusin
2022-06-02 15:42 ` [PATCH 1/6] drm/atomic: Add support for mouse hotspots Zack Rusin
2022-06-02 15:42 ` [PATCH 2/6] drm/vmwgfx: Create mouse hotspot properties on cursor planes Zack Rusin
2022-06-03 13:11 ` Martin Krastev (VMware)
2022-06-02 15:42 ` [PATCH 3/6] drm/qxl: " Zack Rusin
2022-06-02 22:05 ` kernel test robot
2022-06-02 23:26 ` kernel test robot
2022-06-02 15:42 ` [PATCH 4/6] drm/vboxvideo: " Zack Rusin
2022-06-02 15:42 ` [PATCH 5/6] drm/virtio: " Zack Rusin
2022-06-02 15:42 ` [PATCH 6/6] drm: Remove legacy cursor hotspot code Zack Rusin
2022-06-03 10:28 ` [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS Gerd Hoffmann
2022-06-03 14:43 ` Zack Rusin
2022-06-03 14:14 ` Simon Ser
2022-06-03 14:27 ` Zack Rusin
2022-06-03 14:32 ` Simon Ser
2022-06-03 14:38 ` Zack Rusin
2022-06-03 14:56 ` Simon Ser
2022-06-03 15:17 ` Zack Rusin
2022-06-03 15:22 ` Simon Ser
2022-06-03 15:32 ` Zack Rusin
2022-06-03 15:49 ` Simon Ser
2022-06-03 18:31 ` Zack Rusin
2022-06-05 7:30 ` Simon Ser
2022-06-05 15:47 ` Zack Rusin
2022-06-05 16:26 ` Simon Ser
2022-06-05 18:16 ` Zack Rusin
2022-06-06 8:11 ` Simon Ser
2022-06-04 21:19 ` Hans de Goede
2022-06-05 7:34 ` Simon Ser
2022-06-07 11:25 ` Gerd Hoffmann
2022-06-06 9:13 ` Pekka Paalanen
2022-06-07 8:07 ` Pekka Paalanen
2022-06-07 14:30 ` Gerd Hoffmann
2022-06-08 7:53 ` Pekka Paalanen
2022-06-08 14:52 ` Gerd Hoffmann
2022-06-07 17:50 ` Zack Rusin
2022-06-08 7:53 ` Pekka Paalanen
2022-06-09 19:39 ` Zack Rusin
2022-06-10 7:49 ` Pekka Paalanen
2022-06-10 8:22 ` Jonas Ådahl
2022-06-10 8:54 ` Simon Ser
2022-06-10 9:01 ` Daniel Vetter
2022-06-10 8:41 ` Daniel Vetter
2022-06-10 8:56 ` Pekka Paalanen
2022-06-10 8:59 ` Daniel Vetter
2022-06-10 12:03 ` Gerd Hoffmann
2022-06-10 14:24 ` Zack Rusin
2022-06-13 7:33 ` Pekka Paalanen
2022-06-13 13:14 ` Zack Rusin
2022-06-13 14:25 ` Pekka Paalanen
2022-06-13 14:54 ` Zack Rusin
2022-06-14 7:36 ` Pekka Paalanen
2022-06-14 14:40 ` Zack Rusin
2022-06-14 14:54 ` Daniel Stone
2023-06-09 15:20 ` Albert Esteve [this message]
2023-06-21 7:10 ` Javier Martinez Canillas
2023-06-22 4:29 ` Zack Rusin
2023-06-22 6:20 ` Javier Martinez Canillas
2022-06-10 9:15 ` Simon Ser
2022-06-10 9:49 ` Daniel Vetter
2022-06-10 12:36 ` Gerd Hoffmann
2022-06-10 12:53 ` Simon Ser
2022-06-11 15:34 ` Hans de Goede
2022-06-13 7:45 ` Pekka Paalanen
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=3ef205a7-f418-e22d-6bae-7be08f60d2f8@redhat.com \
--to=aesteve@redhat.com \
--cc=airlied@linux.ie \
--cc=contact@emersion.fr \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=hdegoede@redhat.com \
--cc=javierm@redhat.com \
--cc=krastevm@vmware.com \
--cc=kraxel@redhat.com \
--cc=mombasawalam@vmware.com \
--cc=ppaalanen@gmail.com \
--cc=tzimmermann@suse.de \
--cc=wayland-devel@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).