Messages in this thread | | | Date | Sat, 5 Dec 1998 13:14:38 +0100 (MET) | From | (Guest section DW) | Subject | Re: keyboard.h |
| |
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 ?
Yes.
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.
Andries
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |