Messages in this thread | | | Date | Sun, 21 Sep 2003 16:49:14 +0200 | From | Andries Brouwer <> | Subject | Re: 2.6.0-test5 vs. Japanese keyboards [3] |
| |
On Sun, Sep 21, 2003 at 02:48:17PM +0200, Vojtech Pavlik wrote:
> > So, instead of requiring new ioctls and new loadkeys etc > > I would prefer to make NR_KEYS 256, if possible. > > So the question is: why did you require 512? > > Excerpt from input.h:
> #define KEY_TEEN 0x19e > #define KEY_TWEN 0x19f > #define KEY_DEL_EOL 0x1c0 > #define KEY_DEL_EOS 0x1c1 > > So far the last defined key is KEY_DEL_LINE, with a code of 0x1c3. > That's above 256. If there are other places that require less than 256, > well, then those will need to be fixed or we're heading for trouble.
Hmm. The kernel assumes today that keycodes have 8 bits:
In drivers/char/keyboard.c emulate_raw() tries to invent the codes that the keyboard probably sent and resulted in a given keycode. It starts out if (keycode > 255) return -1;
In drivers/input/keyboards/atkbd.c we have tables that convert scancodes to keycodes. The declaration is static unsigned char atkbd_set2_keycode[512]; the unsigned char means that no keycodes larger than 255 can be returned.
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.
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/
| |