Duplicate scancode for '\' and '#' keys

Librem
#1

I have a Librem 13v2 with UK keyboard layout. Apart from some power issues, for which I had to send it in for repairs, it has worked wonderfully. I am running Debian with KDE Plasma on the laptop.

Then recently I noticed that the ‘’ and ‘#’ keys give the same character, and by using showkey -s the scancode is 0x2b. When in UK-layout I get ‘#’ and when in US layout I get ‘’. It is not an OS-related problem, since when I edit an entry in GRUB, the two keys also give the same character.

I am fairly certain that this is something that have changed recently, because writing in LaTeX and programming in Python would certainly have had me notice it early on, and there was no problem some time ago.

To my level knowledge, I think that this is a hardware issue since scancode -s, as I understand, is very low level. Can anyone confirm this? Does anyone have the same issue?

P.S.: I have observed the posts Both INT 1 and INT 2 keys on Librem13v2 UK keyboard dead and Keyboard layout unable to recognize pipe which seem related, but not really the same problem.

2 Likes
#2

As you saw in the “Keyboard layout unable to recognize pipe,” there seems to be an issue with the keyboards sending non-standard scancodes (though you are the only one I’ve seen report the ‘#’ character has issues). But that same thread includes a systemd-based solution to permanently re-interpret the scancodes as desired. I would think you could modify the solution in that post to suit your needs.

But yes, based on what I’ve read in the other threads, it’s ultimately a hardware issue.

1 Like
#3

Yes, I was thinking the same as I read the pipe-issue. But as I set out to try re-mapping the scancodes, it struck me that since the two keys sends the same scancode, they are indistinguishable. This is exactly what separates my issue from the two issues referred.

#4

Ah, yes, that’s true. Hmm, that is problematic. I don’t think I can provide further help then.

1 Like
#5

“scancode -s, as I understand, is very low level. Can anyone confirm this?”

It is fairly low level (i assume you mean showkey -s) , certainly compared to xev there is less ‘stuff’ between you and the physical keyboard. It works by feeding off the input to the virtual console, so basically it is printing out the raw value of whatever is send to the virtual console. As the console is a great deal simpler than how Xorg deals with events, you could call this ‘low level’. you are also seeing the codes before they get mapped to keyvalue’s (such as ‘a’) Personally i prefer evtest myself.
Do be aware that there is a bunch of things going on before its gets to the virtual console (not least the IRQ events being translated to codes by the kernel).

1 Like
#6

@graham, Thanks for that information. Do you have a pointer to understand how the stuff below the “showkey -s” level, as you correctly write, works and how to configure it? And, more interestingly, do you have a clue what may have gone wrong in my setup, if it is not a hardware error?

#7

Through tips from @mladen experimentation, studying https://tracker.pureos.net/T486 and some evtesting on a working laptop, I was able to find a not so intuitive solution. evtest showed me that the the \-key sends code 0x56 and the #-key sends 0x2b. Creation of an override file /etc/udev/hwdb.d/90-purism-backslash-key-fix.hwdb with the following contents solved my problem:

evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v2*
 KEYBOARD_KEY_56=KEY_102ND  # The backslash key sends 0x56 
 KEYBOARD_KEY_2b=KEY_BACKSLASH  # The hash sign key sends 0x2b

(No, the associations are not the wrong way around!)

Backslash key not working