lkml.org 
[lkml]   [1996]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: KDGKBENT

From UCKO@VAX1.ROCKHURST.EDU Mon Apr 15 04:19:41 1996
Cc: torvalds@cs.helsinki.fi, linux-kernel@vger.rutgers.edu

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.

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.

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.

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.

Andries


[PS Please do not complain that the above is only an approximation
of the truth. I know already.]


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:1.288 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site