Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
Hi, Please, read this thread: https://lists.freedesktop.org/archives/dri-devel/2020-March/thread.html#259615 It has a lot of information about the pitfalls of cursor hotspot and other things done by VM software. 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. On Thursday, June 2nd, 2022 at 17:42, Zack Rusin 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. Thanks, Simon
XDC 2022: Registration & Call for Presentations still open!
Hello! This is just a reminder that the CFP for XDC in 2022 is still open! The 2022 X.Org Developers Conference is being held in conjunction with the 2022 Wine Developers Conference. This is a meeting to bring together developers working on all things open graphics (Linux kernel, Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine Project, a key consumer of open graphics. Registration & Call for Proposals are now open for both XDC 2022 and WineConf 2022, which will take place on October 4-6, 2022 in Minneapolis, Minnesota, USA. https://xdc2022.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! In order to register as attendee, you will therefore need to do it via the XDC website: https://indico.freedesktop.org/event/2/registrations/2/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2022. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://indico.freedesktop.org/event/2/abstracts/ The deadline for submissions is Monday July 4th, 2022. Check out our Reimbursement Policy to accept speaker expenses for X.Org events like XDC 2022: https://www.x.org/wiki/XorgFoundation/Policies/Reimbursement/ If you have any questions, please send me an email to x...@codeweavers.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/XOrgDevConf Best regards, Lyude Paul, on behalf of X.org -- Cheers, Lyude Paul (she/her) Software Engineer at Red Hat
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Friday, June 3rd, 2022 at 16:27, Zack Rusin 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 z...@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.
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Friday, June 3rd, 2022 at 16:38, Zack Rusin wrote: > > On Jun 3, 2022, at 10:32 AM, Simon Ser wrote: > > > > ⚠ External Email > > > > On Friday, June 3rd, 2022 at 16:27, Zack Rusin 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 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. My proposal was: - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better name). Only user-space which supports the hotspot props will enable it. - By default, don't expose a cursor plane, because current user-space doesn't support it (Weston might put a window in the cursor plane, and nobody can report hotspot). - If the KMS client enables the cap, advertise the cursor plane, and make it so the plane doesn't have the CRTC_X/CRTC_Y properties since the driver will pick the position. That way both old and new user-space are fixed. > >>> On Thursday, June 2nd, 2022 at 17:42, Zack Rusin z...@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. See cap proposal above.
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Friday, June 3rd, 2022 at 17:17, Zack Rusin wrote: > > > On Jun 3, 2022, at 10:56 AM, Simon Ser wrote: > > ⚠ External Email > > > > On Friday, June 3rd, 2022 at 16:38, Zack Rusin wrote: > > > > > > On Jun 3, 2022, at 10:32 AM, Simon Ser wrote: > > > > > > > > ⚠ External Email > > > > > > > > On Friday, June 3rd, 2022 at 16:27, Zack Rusin 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 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. > > > > My proposal was: > > > > - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better name). Only > > user-space which supports the hotspot props will enable it. > > - By default, don't expose a cursor plane, because current user-space > > doesn't > > support it (Weston might put a window in the cursor plane, and nobody can > > report hotspot). > > - If the KMS client enables the cap, advertise the cursor > > plane, and make it so the plane doesn't have the CRTC_X/CRTC_Y properties > > since the driver will pick the position. > > > > That way both old and new user-space are fixed. > > I don’t think I see how that fixes anything. In particular I don’t see a way > of fixing the old user space at all. We require hotspot info, old user space > doesn’t set it because there’s no way of setting it on atomic kms. Old atomic user-space is fixed by removing the cursor plane. Then old atomic user-space will fallback to drawing the cursor itself, e.g. via OpenGL. New user-space supports setting the hotspot prop, and is aware that it can't set the cursor plane position, so the cursor plane can be exposed again when the cap is enabled.
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Friday, June 3rd, 2022 at 17:32, Zack Rusin wrote: > > On Jun 3, 2022, at 11:22 AM, Simon Ser wrote: > > ⚠ External Email > > > > On Friday, June 3rd, 2022 at 17:17, Zack Rusin wrote: > > > > > > > > > > > > > > On Jun 3, 2022, at 10:56 AM, Simon Ser wrote: > > > > ⚠ External Email > > > > > > > > On Friday, June 3rd, 2022 at 16:38, Zack Rusin wrote: > > > > > > > > > > > > > > On Jun 3, 2022, at 10:32 AM, Simon Ser wrote: > > > > > > > > > > > > ⚠ External Email > > > > > > > > > > > > On Friday, June 3rd, 2022 at 16:27, Zack Rusin > > > > > > 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 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. > > > > > > > > > > > > My proposal was: > > > > > > > > - Introduce DRM_CLIENT_CAP_CURSOR_PLANE_NO_POSITION (or a better name). > > > > Only > > > > user-space which supports the hotspot props will enable it. > > > > - By default, don't expose a cursor plane, because current user-space > > > > doesn't > > > > support it (Weston might put a window in the cursor plane, and nobody > > > > can > > > > report hotspot). > > > > - If the KMS client enables the cap, advertise the cursor > > > > plane, and make it so the plane doesn't have the CRTC_X/CRTC_Y > > > > properties > > > > since the driver will pick the position. > > > > > > > > That way both old and new user-space are fixed. > > > > > > > > > I don’t think I see how that fixes anything. In particular I don’t see a > > > way > > > of fixing the old user space at all. We require hotspot info, old user > > > space > > > doesn’t set it because there’s no way of setting it on atomic kms. > > > > > > Old atomic user-space is fixed by removing the cursor plane. Then old > > atomic user-space will fallback to drawing the cursor itself, e.g. via > > OpenGL. > > But it’s not fixed, because the driver is still on a deny-list and > nothing implements this. You’re saying you could potentially “fix” by > implementing client side cursor handling in all kms clients? That’s a > hard sell if the user space can just put the virtualized driver on > deny-lists and fallback to use old kms which supports hotspots. What deny-list are you referring to? All compositors I know of implement a fallback when no cursor plane is usable. > > New user-space supports setting the hotspot prop, and is aware that it can't > > set the cursor plane position, so the cursor plane can be exposed again when > > the cap is enabled. > > But we still use cursor plane position. Hotspots are offsets from > cursor plane positions. Both are required. No, VM drivers don't need and disregard the cursor position AFAIK. They replace it with the host cursor's position. This is what breaks Weston, breaks uAPI expectations, and IMHO is unacceptable without KMS client opt-in.
