With the changes I proposed in the "mouse movement speed" message,
the text mode cursor can be slowed down to the point where it is
controllable, but it still isn't ideal for a few reasons:
It is still anisotropic, with vertical movement feeling faster than
horizontal due to the aspect of the character cells.
It would be at drastically different "screen crossing speeds" in X
versus the console.
They could both be addressed by having wscons track the cursor
position in pixels, and divide by the font size whenever it needs to
get a character cell location. For a framebuffer based console that
would make the mouse feel identical in X and the console. A VGA
text console would still be a few times faster than a high res X
screen, but it would be 8x closer than it is today.
The drm framebuffer drivers might even choose to use a pixel
addressable cursor in text modes.
Even with that change, the console cursor would still feel strange
relative to a conventional graphics cursor.
Presumably in an attempt to mitigate the crazy-fast movement speed,
wsmoused applies a dubious scaling to the mouse deltas:
two_power = 1;
dy = abs(event->value);
while (dy > 2) {
two_power++;
dy = dy / 2;
}
event->value = event->value / (NORMALIZE_DIVISOR * two_power);
This is sort of an inverse-acceleration, where the faster you move,
the more it divides the value down. This has the problem of truncating
fractional residuals and scaling the axis unequally, but worse, it
makes the speeds not even monotonically increasing.
So, the cursor movements are too fast, anisotropic in steady speeds,
lose residuals, and have a non-monotonic, axial-biased speed profile.
I am very confident that removing the event normalization code in
wsmoused and doing the pixel based tracking in wscons will make a much
better cursor in general, but it is also likely that there will be
some users that have made themselves completely comfortable with the
current idiosyncratic behavior, and will be put off by any changes.
They could get the raw speed back by setting mouse.speed=8, but if
they switch back and forth to X it still won't be "the way it was".
If it was necessary to have a compatibility behavior flag, I would
rather see it in wsmoused than as a kernel mouse parameter.
