[ Adding the dri-devel list back, please keep it in Cc when following up ]
On 11/13/25 18:21, rat marrow wrote: >> The choices you're describing are mostly up to the Wayland compositor. > > I suppose I worded that wrong, but you understood where I was getting to. I > meant having this functionality available for Wayland compositors to expose > control for. Many of those choices are independent of any new KMS functionality. >> Instead, I'm proposing a HW_DONE_DEADLINE CRTC property, which the >> compositor can use to minimize cursor latency. See >> https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4540 >> <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4540> , which also >> references the kernel changes. >> >> (Speaking to AMD developers, apparently my assumption that AMD GPUs can >> reflect cursor position changes while a frame is being scanned out was >> wrong, in which case this should allow getting cursor latency very close to >> Xorg, certainly within a millisecond) > > Very comforting knowing you've shared similar latency concerns, I was > starting to think myself crazy! (Or, /crazier.../) > > I really hope more eyes get put on > https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4540 > <https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/4540> , because from > where I am standing, that is a very promising proposal. > > This may again be my short-sightedness around the technicalities of this all, > but for posterity sake: all of this work on Mutter specifically /does/ have > general application across the compositor space as a whole? Other compositors will need to implement something similar. Note that in mutter, this is just a minor optimization for the existing deadline-based cursor handling on the KMS thread, shaving off ~500µs of latency. If a compositor doesn't have something like the latter yet, the new CRTC property on its own is unlikely to be useful. -- Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer https://redhat.com \ Libre software enthusiast
