See my above post. There is a workaround that you put in one 2-line text file in qubes’ dom0 in order to fix the entire system.
Hiya
I’m stuck on this too. Bought my laptop in March.
First I tried:
In the tilix terminal, from @oemb1905
sudo nano /etc/rc.local
#!/bin/sh
setkeycodes 56 43
exit 0
Ctrl-X, Y, Enter.
sudo chmod 750 /etc/rc.local
sudo chown root:root /etc/rc.local
sudo reboot
It seems to be working, but I tried it twice, with no effect.
typing the sudo commands doesn’t seem to do anything much except of course sudo reboot reboots the whole computer (I kind of miss the windows option to cancel the reboot in case I forgot I had some other stuff opened that I hadn’t saved. But, to be fair reboot is what it says on the tin).
then I tried @Snorlax’
xmodmap -e “keycode 94 = backslash bar”
both in the tilix normal command line and as a super user, but it just reads: 'No protocol specified xmodmap: unable to open display ‘:0’(as super user) or it just doesn’t do anything in the tilix terminal.
I also tried evdev:atkbd:dmi:bvn*:bvr*:bd:svnPurism:pnLibrem13.2* KEYBOARD_KEY_56=backslash
in sudo but it returns
could not find the database of available applications, run update-comand-not-found as root to fix this.
Is there any further help and can the further help be written up somewhere in one place?
As obviously a lot of new Librem owners come up with those problems, it might be a good idea for Purism ( @mladen ) to collect the really relevant informations and bundle them in an obviously easily to be found spot (eg sticky thread, …).
That way purism would help sort out problems introduced by purism in a more easy manner.
(I already started messing up my system and lost track - pipe still not working on german keyboard. Probably it’s by far not me alone)
This is still an issue for me on a UK lib rem 13 v 2. I have the patched code in /lib/udev/hwdb.d/60-keyboard.hwdb and added a rc.local as above but still no luck. Any more ideas?
1 Like
Unfortunately, This doesn’t work for me running Qubes 4.
In dom0, I created
/etc/udev/hwdb.d/90-purism-pipe-symbol-fix.hwdb
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v2*
KEYBOARD_KEY_56=backslash
Then ran
sudo systemd-hwdb update
sudo udevadm trigger
Don’t believe there’s a newline and I’ve used a single space before KEYBOARD_KEY.
Nothing seems to fix the issue and extremely frustrating.
After modifying the Librem version to 3 in 90-purism-pipe-symbol-fix.hwdb file that ewout/quban specified, I was FINALLY able to get the keys to work properly in Qubes 4.0
Solution that worked for me:
Create /etc/udev/hwdb.d/90-purism-pipe-symbol-fix.hwdb with the content:
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v3*
KEYBOARD_KEY_56=backslash
Run:
sudo systemd-hwdb update
sudo udevadm trigger
Notice that the file contents specifies pnLibrem13v3* not pnLibrem13v2*
2 Likes
@ChrisD I found that it broke again after an dist-upgrade. I deleted the rc.local file, recreated these steps and it worked again. For me, this fix is still in place and working. I have, however, switched to stock Debian instead of PureOS, but previously had the problem on PureOS as well when I first wrote this. Best luck …
@dmgarland I found that the rc.local fix only works when used by itself. Try again without altering the *.hwdb and simply restarting after rc.local is created and granted proper permissions.
I’m curious why this is “more permanent” than editing rc.local @ewout as I and some others suggested. Can you explain? Is it because rc.local is considred legacy on Debian / PureOS?
Yep. systemd’s hwdb is what most (if not all) distro’s use for working around buggy/faulty input devices. The Purism keyboard fix has been upstreamed to systemd’s hwdb quite a while ago. Simply updating the system should be enough to fix the backslash key.
It seems, that the fix is just for the UK and US layout, the DE layout is still affected (me)
1 Like
On my laptop, that was delivered this week, there is, in fact, a
KEYBOARD_KEY_56=backslash
entry in /lib/udev/hwdb.d/60-keyboard.hwdb for pnLibrem13v3.
Unfortunately, the pipe/backslash key on my keyboard sends less-than and greater-than symbols (even after a full apt update and reboot).
I am guessing that the keyboard or laptop model may have changed again … like to 13v4?? I see no documentation on how to discover these modalias keys required in the hwdb config files.
So I’ll be trying the setkeycodes fix instead.
I did find my laptop has a “v4” sticker on the bottom. I did not attempt to change the modalias key to use v4 instead of v3 because the setkeycodes fix is working so far.
The hwinfo command shows the modalias for the keyboard:
$ sudo hwinfo |grep svnPuri
E: MODALIAS=dmi:bvncoreboot:bvr4.8.1-Purism-4:bd01/16/2019:svnPurism:pnLibrem13v4:pvr4.0:rvnPurism:rnLibrem13v4:rvr4.0:cvnPurism:ct9:cvr:
So Purism has a bug in /lib/udev/hwdb.d/60-keyboard.hwdb. They updated the model key to rnLibrem13v4 but failed to add an entry to /lib/udev/hwdb.d/60-keyboard.hwdb.
1 Like
This was right on the money. As a complete noob to Linux and qubes, I figure I’d go into a little more detail with the instructions so others like me don’t have to experience the same emotional roller coaster. I was able to create that file “/etc/udev/hwdb.d/90-purism-pipe-symbol-fix.hwdb” by using the command “sudo thunar” in the dom0 terminal emulator. Then I typed “sudo nano /etc/udev/hwdb.d/90-purism-pipe-symbol-fix.hwdb” into the terminal. It launches a cli text editor. I typed in the two lines ewout advised making sure there was a space before KEYBOARD_KEY_56=backslash. I have a Librem13v3 and I had to modify the line “evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v2*” with “evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism:pnLibrem13v3*”. I hit enter, and ctrl+O to write the two lines in nano, then ctrl+X to exit. I typed the remaining two sudo commands in the terminal, and the | key started working immediately. Thanks to ewout and quban. 
2 Likes
I’ve had a similar problem, but with the librem v4 of course. I’m wondering if we should just make that wildcard pnLibrem13v* instead of pnLibrem13v3*…
i have to test and see if that actually works, still.
well, I can pretty much guarantee that the 13v5 won’t have this issue 
1 Like
weeeell… we’re already two revisions later, so allow me to doubt you a little here. 
I think the last two revision were rather minor. Possibly the component in question was never updated.
no, we’re still using the exact same board/EC (which is where the problem is). We won’t be for v5