Messages in this thread | | | Date | Mon, 15 Apr 1996 17:47:27 -0600 (CST) | From | Aaron Ucko <> | Subject | Re: KDGKBENT |
| |
> In drivers/char/vt.c, why does the code for KDGKBENT contain the statement > if (kbd->kbdmode != VC_UNICODE && KTYP(val) >= NR_TYPES) > val = K_HOLE; > ? I feel that it should be unnecessary to set kbdmode to VC_UNICODE just > to get a keyboard map including any possible non-ISO-8859-1 keysyms. > >I hope that not too many people mail both torvalds@cs.helsinki.fi and >linux-kernel@vger.rutgers.edu when they do not understand the kernel code.
I understand the kernel code perfectly well.
>Precisely what do you hope to achieve by removing this test, except >confusing dumpkeys or X? > >The idea is that the keymap contains a 16-bit entry for each key. >When not in Unicode mode, this entry is a pair (type, value) >with 13 possible types, like KT_LATIN (ordinary key), KT_SHIFT (shift key), >KT_FN (function key). Type cannot be larger than or equal to NR_TYPES >since keyboard_interrupt() contains the call > > (*key_handler[type])(value, up_flag); > >and NR_TYPES is the size of the array key_handler.
What do you mean? The addition of KT_SLOCK didn't break either, and that may have exceeded the value of NR_TYPES that set when dumpkeys or X was compiled on some system. > >When in Unicode mode, this entry is the 16-bit Unicode value associated >with the key. This seems to take the entire key space, but the Unicode >code space contains a user area, and codes like ShowMemory or Reboot >that do not occur in Unicode are stuffed there. >For this case, keyboard_interrupt() contains the call > > if (!up_flag) > to_utf8(keysym); > >so that the 16-bit Unicode value is transmitted as a sequence of between >one and three bytes. In particular, users that work strictly ASCII-only >will not see any difference between VC_UNICODE and VC_XLATE.
Yes, I understand all that. What does this have to do with having to set the mode to VC_UNICODE just to read a complete keymap?
>The test you refer to makes sure that Unicode characters are not >given to a user mode program when we are not in Unicode mode. >Some programs (like X) read out the current keymap, and adapt their >own keymap accordingly. These programs would only be confused by >Unicode values.
They shouldn't be. X in particular supports non-ISO-8859-1 characters anyway (albeit not via Unicode), and as I said the addition of a new type after they were compiled should confuse them too.
-- Aaron Ucko (ucko@vax1.rockhurst.edu; finger for PGP public key) | httyp! "That's right," he said. "We're philosophers. We think, therefore we am." -- Terry Pratchett, _Small Gods_ | Geek Code 3.1 [for explanation, finger hayden@mankato.msus.edu]: GCS/M/S/C d- s: a18 C++(+++)>++++ UL++>++++ P++ L++>+++++ E- W(-) N++(+) o+ K- w--- O M@ V-(--) PS++(+++) PE- Y(+) PGP(+) t(+) !5 X-- R(-) tv-@ b++(+++) DI+ !D-- G++(+++) e->+++++(*) h!>+ r-(--)>+++ y?
| |