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. > > 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.
