The problem
-----------

Almost no graphical desktop translates mouse motions to pointer movements
with a constant factor. You can try it: Just move your mouse over a certain
distance, first very short, then very fast. You will realize that the
pointer travelled different distances.

The idea
--------

As QEmu not only gets mouse input, but also displays graphical output, we
can track the pointer via software. If the pointer does not change its shape,
and nothing else happens, we need only track the bounding box of the change.

What is in the rfb patch right now?
-----------------------------------

After a few gdb sessions I was convinced that there is not much difference
between different OSes (or better: their mouse handling). I found out that
both Linux and Windows98 translate mouse movements one to one, up until
a certain value, where they are translated one to two, i.e. the pointer
travels twice as fast as the mouse. This certain value is 4 with Linux,
and 3 with Windows 98. One more complication: With Linux, if either x or
y movement reaches the threshold, both are multiplied by two; Windows 98
does not do that, but treats them separately.

So I introduced a calibration which just moves the cursor a little upward
and a little to the left, in order to test where the threshold lies, and
if the two axis are connected or not.

My original plan
----------------

So if we avoid certain motions by splitting them into two, we can support
both Windows98 and Linux without calibration. Perfect!

But then came Windows XP. Of course, like every Windows version,
Microsoft changes every other aspect, often breaking things. I don't know
yet exactly how it works, but there is no chance in hell you can get
Windows XP in QEmu via VNC working without a calibration.

The plan
--------

The whole point is to wiggle the pointer in a very small region, so as to
not touch any icon or whatever (and thus trigger animations or selections).
When the first movement was recorded, the shape of the pointer can be
analyzed (the bounding box should be sufficient).

One thing which helps: if the screen borders are not touched, the same
motions being replayed in reverse order and reverse direction should
yield the original position again. Maybe we also have to wait a little
for the OS to react...

A bit more detailed: I want to build an array real[x][y] which tells you
how many pixels the pointer travels when a certain motion is triggered.
The tests should be done forward/backward, so that the pointer stays more
or less at the same point on the screen. After each calibration step,
the guest OS is given some cycles to give a feedback.

After the calibration, everytime we get a motion, the closest real[x][y]
is looked up and sent to the guest OS, and the difference to what we wanted
will be handled in the next cycle.