This makes sense. I had two ideas for that:
* first one: control request for device names. it's generic, intelligent
(in the sense of Hayes or SCSI, not K2000 or Deep Thought), and
relatively low overhead.
* second one: every device with such dual semantics should issue pairs of
events. this reduces the amount of code that has to be written in the
application, and allows easily to merge or differenciate duplicate keys
such as LMeta/RMeta, or LArrow/KP_LArrow...
> > 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.
prévoyance: ability to do long-term planning, to be careful about the
future, according to me; when asking the BabelFish of AltaVista,
translation is: precaution... but in french, précaution already exists
and doesn't have the same meaning exactly...
> > 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.
I'm gonna release the 0.3 document before the end of Eastern Time night.
> Yes, I was talking about a library that could be used by
> apps if they wanted the mapping.
It could be a library or another thing, as long as it works... there is
enough freedom in the spec.
> > > 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.
okay, a guy at the Canadian National Research Council told me about that
when I was there. He shopped and only found the Micro$oft one and I said
fuck, don't use that! What are other brands for 6DOF devices? I'd like to
tell him.
> Yes, but I don't think you really will use the same protocol
> for generating keyboard events and controlling a spaceship.
No, but for controlling small physical robots (like turtles and
tracing-tables), this could be nice.
> 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).
Hmmm... worth re-thinking.
> 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?
multiple-open is to be done via 'tee'-like program. the program might
effectively start to buffer everything. Hmmm... sh*t.
> 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?
Sounds like an interesting idea... there is the more generic "user-level
char-devices and block-devices" thing.
matju
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu