Messages in this thread | | | Date | Wed, 24 Sep 2003 12:02:33 +0200 | From | Pavel Machek <> | Subject | Re: 2.6.0-test5 vs. Japanese keyboards [3] |
| |
Hi!
> > #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.
Multimedia keyboards are very common today, and tv cards with their remote controls need it, too. -- Pavel Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...
- 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/
| |