This is a side issue I'd like to discuss.
Kernel side abstraction of mouse drivers is painful. It encourages
user space applications that take over the entire device, and this
prevents applications from sharing a device.
The perfect example is /dev/dsp. Because the interface was "fairly
good" applications chose to open(2) it. So your desktop could make
noises, but you had to kill your desktop to play an mp3.
This has led to the current mess with your choice of ESD, OSS, and
ALSALIB as the sound API. If applications had used the theoretical
libsound.so from the start, there wouldn't be this problem.
If the kernel approach results in a "fairly good" /dev/mouse, then
I can already see applications which say "you may need to kill the
X server, and gpm, and ... etc, before using this application".
Now perhaps the mouse is special because it is used by the console
but I am concerned that a good /dev/mouse interface will result in
a repeat of the sound fiasco.
--
Nathan Hand - Chirp Web Design - http://www.chirp.com.au/ - $e^{i\pi}+1 = 0$
Phone: +61 2 6230 1871 Fax: +61 2 6230 4455 E-mail: nathanh@chirp.com.au
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/