> > 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.
What about numbering them sequentially from 0 in the events,
and providing a way how to identify each key/axis? I'm
thinking of an ioctl, or something similar, that would
either return the key/axis name (a string), eg. "A",
"Enter", "Axis X" ... and such, or a predefined number eg.
KEY_A, KEY_Enter, AXIS_X, ... what do yout think?
The same for identifying a device type ...
> 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?)
Yes.
> left/right is X, thus should be numbered immediately inferior to up/down
> which is Y.
Okay.
> > 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.
Me probably *grin*. Okay, I'll try to think up something
useful.
> > 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.
Yes, I was talking about a library that could be used by
apps if they wanted the mapping.
> > > 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.
Yes.
> > And 6DOF devices used in CAD design?
> what is that? if you know a special device, just post info on it...
3D (six degree of freedom) devices. But there are no real
problem with these actually, except that they don't fit in
any predefined cathegory / mapping.
> > 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.
Port 0x201. IBM Game Port. Unfortunately recently there was a huge number of
extensions by various manufacturers using a number of analog/digital protocols
over this old poor gameport to give access to many more axes and buttons.
See the joystick driver docs (specs.txt) if you want to know
more.
> > 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.
I use ioctls for that in my joystick driver ....
> > > 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?
As said above, ioctls.
> > 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.
Yes, but I don't think you really will use the same protocol
for generating keyboard events and controlling a spaceship.
> ioctl()... the filter program providing filtered events in a named pipe
> won't be able to honor ioctl()'s, afaik.
Yes, named pipes can't do ioctls. They also can't make sure
that only whole numbers of events are read. They also can't
generate 'startup' events as used in my joystick driver.
(These events are generated either when the device is
opened, so that the application gets notified of immediate
state, or when some of the events are lost due to the
application receiving them too slowly).
Also, I'm not sure about how named pipes will handle when
the receiving application simply will stop reading the data
... will they buffer all the events? And will they be able
to handle multiple opens well?
I think it would be easier if we could define that an
/dev/inputX device could also be opened for write (if isn't
assigned to a hardware device), and that it will serve as a
pipe in this respect, but allowing all the above, able to
serve ioctls, doing clever event queueing and such stuff. Is
this too crazy?
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu