lkml.org 
[lkml]   [1999]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Mouse and keyboard drivers in the Linux Kernel?
Kendall Bennett wrote:
>
> Hi All,
>
> 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. 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.
>
This is normal. AFAIK this is the documented behavior when you read
directly from a serial port.

> 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, and this stuff should
> really be in the kernel anyway.
>
Mice are handled from userspace; either the gpm daemon or the X server.
I really see no reason to have mouse drivers in the kernel, we should
only have the bare minimum needed to access them from userspace, e.g.
serial port/usb/busmouse stuff.

There are mouse routines you can link to from userspace distributed with
gpm, (libgpm) I suggest that you snag the source and take a look. Of
course, this is assuming that you want to use mice for the text console.

You might also want to take a look at what the GGI/KGI people are doing
WRT mice. They seem to have a pretty good thing going with video and
keyboards.

> 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, 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
> 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.
>
Definitely look at GGI/KGI. You might also want to sift through the
SVGAlib source, as I believe that it handles mice and other input.

--
+-------------------------------------------------------------------------+
| Ian Eure
<ieure@crosssound.narrows.com> |
| Network Administrator, Cross Sound Appraisal
Company |
|
|
| "Believe it or not, there's more to being a sysadmin than
rabid |
| technophilia." --Annalee Newitz, "Invisible
Heroes" |
+-------------------------------------------------------------------------+

-
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.077 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site