Messages in this thread |  | | From | rubini@pop ... | Subject | Re: wish list | Date | Tue, 14 May 1996 12:06:29 +0200 (MET DST) |
| |
Alan wonders:
> 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
|  |