> Why do we want a kernel mouse module when the user one works
> except for minor glitches under load (fixable by using real
> time priority and locking options for those who care).
> it is not good to add code to the kernel just to handle a user
> input device that doesn't need it either.
Indeed, there are additional advantages in kmouse. It adds a software layer
between the hw device and the application, so that:
- the mouse is always bound to the current console: I can "cat /dev/kmouse"
in one console and still run selection on the other
- new devices (new protocols) can be decoded, and still appear the same on
/dev/kmouse and /dev/gpmctl (the gpm protocol, to run gpm clients)
- new protocols can be thought, 3d protocols or such, and old mice will speak
the new protocol when read from the new device.
In short, the different devices (/dev/kmouse, /dev/gpmctl and whatever new)
refer to the pointer, independently of the physical device. That's
a great win, in my opinion, for application programmers.
BTW: kmouse-0.40 is expected in a few days, supporting busmice and
stacking of extension modules.
Sorry for the noise in the list, but I couldn't resist :)
Regards
/alessandro
-- __ o La forza dei forti sta nel traversare le traversie con occhio sereno _`\<, (Paperino) __( )/( )__ alessandro rubini - rubini@ipvvis.unipv.it