Librem 13v2, German keyboard & PureOS: "angle brackets & pipe" key dysfunctional

After installing PureOS on my Librem13v2 with a German keyboard, the “|<>” key is not working, but instead it is behaving exactly like the “’#’” key.

I am aware of the posts The "| + \" key on the keyboard doesn't work, and installing non-gui distributions is impossible and Keyboard layout unable to recognize pipe , however nothing suggested there worked for me.

A parallel native Manjaro Linux installation produces the same issue.

But: when live-booting into Arch Linux 3.17.4-1-ARCH, both of the above keys work as they should, before and after doing

root@archiso ~ # loadkeys de-latin1

(which I used to do on a Lenovo T440 with German keyboard layout.)

Can anybody recommend a workaround for this (PureOS?!) issue? Any suggestions welcome. I am stuck and out of ideas, the new machine is sitting lonely in a corner catching the dust. Poor thing.



Since you asked for it, buy El-Cheapo™ €5 USB keyboard and use that until proper fix is available from Purism. Not that great suggestion, but I am under impression that this issue is not fixable in software…

Edit: Also, contact technical support via mail (, so they can support you better.

Right, that’s what I am going to do for now, my old Cherry keyboard (about twice as large as the Librem) does still work.

I have contacted the technical support a few days ago, waiting for instructions from their side.

Sorry, we have no workaround yet, but I’ll try to see what’s so special about Arch that have those keys working.

Also in QubesOS R4.0 and Ubuntu 16.04 this keys are working fine.

AFAIK the special key code mapping was contributed to debian upstream so that up-to-date distros like Arch Linux (which compiles from up-to-date sources) may already have incorporated this patch.

Not working fine in Qubes 4.0 with my en_US.utf8

sudo setkeycodes 56 43 worked for me


@max4: Do you use the latest recent version of Qubes 4.0 or you did an upgrade?
German keyboard with german layout and en_UK.utf8 locale is working fine for me.
I didn’t have to set any key codes.

Sorry, I missed the “German” part of the thread. I am using the US keyboard and have the pipe backslash issue, as many others.

It should have posted here but I guess I jumped between threads for a solution a bit to many.

Pardon my mistake

I fixed it on my machine with german keyboard the following way, after some research here and on the archwiki…

  1. Create the file /etc/udev/hwdb.d/90-purism-german-keyboard-fix.hwdb with content:
  1. systemd-hwdb update
  2. udevadm trigger

@max4: Yes true, that’s the more interesting part, cause of the embedded controller firmware.

Just was wondering. So, no problem. It’s looks like the same issue, but it’s slightly different.
The patches don’t work for the german keyboard and the issue occurs mostly only in PureOS.

SUCCESS! Thanks, @elsurion, this works perfectly.

EDIT: I removed the quote of @elsurion’s post, as it was not displayed properly here (missing space before “KEYBOARD_KEY_56…”). Thanks for pointing it out, @Caliga.

Unfortunately this fix doesn’t work for me. There is a message that says:
“Property expected, ignoring record with no properties”

Has anyone an idea?

Thanks and greetings

Sure. Put a space in front of the second line, just as @elsurion has. You’re welcome :wink:
Hm… @antimon maybe you can fix or remove the quote in your message to avoid confusion?

It works…

Thanks and greetings from Cologne

Explanation of this issue:

1 Like

Tried your suggestion step by step which worked out fine, but still having the same wrong mapping on the german keyboard # ’ ’ instead angle brackets & pipe.

Had to create the folder hwdb.d myself. Didn’t exist. Might that have to do with that nothing changed?

(i’m not from a linux-background unfortunately)

I had this issue when upgrading a Librem 13 v3 from Debian 9 stable to unstable. With stable, the <, > and | key worked, after upgrading to unstable and rebooting it did not anymore. @elsurion’s solution had to be adjusted a bit, replacing the “v2” with a “v3” - also see