Messages in this thread | | | Date | Sun, 21 Sep 2003 19:42:00 +0200 | From | Andries Brouwer <> | Subject | Re: 2.6.0-test5 vs. Japanese keyboards [3] |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |