Just back from a nice relaxing holiday and, at first, I was totally perplexed by all this talk of the Xen “absolute pointer” problem. “It’s just VNC”, I thought, “it can’t be that hard. It must be just a simple bug somewhere”.
The background is:
- In Xen guests we have a “xenfb” driver, which acts just like a normal framebuffer device as far as the Xserver is concerned, but the contents of the framebuffer is exported to Dom0 via XenBus and shared memory.
- Similarly, we have a “xenkbd” driver, which takes input events from Dom0 and makes them available to the Xserver.
- In Dom0, we have a little daemon which acts as a VNC server. It exports the framebuffer contents from the guest and injects input events into the guest.
The problem here is that pointer motion events arrive at the Xserver as if they came directly from hardware. And just like normal mouse events, they are relative – i.e. you move your mouse up X amount and across Y amount.
This is unusual, because a VNC server receives motion events with absolute co-ordinates and can normally warp the pointer to those exact co-ordinates.
What we have might not be too bad – we might be able to reliably control the absolute pointer position in X by injecting events with relative co-ordinates – except that these events are subject to acceleration. If we try and move the pointer by injecting an event that says “move 100 pixels to the right”, the Xserver may accelerate that and move it, say, 200 pixels (with a ratio of 2/1). So, Pete’s first going to come up with a quick hack to disable acceleration.
It’s still stupid to try and move the pointer to an absolute position by injecting relative pointer motion events, though. The ideal solution is that the pointer device in the Xen guest behaves just like a grapics tablet. We would pass the absolute pointer co-ordinates to the guest and the driver would pass those on to the Xserver as though it was tablet device.
The problem with doing absolute events (okay, “problem”) is that we don’t have a good infrastructure for handling absolute events with virtually no configuration — for relative mice, you can use /dev/input/mice as your device, set the protocol to IMPS/2 and have nothing else to worry about.
To handle absolute event sources, you have to set up a separate pointer for each in the X config and handling of hotplugged devices is poor (nonexistent) as well.
Two things:
a) you can use evdev to send absolute pointer events, but you probably want the input-hotplug branch of xserver, as well as latest git master inputproto/libxi.
b) you should be able to just disable acceleration with xset, but otherwise you need to modify xf86PostMotionEvent in hw/xfree86/common/xf86Events.c.
Yeah, “xset m 1/1” worked like a charm for me. However, there’s a question of the initial position, so you have to press the pointer against the VNC window borders a few times before host and guest cursors align. Also, Dan Berrange reported that xset didn’t work for him, he still gets a scaled motion for some reason. No, I do not think that he ran xset on the host instead of guest, so it’s very mysterious.