>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.
I was afraid of that.
[ K_Fnn ]
>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.
Backwards to what ? The keycodes aren't an exported kernel
interface. If you want to use them, you should be using the macros
defined in keyboard.h, not absolute values. Programs that relied on
K_FIND being some certain value are broken. And besides, I have always
been under the impression that Linus tries to act as a good filter for
this kind of thing.
> 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 array
> 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.
Well, almost. The problem is that X has its own set of
scancode/keycode mappings, and in order to look up the kernel mapping,
it has to translate from its "AT Keycodes" to the Linux equivalent
(and then back again at the keysym level). So there is an array in
xf86KbdLnx.c called at2lnx which does this mapping, and *it* has to
have the kernel keycodes that correspond to X's view of the world.
This is pretty ugly, since X can choose only one such mapping. The
existing X server define ASSUME_CUSTOM_KEYCODES is an attempt to get
around this, but has its own problems in terms of backwards compatibility.
> 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.
As I indicated above, they are used implicitly, which is nearly always
bad. The X server has to specify which Linux keycode wants to ask
about when trying to figure out what to do with its own
"{scan,key}codes".
I don't agree that they act as a visual aid. Instead, as someone
trying to add support for a new keyboard, I'm finding myself saying
"why is scancode 0xe0 0x7a called FOCUS_something ?" What we're trying
to do in the code is to say: the keyboard controller gave us "e0 7f",
and we generate keycode 0xfeedface in response. Giving them names when
its just a table lookup (e0_keys[]) doesn't help anyone, and makes it
appear that particular scancodes have some semantic significance.
> 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.
Now that I've thought about this some more, and read your message, it
seems clear that increasing NR_KEYS is a bad idea. I'll think some
more. having only 128 keycodes wouldn't be as much of a problem if it
weren't for the fact that X has more. They don't all correspond to
real keys, since the server generates its own keycodes for various
numlock-state keys. This means that 128 is actually too small for all
the keycodes that X wants to use when its driven by one of the new
Logitech keyboards. Of course, the problem is not so bad, since I have
X working already with the new keys, but it doesn't pick up any kernel
mappings since for the keycodes > 127, and this now includes the
server's "synthetic" numlock keys.
--regards,
--p
-
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/