Messages in this thread | | | Date | Thu, 20 May 1999 08:56:26 -0700 | From | Ian Eure <> | Subject | Re: 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/
| |