> On Jun 5, 2022, at 12:26 PM, Simon Ser <contact@xxxxxxxxxxx> wrote: > > ------- 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. They work well, or usually well enough, on native but not with virtual machines. They break a lot of features. The nature of virtualization is that the guest doesn’t explicitly get access to a lot of host side info. If you move to software cursor you automatically lose all that info (unless, as I mentioned before, you rewrite hypervisors to push all that info to guests again, either via backdoors, irq or register accesses). Software cursor just doesn’t work with modern hypervisors well enough to be a reasonable replacement. >>>>>>> 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 But we do… The cursor is at crtc_x, crtc_y. > or misbehaves if it's missing hotspot info. That doesn’t follow at all. How can they not behave incorrectly if the information is missing? Maybe we can refocus the discussion because it seems like we’re moving in circles. Your proposal for a feature cap and removal of the cursor plane doesn’t fix anything: - current user space which doesn’t fallback to legacy kms with virtualized driver is completely broken and obviously will always remain broken on all already released kernels - making the same software fallback to software cursor breaks a massive amount of interactions in VMs so what are you proposing? z
