On Fri, 3 Jun 2022 14:38:54 +0000 Zack Rusin zackr@vmware.com wrote:
On Jun 3, 2022, at 10:32 AM, Simon Ser contact@emersion.fr wrote:
⚠ External Email
On Friday, June 3rd, 2022 at 16:27, Zack Rusin zackr@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
Hi Zack,
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 latest emails.
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 possible?
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.
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*?
Thanks, pq