> 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.
From another point of view you get "Don't put in the kernel what needn't
be there and write a generic input library which will provide a consistent
interface to all kinds of input devices, not depending on whether handled
in the kernel or not".
> 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)?
The user either compiles the things from source, then he knows he needs
to install the gpm library and installs it or he is a dumb user using some
precompiled package and then the packaging system will notice a dependency
your library -> gpm package and will install it automatically.
> 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?
Without gpm -R the mouse simply cannot be shared between two programs.
Since most users use both gpm on the console and X for graphics, the repeater
mode is the only chance they have to get it working :-)
> 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).
With few exceptions like mouse doubleclicks and mouse/joystick
acceleration I strongly doubt accurate timestamps are of any use
-- either the application is slow and unresponsive and therefore
even timestamps won't help it to react reasonably or it's fast
and responsive and then it can measure the time itself.
I'm not against the idea of some unified input event handling in the kernel
(actually I'm helping Vojtech with writing one :-)), but I doubt putting serial
mouse drivers in the kernel is sane as there are lots of different protocols to
handle. IMHO it's better to have a user-space daemon which parses the serial
protocols and passes all the events to the kernel which distributes them.
> Every other OS on the planet includes this information in the
> keyboard and mouse data you get from the standard OS services.
Obviously false. There are even OS's with _no_ mouse support.
> More importantly it could add the necessary time stamps accurately at the
> time when the event really occurred (ie: interrupt time).
What does "time when the event really occured" mean for serial mice?
Measuring the times with up-to-nanosecond accuracy has no connection
to reality -- millisecond resolution is more than accurate (especially
for serial mice which are able to transmit at most 320 events per second)
and you can easily get such precision even in a userspace process.
> 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.
Please distinguish between scan codes and key codes. Scan codes are
sent directly by the keyboard, are strongly hardware dependent and vary
with settings of the keyboard and keyboard controller. Key codes are what
you need -- i.e., real identifiers of keys, not depending on any ASCII
mapping.
> 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 provides key codes. You don't need scan codes. Actually,
nobody needs scan codes.
> 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.
Neither you can with the kernel. Imagine somebody running kernel 1.2.13.
> What is the event based system you are talking about? Is it the stuff
> that Vojtech Pavlik is working on,
Yes.
> or is it the KGI stuff or something else?
Have a nice fortnight
-- Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth "Who is General Failure and why is he reading my disk?"- 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/