[PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
ppaalanen at gmail.com
Mon Jun 6 09:13:27 UTC 2022
On Fri, 3 Jun 2022 14:38:54 +0000
Zack Rusin <zackr at vmware.com> wrote:
> > On Jun 3, 2022, at 10:32 AM, Simon Ser <contact at emersion.fr> wrote:
> > ⚠ External Email
> > On Friday, June 3rd, 2022 at 16:27, Zack Rusin <zackr at vmware.com> wrote:
> >>> 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.
> >> I think Thomas expressed our concerns and reasons why those wouldn’t
> >> work for us back then. Is there something else you’d like to add?
> > I disagreed, and I don't understand Thomas' reasoning.
> > KMS clients will need an update to work correctly. Adding a new prop
> > without a cap leaves existing KMS clients broken. Adding a cap allows
> > both existing KMS clients and updated KMS clients to work correctly.
> I’m not sure what you mean here. They are broken right now. That’s
> what we’re fixing. That’s the reason why the virtualized drivers are
> on deny-lists for all atomic kms. So nothing needs to be updated. If
please, stop removing all email quoting level indicators, you have been
doing that a lot in your more recent replies. It makes reading the
emails really difficult, and I had to stop trying to make sense of the
It is really unfortunate that display servers have driver deny-lists
indeed. All the bug reports they got from being broken should have been
denied and forwarded to the respective drivers instead for breaking the
KMS UAPI. OTOH, I understand that some userspace projects do not want
to stop because of few broken but popular drivers.
> you have a kms client that was using virtualized drivers with atomic
> kms then mouse clicks never worked correctly. So, yes, clients need
> to set cursor hotspot if they want mouse to work correctly with
> virtualized drivers.
I'm very much agreeing with Simon. He has made similar questions and
comments that occurred to me.
Reading as much of the discussion between Simon and Zack as I could, it
seems every time Simon gets to the point, Zack hops to a completely
different use case to make Simon's argument no longer apply.
Like, root-window-less per-window remoting through KMS? How is that even
> >>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin zack at 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.
> >> Only some drivers require informations about cursor hotspot, user space
> >> currently has no way of figuring out which ones are those, i.e. amdgpu
> >> doesn’t care about hotspots, qxl does so when running on qxl without
> >> properly set cursor hotspot atomic kms will result in a desktop where
> >> mouse clicks have incorrect coordinates.
> >> There’s no way to differentiate between drivers that do not care about
> >> cursor hotspots and ones that absolutely require it.
> > Only VM drivers should expose the hotspot properties. Real drivers like
> > amdgpu must not expose it.
> Yes, that’s what I said. There’s no way to differentiate between
> amdgpu that doesn’t have those properties and virtio_gpu driver from
> a kernel before hotspot properties were added.
Why would userspace want to tell the difference between a driver that
truly does not need those properties, and a driver that did not add
those properties *yet*?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel