------- Original Message ------- On Sunday, June 5th, 2022 at 17:47, Zack Rusin <zackr@xxxxxxxxxx> wrote: > > > Also, let me point this out because it also seems to be a fundamental > > > misunderstanding, user space implementing software cursor doesn’t fix > > > anything. Just leaves everything broken in different ways. The reason > > > virtualized drivers went away from software cursors is because it makes it > > > impossible to make it work with a bunch of interesting and desirable > > > scenarios, e.g. unity mode where the guest might have a terminal and browser > > > open and then the virtual machine software creates windows out of those, so > > > you don’t have the entire desktop of the guest but instead native looking > > > windows with the apps. In that case guest has no way of knowing when the > > > cursor leaves the window, so to make seemless cursors work you’d need to > > > implement irc or backdoors that send that information from the host to the > > > guest, then have virtualized drivers create some sort of uevent, to send to > > > the userspace to let it know to hide the cursor because it actually left the > > > window. That’s a trivial scenario and there’s a lot more with mice that are > > > remoted themselves, guests with singular or maybe many apps exported, > > > possibly overlapping on the host but all within a desktop in the guest, etc. > > > > Are you saying that the current broken behavior is better than software > > cursors? > > They’re broken in very different ways. You’re asking me which bugs do > I prefer. Ultimately the current lack of hotspots leaves mouse unusable > but I don’t see any reason to trade that for another set of bugs instead > of just fixing it (either via fallback to legacy or using the new hotspot > api). Software cursors aren't a bug. They're a fallback. > > > > > > 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. > > > > > > Iirc they all use it. > > > > What do they use it for? > > > > The whole point of this discussion is to be able to display the guest's cursor > > image on the host's cursor, so that latency is reduced? > > > Ah, I think I see now where the confusion is coming from. No, it’s > definitely not. This has nothing to do with latency. By default > position of a mouse cursor doesn’t tell us where the point that is > actually used as an activation of a click is, e.g. a mouse cursor image > with an arrow pointing to the top-left and a mouse cursor image pointing > to the bottom right - both at the same position, as you can imagine it will > become impossible to use the desktop if the click defaults to the top left, > especially as the number of cursor images increases, you need information > about which point within the cursor image activates the click, that’s the > hotspot. You need to know the position of the image and you need to know > which point within that image is responsible for actually activating the > events. Yeah, that's what a hotspot is. By "the whole point of this discussion", I meant that the whole point for VM drivers to expose a hardware cursor is to improve latency (and provide other related features). At any rate, I consider broken any driver which exposes a cursor plane, then doesn't display it exactly at the CRTC_X/CRTC_Y or misbehaves if it's missing hotspot info.
