Re: KDGKBENT

Aaron Ucko (UCKO@vax1.rockhurst.edu)
Mon, 15 Apr 1996 17:47:27 -0600 (CST)


> 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?