Paul Barton-Davis (pbd@Op.Net)
Fri, 4 Dec 1998 16:16:07 -0500

1) Why does keyboard.h define NR_KEYS to be 128 ? Is it just so that
its the the nearest power of 2 to a likely limit ?

2) Why does keyboard.h stick the macros for K_FIND thru K_PAUSE right
in the middle of those for K_Fnn, thus preventing a nice simple
macro like:

#define K_FNUM(k) KVAL(k)+1

and requires instead:

#define K_FNUM(k) k <= K_F20 ? KVAL(k)+1 : \
k > K_PAUSE(k) ? : KVAL(k)-9 : -1

3) Whats the rationale for the keycodes assigned to various escaped
scancodes (E0_KPENTER etc.) ? I.e why is E0_KPENTER assigned keycode
96, instead of, say, 102 or 83. The comments say:

* The keycodes 1-88,96-111,119 are fairly standard, and
* should probably not be changed - changing might confuse X.
* X also interprets scancode 0x5d (KEY_Begin).

is this the only reason ?

4) Why do the Focus and RC930 keyboards get special treatment,
instead of labelling the scancodes they use generically ?

I have a new Logitech Internet keyboard, with 18 new function keys
that generate various e0-prefixed scancodes. I can get Linux to work
with them using setkeycodes(1), and I hacked X to work with them by
tweaking the XFree-3.3.3 code. But these two sets of keymaps are
nowadays designed to work together, and right now, thats hard to do
because of the wierd and sparse-filling of the e0_keys and high_keys arrays in
pc_keyb.c. X needs to know the special names/values in use
in the kernel (like FOCUS_PF11)

I have already hacked pc_keyb.c to avoid all this, and use generic
names for the scancodes, ie.

change E0_MSLW to SC_E0_5B (scancode: 0xe0 0x5b)
and FOCUS_PF11 to SC_73 (scancode: 0x73)

but I got nervous that there is some rationale for the way things are
being done right now.

My plan is to completely fill all the relevant arrays, increase
NR_KEYS, and thus allow any new keyboard with new keys to work
with X without further kernel/X hacking.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at