Strange keyboard scancodes (showkey -s) Topic is solved

[kuzmandi]

Hello everyone,

I've discovered strange behavior that I can't explain to me and would like to know whether this is reproducible for anyone of you or whether someone can tell me what exactly is going on here. I've been looking for information for a few hours now and haven't found anything useful.

The command showkey -s returns the scancode of every pressed (or released) key. The scancode is independent of the keyboard layout, since the country-specific differences are only key labeling. The scancode is generated by the keyboard itself and, as far as I know, cannot be changed. In order to assign a behavior to a key there is a translation table in the operating system which assigns a key code to a scan code (e.g. the character "A" for the scan code 0x1E).

So much for the introduction.

If I connect my keyboard (CHERRY Type: RS 6000 USB ON, P/N: G83-6104 LUNEU-0/04) to a PC w/ Linux Mint 18.3, I can read all scan codes correctly (e.g. 0x01 for ESC key). The extended keys are also recognized correctly (e.g. 0xE0 0x38 for right ALT).

If I connect the same keyboard to the Raspberry Pi 3B w/ dietPi 6.34.3, all scan codes are output correctly, except all with extended scan codes. Instead of the dual output (0xE0 0x..) it shows a single hex code which I can't find in any table of any information on the internet.

Examples:

Code: Select all

Cursor left:
  PC/Mint     : 0xE0 0x4B
  RasPi/dietPi: 0x69
Cursor right:
  PC/Mint     : 0xE0 0x4D
  RasPi/dietPi: 0x6A
WIN left:
  PC/Mint     : 0xE0 0x5B
  RasPi/dietPi: 0x7D
WIN right:
  PC/Mint     : 0xE0 5C
  RasPi/dietPi: 0xFE
Keypad ENTER:
  PC/Mint     : 0xE0 0x1C
  RasPi/dietPi: 0x60

Is that a configuration problem, a defect or a mistake on my part? Did I get something wrong?

Please leave an answer if you have any idea ...

[Joulinar]

Hi,

I did a test an a RPi3B+ 32bit OS and RPi4B 64bit OS. In both cases it is working more or less

[kuzmandi]

Thanks a lot! It seems to work in the same way, the codes are the same as I get (I have only posted the Makecode, not the Breakcode).

Looks like my own experience.

But: It seems to be not right, because everywhere you look for scancodes lists online, you will see the codes beginning with 0xE0 for extended Keys (i.e. cursor). I can't explain this behaviour, it looks like simplified codes but does not match with any scancodes types, HID codes or something else.

Has anyone time to check this with an other Linux type on RasPi vs. dietPi on PC? Does anybody knows about different keyboard working modes via USB which could cause this?

--

This is a nice page which shows a keyboard with all its scancodes (legend overlay):
http://kbdlayout.info/KBDGR/virtualkeys

A bit confusing, but useful: (Nevertheless, the numbers have nothing to do with the scancodes I get on RasPi/dietPi.)
http://www.scs.stanford.edu/09wi-cs140/ ... des-9.html

[Joulinar]

you could try to flash normal Raspbian OS to check how it is behaving.

[kuzmandi]

I have now tried different hardware and different operating systems. I was able to determine that the strange scan codes always occur on the Raspberry Pi and never on x86. It doesn't matter which keyboard I use, it doesn't make any difference.

I've tried dietPi, Raspbian and Ubuntu Server with the Raspberry Pi and kept getting always the same (strange) scan codes. Vice versa, I also tried dietPi on x86, the correct scan codes appear there.

It seems to be a Raspberry Pi thing.

(But even if that is not a DietPi thing I would like to pursue the matter here.)

I have a 3 Model B.

Unfortunately I don't have any other type of Raspberry Pi at hand, I would be interested in whether they also output the codes I have described with showkey -s. Would anyone with a RasPi Generation 1, 2 and/or 4 running with any Linux be so kind to test this out? It would also be interesting whether other ARM hardware behaves like this.

Simply enter showkey -s at the Linux prompt, press the cursor keys and tell me which codes are displayed.

[Joulinar]

as already written above, for me this is working same way on RPi3B+ 32bit OS and RPi4B 64bit OS

[kuzmandi]

Of course, thank you for trying this out.

Maybe someone else is reading here and can try it out with another RasPi model?

(If I should follow up the matter in another forum, I will post a link here. Nothing is more frustrating than threads that describe your own problem but end up without a solution.)