Messages in this thread | | | From | "Kendall Bennett" <> | Date | Fri, 21 May 1999 11:37:42 -0800 | Subject | Re: Mouse and keyboard drivers in the Linux Kernel? |
| |
Ian Eure <ieure@crosssound.narrows.com> wrote:
> > 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.
It is normal for the Linux kernel, but not very programmer friendly. The abnormality of the Linux OS is that there are absolultely no standard OS services for dealing with the mouse and keyboard from a console in the manner that we need to. The keyboard services currently in the kernel are archaic, and not useful for event driven systems (hence the need to program the keyboard in raw mode).
> > 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.
You have just summed up the *exact* problem with the current scenario in Linux. All that stuff needs to be handled in user space, so any console apps that want to talk to the mouse and keyboard in a modern manner need to contain code that knows how to talk to every mouse device, and knows how to do code page translations for keyboard data.
When I say console apps, I am talking about SVGALib programs, the X11 server, MGL programs, console libGGI programs and who knows what other programs (for instance the Rhide console programmers IDE). Every single one of those *applications* has the mouse and keyboard handling code duplicated within the program (or the shared library if the app links to shared libraries).
There should be a standard set of OS services (perhaps a beefed up userland daemon based on GPM, but I prefer it in the kernel) that *everyone* is expected to talk to. This way all apps can be easily extended to add support for new mice and keyboards without having to update the code for every project and deal with it that way.
As for GPM, the biggest problem with it is that it is always an optional component in Linux distributions. Hence not all systems have it installed, and hence you can't rely on it.
> 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.
I have done all that, since that is how we have implemented our current support. But it bugs the hell out of me that we had to do that to begin with, and that when USB mice become prevalent we will have to add more code to our drivers to figure out how to manage this.
There is already joystick code in the Linux kernel, and an API for interfacing with this code. I feel very strongly that full keyboard and mouse handling *should* be in the Linux kernel. The keyboard handling is *already* in the kernel, it is just not powerful enough (no Linux app should ever have to read the keyboard in raw mode!).
As for mouse handling, the code to decode the mouse protocol information is not that complicated for each device, but the number of devices to support is already large and growing as USB becomes more prevalent. On top of that, the code that does the decoding of the mouse protocol really should be in the kernel so that the packets can be decoded at interrupt time and placed into the event queue.
Regards,
+---------------------------------------------------------------+ | SciTech Software - Building Truly Plug'n'Play Software! | +---------------------------------------------------------------+ | Kendall Bennett | Email: KendallB@scitechsoft.com | | Director of Engineering | Phone: (530) 894 8400 | | SciTech Software, Inc. | Fax : (530) 894 9069 | | 505 Wall Street | ftp : ftp.scitechsoft.com | | Chico, CA 95928, USA | www : http://www.scitechsoft.com | +---------------------------------------------------------------+
- 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/
| |