> > Then we'll generate both 'pressed' and 'released' events when we receive> > it. This is for example valid for the 'Pause' key on a PC keyboard.

> I supose you could do that -- though that would be implying instantaneous> key-pressing (time of down==time of up).

Actually the Pause key does exactly this - it (in hardware)sends a press and an immediate release. We could add agenerated delay between those, should this be a problem,which I doubt.

> > Lights on keyboard are not input.

> So we are going to have a protocol with _no_ bi-directionality? That dosn't> make much sense, IMHO -- even (old-school) printers can report out-of-paper,> offline, etc. Keep simple bi-directionality. It shouldn't break the> protocol -- if it does, then it was an _awfuly_ brittle protocol.

Well, I wanted to use the other direction for insertingsynthetic events into the queue, so that one app couldgenerate them and a different one read them.

On the other hand, both might work at once (and we could usethis for force-feedback, too). I think we should use separate eventtypes for leds, and motors and such, too, because thesesimply are not keys, eventhough they're booleans and orintegers.

> > There are five ways out of this:> > > > 1* say that 256 is enough for now ;)> > 2* split a chinese keyboard into two or more devices> > 3* extending the number field to 16 bits> > 4* swapping the fields around for buttons> > 5* adding more types to the type field, eg. 0,1,2,3 - button set 0-3, > > 4 - axis, 5 - rel. axis> > > > Which would you go for? Myself I would choose either 3* or 2*.> 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.)

If you used 3*, you'd use one byte more, but would have65535 axes as well, and won't have trouble reporting statusof a nuclear plant control panel ;)

Myself I think it is better to use more bytes than to usemore complex routines.

> > I think that it'd be nice if the application kept working if I run in on a> > PC or on a Sun, with completely different keyboards. How to do it, is the> > question.

> > There are four ways for this:> > > > 1* assign each key (depending on its label on the keyboard) a unique> > 16-bit number> > 2* number keys from 0 sequentially and provide some ioctl for querying the> > above ID> But we don't know the label on the keyboard unless sombody tells us -- you> can't tell an azerty from a qwerty programaticly.

Yes, but the somebody can tell the driver - he has to do itfor joysticks and mice already, so I guess this isn't a bigproblem for the keyboard.

> > 3* same as 2* except that the ioctl would return namestring of the> > key/axis> Even worse -- \` can be a "backquote", an "acute accent" a "negitive-slope> accent", or several other things in several languages that I can't even> pronounce. Also, userspace might not care about what the fourth key on the> top row is unshifted, but shifted -- a dollar or a pound?

The names would have to be registered in some centralregistry to be at least a bit standard, anyway.

> > 4* same as 2* without providing anything, and requiring user configuration> > (keymap)> What I'd go for. We would tell them everything that we can tell about the> device -- which isn't that much. For all we know, some joker pluged in a> Klingon keyboard into our PS2 port and didn't tell us. Let userspace sort> it all out.

We could require the joker to tell us. Actually it wouldn'tbe bad if every application would know just by querying thekernel and not the user, which keys the attached keyboardhas and if it can use some key that is not available onevery keyboard, but would be very useful for the app forexample.

With your approach every application that uses the devicedirectly needs to be configured by the user separately. Thiscan be pretty annoying.

Vojtech

-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.rutgers.edu