[lkml]   [1999]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectkeyboard scancodes
    It is clear that it is about time to redesign the kernel
    keyboard handling, on all levels. The old setup was very
    flexible, and was good enough for the past six years or so,
    but these days it becomes urgent for the low level handler
    to handle keyboards with more than 128 keys and more complicated
    escape sequences, and for the keymap level to better handle
    UTF-8 and Unicode. We also need a bit more flexibility in
    the handling of diacritical signs.

    Just to remind myself of the scancode situation on current
    PC keyboards, I put some notes together and made them available
    at .

    For these PC keyboards it seems the proper solution would be
    a finite state machine, with tables that can be loaded from
    user space, a little bit like setkeycodes does today, but
    much more general. The traditional keybaord would then have
    three scancode maps (the plain one, one for e0 and one for e1)
    and people for whom e0 is not an escape symbol would only
    have the plain map, and people for whom also 80 is an escape
    symbol would have a fourth map.

    I am reasonably well aware of the PC situation. However,
    the notes mentioned do not have any information about
    Sparc and Apple keybaords, etc. Additions or pointers to
    information are welcome.

    (And please: everybody with an interesting keyboard: try out
    "scancode -s" on the interesting keys, and report.)

    Andries -

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

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