Re: keyboard.h

Guest section DW (
Sat, 5 Dec 1998 13:14:38 +0100 (MET)

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 ?

No, it cannot be different today.
It is the size of the keymaps.
It is the number of distinct keycodes possible in MEDIUMRAW mode.
Changing just this define is useless - if you want to increase it
large parts of the keyboard driver and of user space software
like loadkeys and dumpkeys (and the X keyboard driver) will have
to be adapted.

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

These stupid kernel developers always changed things in such a way
that new features were added but people not using them did not notice
any changes. It is called backwards compatibility.

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 ?

The generic name of a scancode is just the scancode itself, viewed
as an integer. For keycodes one wants to describe the label of the
key that was pressed. Unfortunately there are far more than 128
distinct key labels, and only 127 key codes available.
So, some folding is required. The defines were only used to
easily demonstrate that for each single keyboard no two keys
were assigned the same keycode.

For example, both 0x5c and 0x7d were assigned keycode 124,
but the former occurs on a Regnecentrale keyboard, the latter
on a Japanese keyboard, and there is no conflict.

Of course it may happen (and probably already has happened)
that keyboards are manufactured that produce both 0x5c and 0x7d.
For such cases there is the setkeycodes utility.

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)

Why? FOCUS_PF11 is not in keyboard.h, it is not exported, it is just
a local define in keyboard.c. X can read these tables using getkeycode
and need not know anything about these kernel defines.

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.

These defines are not used anywhere - they are just a visual aid
that enable one to check for the keyboards known at the time this
code was written that no conflicts arise.

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.

An interesting plan. I hope you understand the ramifications
and design a migration path where people can work with old/new kernel
and old/new loadkeys and old/new X and old/new keymap without noticing
any problems.


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