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