Hi, On Tue, 14 Jun 2022 at 15:40, Zack Rusin <zackr@xxxxxxxxxx> 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
