On Fri, 3 Jun 2022 14:38:54 +0000 Zack Rusin <zackr@xxxxxxxxxx> wrote: > > On Jun 3, 2022, at 10:32 AM, Simon Ser <contact@xxxxxxxxxxx> wrote: > > > > ⚠ External Email > > > > On Friday, June 3rd, 2022 at 16:27, Zack Rusin <zackr@xxxxxxxxxx> 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@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. > >> > >> 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
Attachment:
pgpEf2Ifg90pv.pgp
Description: OpenPGP digital signature
