On Tue, May 18, 1999 at 10:56:21AM -0800, 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 why libgpm exists.> 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.No, it should be in a library, and you should link against it. Distroscan then create dependencies as necessary.Alternatively, static link against libgpm.The kernel provides access to the hardware. Stuff which can be done inuser space without lossage is obviously not a kernel problem.> 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.Or in a library.The kernel provides access to the hardware. Libraries provide the goodclean interface which "hides" the differences in hardware.What next. X should be in the kernel because not everybody has X? libcshould be in the kernel just in case libc isn't installed?-- 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" inthe body of a message to majordomo@vger.rutgers.eduPlease read the FAQ at http://www.tux.org/lkml/