lkml.org 
[lkml]   [1999]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Mouse and keyboard drivers in the Linux Kernel?
Hi!

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

Yes. On improperly configured computer (i.e. without gpm -R), you
should run without mouse support. Tell your users to run gpm -R. Mouse
support from XFree should be removed...

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

Look at vojtech's input patches.

> 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).

This is how it is going to be done in future. If you want to help with
development of linux-input, you'll be welcome.

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

I know gpm is big hack. But it is better than doing protocol decoding
yourself.

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

They do not want "real scan code"s, all they want is key codes, and
yes, it is valid. (Real scan code for arrow is something like E0 43 E0
21 E1 13, you don't want to decode that in your favourite game).

> > 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)?


Medium raw mode will work just fine for you (and also for anyone else).

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

You can't even guarantee that service will be available on any system
if it _is_ in kernel, so your argument is bogus. [Think old system,
think system with kernel de-bloated by hand.]

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

Yes it is about vojtech pavlik, I believe.

--
The best software in life is free (not shareware)! Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.063 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site