lkml.org 
[lkml]   [1999]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Mouse and keyboard drivers in the Linux Kernel?
Hello!

> We are getting close to finishing the port of our SciTech Multi-
> platform Graphics Library to Linux (free Open Source under our
> modified mozilla PL). One thing has been bothering me for some time
> is that Linux does not appear to have a *full* mouse driver built
> into the kernel.

Yes. The basic design principle Linux uses wrt. mice is "don't put
to the kernel what needn't be there". This leads to only the basic
communication protocols being built in the kernel and the rest
done in userland by the gpm daemon.

> There is the /dev/mouse device you can use to communicate with the currently
> configured mouse, however this device simply passes back the raw mouse
> protocol data and we need to know about *all* the different types of mice
> that can be attached, and to somehow figure out what one is actually
> connected.

A meta-question: What has a graphics library to do with keyboard
and mouse? IMHO graphics and input processing are totally different
tasks which should be done in separate libraries.

> This is a major pain, so I was wondering if there really was a real
> mouse driver in the Linux kernel, or if people are interested in
> building one? Specifically I want a device that maintains a queue of
> events internally including mouse up, mouse down and mouse movement
> events (including a 1ms time stamp for every event so we can tell how
> far apart the events were). Then our MGL code will only need to
> connect to the mouse device and read the events from the queue to get
> the real data we need. Oh, and using the GPM libraries is not
> suitable because GPM is not always installed,

This is a bogus argument leading to decisions like `using the C
library is not suitable because some systems don't have the version
I use installed'.

> and this stuff should really be in the kernel anyway.

BTW why?

> Likewise another thing that bothers me is the keyboard driver we have
> in the MGL. The MGL's event mechanism requires a keyboard driver that
> allows us to get KEYUP, KEYDOWN and KEYREPEAT events along with a 1ms
> time stamp for all key events. We also need to know the real scan
> code of the keypress,

What is the real scan code? Are you willing to handle zillions of
existing keyboards on all architectures and parse their strange
sequences of scan codes?

> along with the correct ASCII translation for
> the key. Right now the kernel keyboard driver does not provide such
> functionality, so we have to run the keyboard in RAW mode so we can

It's unwise to use the RAW mode as the scancodes are _very_
hardware-dependent. Better use the medium raw mode which just gives
_key_codes_ with up/down flags.

> process the up/down events ourselves. This works fine (but we need a
> separate thread processing input so we can get the time stamps),
> however it also means we are not responsible for doing the scancode-
> ASCII translations. This is something we should not be doing in our
> code, and once again something that should be handled in the kernel.

I don't see any argument why this should really be handled in the
kernel. IMHO the better way is to design a library for processing of
input events and make all programs use this library.

Currently, a event-based input layer for Linux is under development,
but it surely won't get to 2.2 kernels. In this code, at least partial
event processing will be done in the kernel, but it's still an open
question how serial mice will be handled.

Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
"What color is a chameleon on a mirror?"

-
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/

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