> > Yes, but as I said in my previous note: I think you should consider
> > using keycode instead of scancode.
>
> Ok.. I agree with you that using keycodes is most deffinately a cleaner
> solution. In theory. That being said, we have a serious shortage of available
> keycodes. My keyboard contains 18 "internet" keys. There is no contiguous
> area in the ununsed keycodes that is that large. We need a better solution.
"serious shortage" - already six years ago I worried that 128 keycodes might not
be enough, and we are uncomfortably close to this limit, but personally I haven't
seen any keyboards with more than 124 keys yet. There are rumours about keyboards
with more than 128 keys, but so far nobody has said "I use such a keyboard".
"18 internet keys" - Good! Can you tell me the keycaps and the scancodes and
the manufacturer/model? Mail aeb@cwi.nl.
"contiguous" - no. I recommend people to use 89-95 and 112-118 and 120-127,
good for 22 unusual keys.
> I'm not totally sure about how the current system works, so I don't want to
> propose any radical new ideas just yet. I'm also not sure how userspace
> applications (like loadkeys) would be affected if we expanded the keycode space
> to say, 32k.
Current system: keyboard produces scancodes. The kernel gives them to user space
for programs in RAW mode. Perhaps dosemu or X. If user space does not want raw
scancodes then the scancodes are parsed into keycodes. The kernel gives them
to user space for programs in MEDIUMRAW mode. Perhaps showkey or X.
If user space does not want keycodes then the keycode is looked up
on the user's keymap and the corresponding character (keysym) is returned
(or action is done).
It is not very difficult to allow 16-bit or 32-bit keycodes, but I suppose
this will first be actually done when keyboards that require it become available.
An intermediate solution could be to go to 8-bit keycodes that use the full range
0-255. Today the high order bit is used for key up/down information, but a new
mediumraw mode that would send one byte 0/128 for key up/down followed by a
byte with the keycode, allows 256 keycodes (with an easy upgrade path to 32k).
> Unless we plan to make some major modifications here, I don't think it is very
> feasible to use keycodes.
Well, today it is feasible, and as soon as it becomes necessary we will make
the modifications.
> To anyone who knows alot about this:
> Can you please reply with information on the feasability of expanding the
> keycode space?
See above. Key codes are used only kernel-internally, and as a mechanism
to index the keys for loadkeys, and as a mechanism to index the keys for
some X servers. Changing things requires very minor modifications to
kernel, X, loadkeys/dumpkeys, xmodmap, dosemu, probably some games.
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/