lkml.org 
[lkml]   [1996]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: wish list
Date

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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.026 / U:4.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site