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.