lkml.org 
[lkml]   [1999]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: keyboard scancodes
    On Tue, Dec 14, 1999 at 11:09:31PM +0100, Andries.Brouwer@cwi.nl wrote:
    > Dear Vojtech,
    >
    > Now that you talked about the untranslated scancodes of the keyboard,
    > I added what I know about them to my scancodes.html page, see
    > http://www.win.tue.nl/~aeb/linux/kbd/scancodes.html
    > or
    > http://www.cwi.nl/~aeb/linux/kbd/scancodes.html

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.029 / U:0.152 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site