Sorry if I wasn’t entirely clear the first time around–the systemctl status command was just a way to make sure the necessary systemd unit is in fact installed. That little piece of systemd is what runs the commands in rc.local at boot time, so as you discovered, all you need to do is create the rc.local file with the right commands in it.
You’re right about needing #!/bin/bash at the top too. I forgot about that because on my Fedora system the file already existed for other reasons.
Hi Dennis - thank you so much for doing the research on this before I could. I may look in to fixing this in the Debian initramfs. I have done some other things with initramfs in Debian, but I have never needed to change keymappings.
To others who might read this in the future:
If someone does happen to have \ or | in their LUKS passphrase, I suggest adding a LUKS passphrase that replaces \ with < and | with > so you will be able to unlock the device conveniently with a device that handles this key more normally. The other alternative would be to remove this key from your passphrase.
You can add a passphrase to a LUKS volume with the cryptsetup luksAddKey command. There are other places to find more details. Be careful if the data on your LUKS volume is important.
After reading an article on the Arch wiki, I came up with a more permanent fix
This uses udev and the systemd hdwb hooks provided by most upstream distros
This will work fine on the latest Ubuntu, Fedora, Arch etc
Create /etc/udev/hwdb.d/90-purism-pipe-symbol-fix.hwdb with these contents:
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v2*
KEYBOARD_KEY_56=backslash
Then execute
sudo systemd-hwdb update
sudo udevadm trigger
Now the | \ key below backspace (backslash) should work as expected permanently
Created a pull request for the hwdb defaults systemd provides
Please leave a comment on the pull request if you also experience this issue or have suggestions. Thumb up emojis also count 
This appears to work. Thanks!
Note, the file can’t have a trailing newline, and there is a single space before KEYBOARD_KEY - once I fixed those and ran the two commands again, I got pipes and backslashes immediately - thanks!
If you’re running qubes, do this in the dom0 terminal. All other vms will be affected immediately.
You need to add an extra hash-bang for the shell. So the whole file becomes:
#!/bin/sh
setkeycodes 56 43
exit 0
And you can test this with sysctl status rc-local; sysctl status rc-local.
Just bumping - This is still broken on laptops being shipped out right now. I got my laptop today and it still requires this ridiculous setkeycode command to fix every time I boot a livecd, and is unfixable in luks. Haven’t seen any response from support or a developer and it’s been, what, 4 months now? This is ridiculous.
From what I can tell, it’s a problem with the keyboard supplier more so than a problem of Purism. You could ask Purism to change keyboard suppliers, but then Librem production gets shut down for a while.
it’s a problem with the keyboard supplier more so than a problem of Purism
Lmao what? They sell a product. They are responsible for what goes out. If they’re having supplier issues then they need to inform their buyers that what they’re buying is defective. They don’t get to just throw up their hands and go “oh it’s a supply side thing” and pretend the keyboards they’re selling to people are still working.
Have you tried the solution posted in this thread by @ewout on January 8?
I’ll grant you that Purism should try to include this fix by default, but they are a fairly small company tackling very large issues. They sell a Laptop with features that no other company offers. This laptop currently has a software-fixable keyboard glitch that can be run by the user. Hardly a critical issue.
Should they post a notice on the order page or something? Probably. But that’s also why these forums exist - so users can communicate with other users about issues and their solutions.
Should Purism suspend laptop production (and thus effectively revenue)? I’d say no.
I have to agree that Purism’s handling of this is less than stellar. While it appears to be a minor issue, I know it threw me for a loop when I tried to install PureOS on my new laptop right out of the box. At a minimum, make a note of this and the steps to perform and place it in the manual. This should not be a surprise that you have to try to search for when buying new high end hardware.
This confuses me a lot. I got my Librem 13 on Tuesday. Pipe worked.
I installed 700 PureOS updates (and I think I rebooted). Pipe worked.
Today, I got 500 new packages incoming, (which also broke KDE Plasma, but that’s a different story). Pipe broken.
I tried @ewout’s solution, but no luck. With or without it, showkey gives me 43, which is proper if I understand right.
Actually, that latest update pulled ewout’s fix in from upstream, possibly breaking it for the German layout I have.
So I tried to be clever and commented the lines in /lib/udev/hwdb.d/60-keyboard.hwdb, but still no effect (yes, I ran the two commands).
Any ideas, anybody?
I have the same issue with Librem 13 and PureOS. I got the keycode 43 for Pipe and Pound Sign on a german keyboard. Udev rules or setting the keycode doesn’t work.
Thank you!
In my case in addition to leaving the space before KEYBOARD_KEY it also helps if I get the commands typed correctly
It’s completely ridiculous that this has not been resolved on a hardware or firmware level yet. It’s dissapointing that there has yet to even be a public announcment, or note in the “getting started guide” that one of the most common keys for developers doesn’t work by default. This is a huge problem for me because I regularly use iPXE to boot liveCD’s on my Librem.
I have a buspirate and have remapped keyscancodes on a ThinkPad T430S using tools by Hamish Coleman and would be interested to see if I could do it again if Librem would provide any details on the Embedded Controllers interaction with the keyboard.
@cmorche: Do you use it as a coreboot payload with the integrated wifi card?
Do you know, if that would work with USB 3.0 ethernet adapter well?
Unfortunately I still use it by booting from a live USB, however I did integrate iPXE into the Coreboot image for my ThinkPad T430S and it was able to boot from other network devices. If the drivers for your device aren’t included I think there is also a switch you can use to compile iPXE with more drivers.
As for the key presses being sent incorrectly. I’ve done a bit of digging and found that the Librem laptops all use a “ene KB3930QF-A1” microcontroller to handle the keyboard matrix translation. This microcontroller was also used a part of the One Laptop Per Child project, so the datasheets have been made public.
http://www.datasheet4u.com/datasheet-pdf/ENE/KB3930/pdf.php?id=723070
https://puri.sm/posts/roadmap-to-a-completely-free-bios/
I’ve also found a tool used for reading and writing to the EC firmware on kakaroto’s Github and was able to successfully dump the firmware of my controller. The instructions all run on an embedded Intel 8051, so I am working to disassemble it now, but running into issues…
As part of the OLPC project they released the firmware used for their KB3930 embedded controllers, and much information on how the keyboard matrix is handled can be found in the files “keyboard.c” and “keymapping.txt”. If Purism would release the source code for their implementation of this microcontroller then we would be able to alter, compile, and flash it back to the laptop to resolve the mapping at a hardware level.
http://dev.laptop.org/git/users/rsmith/ec-1.75
Hopefully the source code for the Embedded Controller used on the Librem laptops will be released, in which case it would be trivial to make this correction.
I hope my post was helpful.
Sorry for the tripple post. I figured out how to disassemble the embedded controller firmware into Assembly, however I will not release it until I have approval from Purism.
In the meantime I’ll be l learning assembly!