> 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.
Yes, this could be done.
> * 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...
Aww, no, I don't like this. First it means double the amount of traffic,
and we would also need different event types for this. What about sending
both of this information in a single event?
Or just leaving it as it was proposed in my last mail, with querying
the key assignments via ioctl (or similar)?
> > > > 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.
As far as I know, Microsoft doesn't make any. They make the
SideWinder 3D Pro, but that one has only 4 degrees of
freedom.
Some of the professional 6dof devices are:
Logitech CyberMan
Logitech Magellan 3D
Space Control SpaceMouse
SpaceTec SpaceBall FLX series
Some of the gaming 6dof devices are:
Logitech CyberMan2
SpaceTec Avenger
SpaceTec SpaceOrb
Pegasus FreeD (but I'm not sure if this is 6dof)
There probably is a couple of others, too.
> > 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.
True. If it were only controlling motors or switches - okay,
we will need something similar for force feedback in
joysticks and mice, and for LEDs on a keyboard.
> > 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.
Not only that, but as I said earlier, this 'tee' program
would get extremely inconvienient in places where the device
was already open by an app and you need to run another app.
Also, the below proposed device behaviour would make
multiple opens working without hassle.
> > 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.
Yes, and no. A generic user level char device won't solve
our problem.
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu