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@xxxxxxx> 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
