Messages in this thread | | 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/
| |