Hi,
Typically there is a communication path from guest to host for pointer movements (i.e. crtc_x + crtc_y updates), so the host knows where the guest wants the cursor plane being placed. So in case the pointer is moved by other means (different input device, some application warping the pointer, ...) the host can adapt.
Would it not be better to be explicit about it? To avoid fragile heuristics.
Explicit about what exactly? Whenever pointer warps via crtc_x + crtc_y update work or not? Not so easy ...
Nevertheless behavior is not consistent here because in some cases the feedback loop is not wired up end-to-end. The spice protocol has a message type for that, so pointer warps work. The vnc protocol has not, so they don't.
... for example qemu allows to enable both spice and vnc protocols.
It actually is a problem for multihead configurations though. Having some way to map input devices to scanouts would actually be helpful. Years ago I checked how this works for touchscreens to see whenever it is possible to leverage that for VMs somehow. There wasn't some obvious way, and I forgot the details meanwhile ...
Ah, that's the other way around, right? To tell guest OS which output an absolute input device is relative to?
Yes.
Having a standard for naming outputs is hard it seems, and there is also the connector vs. monitor dilemma. I guess absolute input devices would usually want to be associated with the (real or virtual) monitor regardless of which (real or virtual) connector it is connected to.
Yes, this should be linked to the monitor not the connector. qemu learned to generate edid blobs a while back, so we actually have virtual monitors and can create virtual monitor properties for them.
take care, Gerd