> > 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.
>
> Yes. The basic design principle Linux uses wrt. mice is "don't
> put to the kernel what needn't be there". This leads to only the
> basic communication protocols being built in the kernel and the
> rest done in userland by the gpm daemon.
This is a silly principle, because that same principle does not apply
to other input devices. Specifically the kernel contains reasonable
keyboard support (ie: all code table translation etc), as full
support for joysticks along with the API's to expose this
information. Hence it seems to me that mouse support is really no
different and the rest of the user land code should be insulated from
the differences between mice.
> > 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.
>
> A meta-question: What has a graphics library to do with
> keyboard and mouse? IMHO graphics and input processing are totally
> different tasks which should be done in separate libraries.
Our library is a complete multi-platform graphics library. We include
full event handling support as well as graphics functionality. You
can use our graphics code without needing the input functionality,
but for cross platform portability developers use our input API as
well as our graphics API. Note that at the API level the graphics and
input handling code are separate.
> > 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,
>
> This is a bogus argument leading to decisions like `using the C
> library is not suitable because some systems don't have the
> version I use installed'.
No, it is not a bogus argument at all. Some people keep telling me;
use GPM since that is how you are supposed to do it. Well what if the
user does *not* have GPM installed on the runtime system (if for
instance they did not know they needed it, so skipped it when asked
whether to install it during installation)? Or what happens if GPM
*is* installed, but it is not enabled and running in repeater mode
(ie: gpm -R)? Is the MGL supposed to not have any mouse support in
this case, even though a mouse is attached and X11 can use it just
fine?
> > and this stuff should really be in the kernel anyway.
>
> BTW why?
For event driven systems it is very important that the mouse and
keyboard data contain accurate system time stamps that indicate the
time when the event occurred (developers sometimes depend on this
information; especially those doing visual stimulation research).
Every other OS on the planet includes this information in the
keyboard and mouse data you get from the standard OS services.
The way that Linux is constructed right now, the only way to do that
with reasonable accuracy is to process the keyboard in raw mode and
directly decode the mouse protocol information directly, and have
that code running in a separate thread that blocks on I/O from the
mouse and keyboard via select(). Whenever input comes in, this thread
wakes up, processes the input, adds the time stamp, stuffs the event
data into the shared event queue and goes back to sleep. Quite a lot
of overhead if you think about it!
On the other hand if the mouse driver was in the kernel, the protocol
data could be decoded and added to the kernel event queue when the
interrupt is recieved resulting is less overhead. More importantly it
could add the necessary time stamps accurately at the time when the
event really occurred (ie: interrupt time).
The best solution for this is to design and build a unified event
handling mechanism for all input devices into the Linux kernel. Then
applications needing to get keyboard, mouse, joystick or other input
device information obtain this by getting event packets from the
unified event queue in the Linux kernel.
BTW, this is another problem with GPM; it does not provide timestamps
since all it does is translate the raw mouse data to mouse systems
format and then repeat it to the calling app. Eck!
> > 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,
>
> What is the real scan code? Are you willing to handle zillions of
> existing keyboards on all architectures and parse their strange
> sequences of scan codes?
The real scan code is *required* by most commercial games, since they
need way to be able to tell those keys apart from their ASCII
translated encodings. Game developers assume certain types of
keyboard layouts, and regardless of whether the keyboards is US, UK,
french or german the scan codes are usually identical for all but the
'special' keys unique to each keyboard. The ASCII tranlated encodings
however may be widly different amonst the same set of keyboards.
> > 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
>
> It's unwise to use the RAW mode as the scancodes are _very_
> hardware-dependent. Better use the medium raw mode which just gives
> _key_codes_ with up/down flags.
We still need the real scan codes as I mentioned above, which I don't
beleive medium raw mode provides (or does it)?
> > 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.
>
> I don't see any argument why this should really be handled in the
> kernel. IMHO the better way is to design a library for processing of
> input events and make all programs use this library.
I do believe that this stuff should be in the kernel, but an
alternate solution is to build a standard userland daemon that is
required by all distributions. The catch with this of course is that
unless something is in the kernel, you can never guarantee that the
service will be available on any one system.
> Currently, a event-based input layer for Linux is under development,
> but it surely won't get to 2.2 kernels. In this code, at least partial
> event processing will be done in the kernel, but it's still an open
> question how serial mice will be handled.
What is the event based system you are talking about? Is it the stuff
that Vojtech Pavlik is working on, or is it the KGI stuff or
something else?
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/