Very useful in fact. That way I was able to verify almost all of the table
you quoted from Gary J Konzak.
# * Ahh, finally I see what you call kscancodes - my scancodes.h table
# only deals with kscancodes, because that's the truth, it doesn't
# make sense to look at the codes through the warped glass the i8042
# provides.
How is that glass warped? It is just a 1-1 correspondence, so before
or after the map doesnt really make any difference. Another table.
(And since most machines in the world use this translated Set 2 default,
doing anything else only has the disadvantage that it won't work on
some keyboards. In particular I wonder how faithful USB keyboards
will emulate this old nonsense.)
Andries
P.S. Is it a 1-1 correspondence? Essentially, yes.
The conversion table is a permutation on 01-7f.
Remain 3 entries, one of which I disagree about with you, see above.
The duplication of 41 at 02 and 83 causes problems for the keyboards
that disregard the highest bit. That is why the values of Set 3 for
the keys 1 and 2 are anomalous.
P.S.2 All this is only of historical interest. I am mainly interested
in the question whether there are reasons not to use the USB keycodes
as our 16-bit keycode standard.
-
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/