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
