Re: 2.6.0-test5 vs. Japanese keyboards [3]

[Andries Brouwer]

On Sun, Sep 21, 2003 at 07:07:10PM +0200, Vojtech Pavlik wrote:

> > 	static unsigned char atkbd_set2_keycode[512];
> 
> We may need to change this to a u16, IF we'll ever need to load a
> keycode above 256 for an AT keyboard. So far all the keys on AT keyboards
> are within the 0..255 range. That's of course not true for other,
> more crazy keyboards.
> 
> > It really seems a pity to have to add new ioctls, and to have to release
> > a new version of the kbd package, and to waste a lot of kernel space,
> > while essentially nobody needs the resulting functionality.
>  
> We could do an audit of the key definitions, document which KEY_* symbol
> means exactly what (and it'd be a good thing anyway), by that try to
> remove duplicities and try to stuff everything in 0..255.

Yes.

I think that if you remove everything that is not used inside the kernel,
the rest fits problemless into 0..255.

> We'd lose te potential possibility to map keysyms to buttons, though
> since that never was used, nobody would cry probably.
> 
> However, my experience tells me that whenever some range is tight, and
> 0..255 is in this case, we will very soon overflow as new weird devices
> come into market.

True. In the long run more may be needed. (If we really want to assign
a different keycode to each possible picture on a key.)

I would be happy if we could pass smoothly from old to new - no new
ioctls for 2.6.0 yet, a kbd package that only changes the NR_KEYS define,
and later worry about whether we really need lots of keycodes.
Everything we add will never go away, so we must be slow in adding.

Andries

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/