> Right. That's why I said that we'd be better off with bools and ints and
> rel. ints, rather then keys/buttons and axes. (I hadn't even thought of
> force-feedback. Not a gamer -- last joystick I held was on an Atari 2600.)
Not a gamer here, too. However a joystick driver author. :)
> > > I'd go for 4. We want to provide _lots_ of room to grow. Remember when
> > > 640k was enough for anybody? I think here 64k will do, but 256 is a bit
> > > short. (Yes, the current keyboard driver gets away with 128.)
> Whops. Memory-numbers-bad. I meant 3*.
Good, I'm glad we agree here. So it's now:
struct input_event {
__u32 timestamp;
__u16 value;
__u16 number;
__u8 type;
__u8 device number; (Do we need this?)
};
Okay?
> > Yes, but the somebody can tell the driver - he has to do it
> > for joysticks and mice already, so I guess this isn't a big
> > problem for the keyboard.
> Why does he have to tell _the driver_ for joysticks and mice? When we get
> an event for the third axis, we report it -- we don't care how many axes it
> has. If the app wants to know, it can look in /etc/whatever.
Because some joysticks use axis wires for buttons, some have hat switches
that are reported through button wires, other report them through axis wires,
and more. This is undetectable by the driver.
For mice it is much the same, because without advanced heuristics you can't
autodetect the protocol of a mouse connected to a serial port. The user has
to specify it.
> > We could require the joker to tell us. Actually it wouldn't
> > be bad if every application would know just by querying the
> > kernel and not the user, which keys the attached keyboard
> > has and if it can use some key that is not available on
> > every keyboard, but would be very useful for the app for
> > example.
> Or the application could look in /etc/keyboard. That's better done in
> userspace rather then userspace telling us so we can regurgate the info back
> later. (That being, after all, what block devices were made for. <G>) We
> should be able to tell userspace all we know, and not rely on it to tell us
> stuff.
Now, this sounds good to me. I just want to have one configuration file,
the info doesn't have to be in the kernel necessarily.
> Along with the monitor... there are simply better ways of globaly
> configuring both then sticking the data into kernelspace and then getting it
> out again later. The data should only come from kernelspace if it comes
> from the hardware. That's what they call it userspace for.
You're right.
Vojtech
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu