16

I have a vintage IBM 122 key model M keyboard that I am adapting for use on a modern computer. I am using a Teensy 2.0 to do the encoding and to handle the USB side of things. I borrowed the firmware from the Humble Hacker keyboard project (https://github.com/humblehacker/keyboard) and I added the extra keys in the build config. So far, so good.

All of the "regular" keys work, but the kernel appears to be dropping the extra keys (F13-F24, etc.).

Running /lib/udev/keymap -i input/event0 shows the scan codes of all the normal keys, but nothing for the extra keys.

Running wireshark to packet capture the USB port shows that the keyboard IS sending the scan codes, but it looks like the kernel is just dropping them on principle.

I feel like this is something in the kernel drivers that is simply not delivering scan codes that it does not expect.

I would think that there would be some sort of "master" key map in some .h file in the kernel source somewhere, but so far, I have not been successful in my efforts to find it.

It is worth stressing that I am not asking about mapping the extra keys in X, like so many others before me. This is a low level, apparently kernel related, problem. Assume for the moment that I will not be using X at all. What I need is for the scan codes to show up when I run /lib/udev/keymap -i, I can do the rest from there.

Improve this question
6
  • I know this doesn't help but: Why are you using the Teensy? That keyboard should work with a straight PS2/USB adapter.
    – goldilocks
    Jul 10, 2014 at 12:56
  • The keyboard came from an old IBM terminal, it's doesn't use a PS/2 compatible protocol.
    – user2543941
    Jul 10, 2014 at 14:40
  • Wow. It could indeed be that the driver is not passing the event on (have a look at the last part here). You could try evtest instead of /lib/udev/keymap -i, dunno if that will come out any different.
    – goldilocks
    Jul 10, 2014 at 15:02
  • 1
    evtest also shows nothing when the extra keys are used.
    – user2543941
    Jul 12, 2014 at 2:49
  • 1
    Looks like maybe if you want to use those keys your project just got a bit bigger, lol. The hardest thing about writing a keyboard driver will be learning the API, otherwise they don't look so complicated. I haven't done any kernel stuff in a while, but this: LDD3 is still valid for 3.x, I think.
    – goldilocks
    Jul 12, 2014 at 9:25

2 Answers 2

Reset to default
1

The kernel sees the weird scan codes and drops them. I would try to get those scan codes values and then update the hardware database index. So in short the plan is this:

  • get the codes from dmesg output - dmesg should output something like this when the unknown keycode is pressed:

    Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0)

a0 being the code value.

  • create custom keycode mapping file. The examples and help are in the default file
    (/usr/lib/udev/hwdb.d/60-keyboard.hwdb for Arch, it may be different in other distributions).

  • update and trigger the hardware database by running the commands:

    > udevadm hwdb --update
> udevadm trigger /dev/input/eventXX

where eventXX corresponds to your keyboard (you can get it by running evtest). You may also reboot instead of triggering.

Look in Arch wiki and the default keycode mapping file for the more detailed description (or in your distribution documentation if it's not Arch).

This is the reliable and simple method, makes mapping on the kernel level so works whatever display server, DE etc is.

Improve this answer
1

This website offers custom keyboard conversions http://straypoetry.com/ibm-model-m-keyboard/

Based on information from this website: http://deskthority.net/workshop-f7/xt-at-ps2-terminal-to-usb-converter-with-nkro-t2510.html

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .