it's true, because anyway it is trivial to write a program that converts
it to a much more explicitly human readable form, and even interpret the
event types for known devices.
> Well, this isn't an easy issue. All the boolean and even the integer
> events should be possible to identify by the application receiving the
> events, eg. we could use the number 'a' for a 'A' key on a keyboard -
On AZERTY keyboards the key position is not the same. If trying to do a
port of FastTracker for example, and i kick the 2nd key in Tab's row for a
"Do" (C) note, on QWERTY like mine it will be 'q', but on AZERTY keyboards
like in France it'll be an 'a'.
Most programs prefer the semantic value of the keys, but some prefer the
positional value.
> but what to use for the left mouse button? And how to say to the application
Number them as in X, for example. This is just a matter of deciding
arbitrarily these and be prevoyant enough to have a minimum of divergence
on this standard for as long as possible. (is "prevoyant" a gallicism of
mine or what?)
> which integer event is up/down, and which right/left? And joysticks ...
left/right is X, thus should be numbered immediately inferior to up/down
which is Y.
> there is a lot of very different sticks, with 2-9 integer outputs,
> using them for various purposes ... these should be somehow identified,
> too ... any ideas?
the idea is to kidnap someone who knows the joysticks alot and force him
to write a standard.
> Or we could just leave setting this to the user, as is currently done
> with the keyboard via loadkeys ... having a similar map somewhere and
> a library that reads it.
at the lowest level there should be no mapping. if root wants a filter,
he'd rename /dev/joystick to /dev/joystick--, and use a filter that
outputs its stuff to a named pipe /dev/joystick.
> I don't think we can time sort packets. This would imply buffers, which
> could be huge to keep the packets sorted. And, what would we do upon receiving
> an older event from a low-level driver that the one we already sent to the
> application?
it's true.
> > a mouse would use these: booleans 1 to 5 (for buttons 1 to 5); Relat.#0
> > is X displacement; Relat.#1 is Y displacement.
> What about mice with scroll wheels?
Well, Relat.#2 would be used for that wheel, intuitively, unless you want to
use #99 or #255 for that matter.
> And 6DOF devices used in CAD design?
what is that? if you know a special device, just post info on it...
> > a joystick would be quite the same, except Absol.#0 and Absol.#1 would be
> > used instead.
> Well, for joysticks you'd need at least 10 booleans for buttons and about
> the same number of integers ...
i was talking about classic joysticks as the stuff on ports 0x200 and above.
> By the way, the protocol is missing a way how to get info on what range
> of integer/boolean events the device can generate ...
yes, i know. it's normal. i'm at proposal 0.2, you know, and we're gonna
have like 150 revisions before version 1.0.
> > the same generic protocol could be used to talk to those input devices
> > (like to ask them a complete restatement of their status, or configure
> > mouse acceleration, keyboard repeat rate, etc).
> Yes, it could. But I don't think the protocol is matching these uses ...
Then how would you get info on what range of integer/boolean events the
device can generate?
> Eek. Do you want it to control spaceships, too? What about throwing
> away TCP/IP and control the whole internet with this? Keep things simple,
> please. And remember that a couple of specific tools is usually much better
> than a single super-swiss-knife with inbuilt calculator and rocket launcher.
They still are simple: if your program wants to handle the keyboard only,
it doesn't have to know about the spaceship event protocol. The
"complicated" part is just a long list of stuff that should be kept to
ensure compatibility between drivers and applications.
> After all, as I said in the beginning, I like it. I would simplify it a bit,
> though. Would make it unidirectional only, kernel->application, architecture
> specific (endianity), binary, unencoded (no base64), with a bit less fields,
> with ioctls for all the non-event info, but, otherwise, much the same. :)
ioctl()... the filter program providing filtered events in a named pipe
won't be able to honor ioctl()'s, afaik.
matju
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu