Finally I was able to get there - the last time the server was just
timing out.
A couple corrections:
The scancode set that uses 0x80 as 'released' mark, is Set1,
not Set2. - It's the XT emulation set.
> Can you complete the translation table?
Ok, here goes the Set2->Set1 (and also AT->XT) table:
AT XT AT XT AT XT AT XT AT XT
00 ff 20 67 40 6b 60 55 80 ??
01 43 21 2e 41 33 61 56 81 ??
02 41 22 2d 42 25 62 77 82 ??
03 3f 23 20 43 17 63 78 83 41
04 3d 24 12 44 18 64 79 84 37
05 3b 25 05 45 0b 65 7a 85 ??
06 3c 26 04 46 0a 66 0e .. ??
07 58 27 5c 47 60 67 7b
08 64 28 68 48 6c 68 7c
09 44 29 39 49 34 69 4f
0a 42 2a 2f 4a 35 6a 7d
0b 40 2b 21 4b 26 6b 4b
0c 3e 2c 14 4c 27 6c 47
0d 0f 2d 13 4d 19 6d 7e
0e 29 2e 06 4e 0c 6e 7f
0f 59 2f 5d 4f 61 6f 6f
10 65 30 69 50 6d 70 52
11 38 31 31 51 73 71 53
12 2a 32 30 52 28 72 50
13 70 33 23 53 74 73 4c
14 1d 34 22 54 1a 74 4d
15 10 35 15 55 0d 75 48
16 02 36 07 56 62 76 01
17 5a 37 5e 57 6e 77 45
18 66 38 6a 58 3a 78 57
19 71 39 72 59 36 79 4e
1a 2c 3a 32 5a 1c 7a 51
1b 1f 3b 24 5b 1b 7b 4a
1c 1e 3c 16 5c 75 7c 37
1d 11 3d 08 5d 2b 7d 49
1e 03 3e 09 5e 63 7e 46
1f 5b 3f 5f 5f 76 7f 54
This table is stored in most existing i8042's in the computers,
except for the really old ones (found in 286's), which instead tell
the keyboard to switch to set1 (which doesn't work with some keyboards)
so that it's the keyboard who does the translation then..
If you wonder where this crazy translation comes from, then compare
the XT and AT keyboard layouts and you'll find that the numbering
on each is quite reasonable, and, unfortunately unrelated to the other.
This table is a child of backward-compatibility.
> Do you know references for these kscancodes?
You can find a lot on eg.
http://www.repairfaq.org/filipg/LINK/PORTS/F_Keyboard_FAQ.html
http://www.geocities.com/SiliconValley/Bay/8302/keybrd.htm
Also, I've got a book by Gary J Konzak, "PC 8042 Controller",
ISBN 0-929392-21-3, which is worth reading, and which contains
the above table.
> Comparing with your scancodes.h, I find several differences.
> These untranslated scancodes look like they are what you have
> in the second column of your table.
>
> But you have
> {0x41, 0x02, 0x37, 0x10, 0x40, 0x62, 65}, /* F7 */
> where I find that F7 has kscancode 0x83.
>
> You do not give the scancodes? F11 has scancode 0x57, etc.
To save space, the atkbd.c uses the 7th bit (0x80) in its internal
scancode table to indicate the key was prefixed with 0xe0 or 0xe1.
This means that for example the Up key, which is 0xe0 0x75 will be
0xf5 in the scancodes.h Set2 (at) table.
So the code has exceptions for keys that are above 0x80 natively,
without prefixing. The two are:
Set2 | Key atkbd.c/scancodes.h
~~~~~|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x83 | F7, remapped to 0x02
0x84 | SysRq, remapped to 0xfc
Also, I don't have all the XT scancodes in my table - only those
used in an XT keyboard - because they're no good. First, you can
compute them using the above table, second, it's way better to use
the AT ones in a driver.
The XT scancodes on an AT keyboard are not very useful ...
> What about choosing USB as the new standard for the keycodes?
> It is 16-bit, and that is good. But today it only uses 8 bits,
> that is also good.
Actually, I don't care which will be THE kernel encoding, I just
hope there will be just ONE, and for all the architectures. Right
now every architecture uses its own ...
-- Vojtech Pavlik SuSE Labs- 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/