Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Mon, 13 Jun 2022 14:54:57 + Zack Rusin wrote: > On Mon, 2022-06-13 at 17:25 +0300, Pekka Paalanen wrote: > > On Mon, 13 Jun 2022 13:14:48 + > > Zack Rusin wrote: > > > > > On Mon, 2022-06-13 at 10:33 +0300, Pekka Paalanen wrote: > > > > On Fri, 10 Jun 2022 14:24:01 + > > > > Zack Rusin wrote: > > > > > > > > > On Fri, 2022-06-10 at 10:59 +0200, Daniel Vetter wrote: > > > > > > ⚠ External Email > > > > > > > > > > > > On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > Kinda top post because the thread is sprawling and I think we > > > > > > > need a > > > > > > > summary/restart. I think there's at least 3 issues here: > > > > > > > > > > > > > > - lack of hotspot property support, which means compositors can't > > > > > > > really > > > > > > > support hotspot with atomic. Which isn't entirely true, because > > > > > > > you > > > > > > > totally can use atomic for the primary planes/crtcs and the > > > > > > > legacy > > > > > > > cursor ioctls, but I understand that people might find that a > > > > > > > bit silly :-) > > > > > > > > > > > > > > Anyway this problme is solved by the patch set here, and I > > > > > > > think results > > > > > > > in some nice cleanups to boot. > > > > > > > > > > > > > > - the fact that cursors for virtual drivers are not planes, but > > > > > > > really > > > > > > > special things. Which just breaks the universal plane kms uapi. > > > > > > > That > > > > > > > part isn't solved, and I do agree with Simon and Pekka that we > > > > > > > really > > > > > > > should solve this before we unleash even more compositors onto > > > > > > > the > > > > > > > atomic paths of virtual drivers. > > > > > > > > > > > > > > I think the simplest solution for this is: > > > > > > > 1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for > > > > > > > these > > > > > > > special cursor planes on all virtual drivers > > > > > > > 2. add the new "I understand virtual cursors planes" setparam, > > > > > > > filter > > > > > > > virtual cursor planes for userspace which doesn't set this > > > > > > > (like we do > > > > > > > right now if userspace doesn't set the universal plane mode) > > > > > > > 3. backport the above patches to all stable kernels > > > > > > > 4. make sure the hotspot property is only set on VIRTUAL_CURSOR > > > > > > > planes > > > > > > > and nothing else in the rebased patch series > > > > > > > > > > > > Simon also mentioned on irc that these special planes must not > > > > > > expose the > > > > > > CRTC_X/Y property, since that doesn't really do much at all. Or is > > > > > > our > > > > > > understanding of how this all works for commandeered cursors wrong? > > > > > > > > > > > > > > > > Yes, that's the part I don't understand. I don't think I see how the > > > > > CRTC_X|Y > > > > > properties aren't used. > > > > > > > > > > I think the confusion might stem from the fact that it appears that > > > > > the > > > > > hypervisors/hosts are moving that plane, which is not the case. We > > > > > never move the > > > > > plane itself, we redirect the mouse focus/movement, that's what's > > > > > reducing the > > > > > latency but don't touch drm internals. I can't speak for every > > > > > virtualized stack, > > > > > but what is happening on ours is that we set the image that's on the > > > > > cursor plane as > > > > > the cursor on the machine that's running the guest. So when you move > > > > > the mouse > > > > > across the screen as you enter the VM window the cursor plane isn't > > > > > touched, but the > > > > > local machines cursor changes to what's inside the cursor plane. When > > > > > the mouse is > > > > > clicked the mouse device in the guest generates the event with the > > > > > proper > > > > > coordinates (hence we need the hotspot to route that event > > > > > correctly). That's when > > > > > the guest reacts just like it would normally on native if a mouse > > > > > event was > > > > > received. > > > > > > > > > > The actual cursor plane might not be visible while this is happening > > > > > but even when > > > > > it's not visible it's still at whatever crtc_x|y the guest thinks it > > > > > is. crtc_x|y > > > > > are still only driven by the guests mouse device. > > > > > > > > > > We control the mouse device and visibility of the cursor plane itself > > > > > based on > > > > > what's happening in the system but I don't think that's that > > > > > different from a native > > > > > system. > > > > > > > > Sorry Zack, while I'm sure that is technically correct and very detaily > > > > accurate, it's totally not any different to what we have been talking > > > > about all along. > > > > > > > > We care about how things look like to the end user, and not what > > > > property values the guest KMS driver might have for each plane. The KMS > > >
Re: [fdo] 504 to gitlab.freedesktop.org
https://www.phoronix.com/scan.php?page=news_item&px=FreeDesktop-GitLab-2022-Crash On Mon, Jun 13, 2022 at 9:40 AM Daniel Stone wrote: > On Mon, 13 Jun 2022 at 05:17, Peter Hutterer > wrote: > > On Sun, Jun 12, 2022 at 05:57:05PM -0700, Jeremy Sequoia wrote: > > > I was going to spend a little bit of time putting out an update to > XQuartz > > > to address a few bugs that I've been meaning to squash, but I'm having > a bit > > > of an issue pulling down sources. > > > > > > Fetching via ssh://g...@gitlab.freedesktop.org is giving me Permission > denied > > > (publickey,keyboard-interactive). I'm not sure if the latter is an > infra > > > issue or if the ssh key I have stored in my gitlab account are out of > date > > > (it's been about a year since I touched this). Unfortunately, I can't > seem > > > to access https://gitlab.freedesktop.org to check as it's constantly > > > presenting me a 504 Gateway timeout. > > > > > > Is anyone else able to pull sources via ssh:// > g...@gitlab.freedesktop.org > > > right now? Is someone looking into the 504 issue? > > > > not an fdo admin but judging by the chatter on #freedesktop: no and yes, > in > > that order. seems like the infrastructure is in various stages of > depositing > > fecal matter on itself and the fixes are involved enough that the admins > have > > to be mentally awake, not merely physically. > > Yes, that's what's happening. Our (multi-host-replicated etc) Ceph > storage setup has entered a degraded mode due to the loss of a couple > of disks - no data has been lost but the cluster is currently unhappy. > We're walking through fixing this, but have bumped into some other > issues since, including a newly-flaky network setup, and changes since > we last provisioned a new storage host. > > We're working through them one by one and will have the service back > up with all our data intact - hopefully in a matter of hours but we > have no firm ETA right now. > > Cheers, > Daniel >
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
On Tue, 2022-06-14 at 10:36 +0300, Pekka Paalanen wrote: > On Mon, 13 Jun 2022 14:54:57 + > Zack Rusin wrote: > > > On Mon, 2022-06-13 at 17:25 +0300, Pekka Paalanen wrote: > > > On Mon, 13 Jun 2022 13:14:48 + > > > Zack Rusin wrote: > > > > > > > On Mon, 2022-06-13 at 10:33 +0300, Pekka Paalanen wrote: > > > > > On Fri, 10 Jun 2022 14:24:01 + > > > > > Zack Rusin wrote: > > > > > > > > > > > On Fri, 2022-06-10 at 10:59 +0200, Daniel Vetter wrote: > > > > > > > ⚠ External Email > > > > > > > > > > > > > > On Fri, Jun 10, 2022 at 10:41:05AM +0200, Daniel Vetter wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Kinda top post because the thread is sprawling and I think we > > > > > > > > need a > > > > > > > > summary/restart. I think there's at least 3 issues here: > > > > > > > > > > > > > > > > - lack of hotspot property support, which means compositors > > > > > > > > can't really > > > > > > > > support hotspot with atomic. Which isn't entirely true, > > > > > > > > because you > > > > > > > > totally can use atomic for the primary planes/crtcs and the > > > > > > > > legacy > > > > > > > > cursor ioctls, but I understand that people might find that a > > > > > > > > bit silly :-) > > > > > > > > > > > > > > > > Anyway this problme is solved by the patch set here, and I > > > > > > > > think results > > > > > > > > in some nice cleanups to boot. > > > > > > > > > > > > > > > > - the fact that cursors for virtual drivers are not planes, but > > > > > > > > really > > > > > > > > special things. Which just breaks the universal plane kms > > > > > > > > uapi. That > > > > > > > > part isn't solved, and I do agree with Simon and Pekka that > > > > > > > > we really > > > > > > > > should solve this before we unleash even more compositors > > > > > > > > onto the > > > > > > > > atomic paths of virtual drivers. > > > > > > > > > > > > > > > > I think the simplest solution for this is: > > > > > > > > 1. add a new DRM_PLANE_TYPE_VIRTUAL_CURSOR, and set that for > > > > > > > > these > > > > > > > > special cursor planes on all virtual drivers > > > > > > > > 2. add the new "I understand virtual cursors planes" > > > > > > > > setparam, filter > > > > > > > > virtual cursor planes for userspace which doesn't set this > > > > > > > > (like we do > > > > > > > > right now if userspace doesn't set the universal plane mode) > > > > > > > > 3. backport the above patches to all stable kernels > > > > > > > > 4. make sure the hotspot property is only set on > > > > > > > > VIRTUAL_CURSOR planes > > > > > > > > and nothing else in the rebased patch series > > > > > > > > > > > > > > Simon also mentioned on irc that these special planes must not > > > > > > > expose the > > > > > > > CRTC_X/Y property, since that doesn't really do much at all. Or > > > > > > > is our > > > > > > > understanding of how this all works for commandeered cursors > > > > > > > wrong? > > > > > > > > > > > > Yes, that's the part I don't understand. I don't think I see how > > > > > > the CRTC_X|Y > > > > > > properties aren't used. > > > > > > > > > > > > I think the confusion might stem from the fact that it appears that > > > > > > the > > > > > > hypervisors/hosts are moving that plane, which is not the case. We > > > > > > never move the > > > > > > plane itself, we redirect the mouse focus/movement, that's what's > > > > > > reducing the > > > > > > latency but don't touch drm internals. I can't speak for every > > > > > > virtualized stack, > > > > > > but what is happening on ours is that we set the image that's on > > > > > > the cursor plane as > > > > > > the cursor on the machine that's running the guest. So when you > > > > > > move the mouse > > > > > > across the screen as you enter the VM window the cursor plane isn't > > > > > > touched, but the > > > > > > local machines cursor changes to what's inside the cursor plane. > > > > > > When the mouse is > > > > > > clicked the mouse device in the guest generates the event with the > > > > > > proper > > > > > > coordinates (hence we need the hotspot to route that event > > > > > > correctly). That's when > > > > > > the guest reacts just like it would normally on native if a mouse > > > > > > event was > > > > > > received. > > > > > > > > > > > > The actual cursor plane might not be visible while this is > > > > > > happening but even when > > > > > > it's not visible it's still at whatever crtc_x|y the guest thinks > > > > > > it is. crtc_x|y > > > > > > are still only driven by the guests mouse device. > > > > > > > > > > > > We control the mouse device and visibility of the cursor plane > > > > > > itself based on > > > > > > what's happening in the system but I don't think that's that > > > > > > different from a native > > > > > > system. > > > > > > > > > > Sorry Zack, while I'm sure that is technically correct and
Re: [PATCH 0/6] drm: Add mouse cursor hotspot support to atomic KMS
Hi, On Tue, 14 Jun 2022 at 15:40, Zack Rusin wrote: > On Tue, 2022-06-14 at 10:36 +0300, Pekka Paalanen wrote: > > The reason I am saying that you need to fix other issues with > > virtualized drivers at the same time is because those other issues are > > the sole and only reason why the driver would ever need hotspot info. > > > > Hotspot info must not be necessary for correct KMS operation, yet you > > seem to insist it is. You assume that cursor plane commandeering is ok > > to do. But it is not ok without adding the KMS UAPI that would allow > > it: a way for guest userspace to explicitly say that commandeering will > > be ok. > > > > If and only if guest userspace says commandeering is ok, then you can > > require hotspot info. On the other hand, you cannot retrofit hotspot > > info by saying that if a driver exposes hotspot properties then all KMS > > clients must set them. That would be a kernel regression by definition: > > KMS clients that used to abide the KMS UAPI contract are suddenly > > breaking the contract because the kernel changed the contract. > > > > Therefore I very much disagree that virtualized drivers need hotspot > > info. They do not strictly need hotspot info for correct operation, > > they need it only for making the user experience more smooth, which is > > an optional optimization. That optimization may be very important in > > practise, but it's still an optimization and is generally not expected > > by KMS clients. > > I strongly disagree with that (both the sentiment towards hotspots and the > client > handling of it). I don't think we have to agree on reasoning here at all to > make > progress though so I'm going to let it go (we can always continue on irc or > email if > you'd like to try to conclude this bit but we could all use a few days of > break from > this discussion probably). Well, it's just coming from two different directions: * many current KMS clients want the cursor plane to be displayed as the client-programmed plane properties indicate, and the output can be nonsensical if they aren't * VMware optimises the cursor by displaying the cursor plane not as the client-programmed plane properties indicate, and the output is sometimes good (faster response!) but sometimes bad (nonsensical display!) The client cap sounds good. As a further suggestion, given that universal planes are supposed to make planes, er, universal, rather than imbued with magical special behaviour, how about _also_ adding an 'is cursor' plane prop which userspace has to set to 1 to indicate that the output is a cursor and has the hotspot correctly set and the 'display hardware' is free to make the cursor fly around the screen in accordance with the input events it sends? That way it's really really clear what's happening and no-one's getting surprised when 'the right thing' doesn't happen, not least because it's really clear what 'the right thing' is. Cheers, Daniel
