By the way, it's for things like this that I suggested using a keycode
which can be algorithmically mapped from scan codes once we go to a
larger keycode space. For example, if your key generates E0 63, it
would *always* have keycode 0x00E3 (227). For PC keyboards, I believe
the following mapping algorithm should work onto a 15-bit keycode
space (all numbers in hex):
xx -> 00xx
E0 xx -> 00xx | 0080
E1 xx yy -> yyxx
(I can't remember which one of the E1 bytes that has the make/break
bit, it should obviously go at the top.)
This assumes that there isn't a null byte form of E1, in which case it
really can't be made to fit, but I don't think so.
This means you don't have to configure two levels (scancodes ->
keycodes and keycodes -> keymap); since currently the keycodes are
keyboard-specific anyway there is no benefit to the two levels.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/