Hi,
I’d been waiting to get a librem laptop for so long, and I got my wish granted today when it came home in the mail. Unfortunately, I was disappointed almost as soon as I booted off the gentoo livedvd, because the |\ key north of the enter key doesn’t work. Every | is reinterpreted as > key and every \ is reinterpreted as <.
Edit: It appears that in this thread they detail a partial solution to this problem by manually remapping the keycodes. This is a hardware issue with the keyboards Purism is selling. I shouldn’t have to go out of my way to find an unstickied thread on the purism forums and then enter a command every time I boot just so I can pipe output. If purism knows about this then they should either stop sending out laptops until they fix their hardware or send an email to everyone who buys them telling them they need to implement this workaround if they want to type correctly.
He’s using gentoo, not PureOS. Fixing it via systemd doesn’t work anyways because gentoo uses openrc by default and for its installer, which is what he is trying to work with. This is a hardware problem and needs to be fixed hardware/firmware wise, not through a systemd patch.
I feel like I’m being a dick about this but that’s not a fix, it’s a software coverup of a hardware issue, and its a coverup only for the segment of your customers that use your linux distribution instead of Qubes or Gentoo or Arch or whatever.
Using Qubes here so I also do not use Pure OS. I asked mladen for help on an email and received the same link to the thread that is anything but straight forward so my pipe key still does not work.
In the case of Qubes I think you can follow these directions in dom0 since Qubes is based off of Fedora. Since Fedora also uses systemd you could try this as well.
I’ve 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. There is no issue in Qubes 4 RC5.
Are there any plans to fix this in Coreboot or on the Embedded Controller? I am also using Qubes and having to remap my keys with a script is quite unfortunate when this was a hardware/firmware issue. I am using the Librem 13v3 with a US layout.
Look, this is completely ridiculous to see from a laptop geared for Linux. The pipe character is essential to any terminal workflow. It definitely doesn’t take a year of “looking into this”.
I just bought a Librem 13 v4 in the mail, got a v3 since apparently paying for v4 doesn’t mean anything, two of the screws on the back came stripped which made installing the nVME hard as hell without breaking anything, and it still has old issues like this.
What is Purism doing over there? I already pre-purchased a phone, but honestly it’s not looking like I made the right decisions at this point.
Sadly, the problem is with the Embedded Controller which is actually closed source (even to Purism). It’s actually quite surprising that the controller being used to handle ALL laptop keyboard input, charging and battery communication, and much more, is something we have no view into, modifications aside.
I did some research when I first got my Librem 13 v3 and found out the EC is the same one used in the OLPC laptop (something I actually did a lot of work on). The source was released, along with a lot of information on it. I’ve done BIOS/EC keyboard mapping swaps before with the ThinkPad T430S, so I figured maybe I might have a shot helping out. I emailed Youness Alaoui before he left Purism, and he gave me a very stern warning against messing with the Embedded Controller as much has changed with it since it was used in the OLPC, and they do not know any details.
I do agree that this is ridiculous though to keep using such hardware in, how many models/revisions now??
Rant aside, I love my Librem 13 more than any other laptop I’ve owned
Qubes can be fixed by adding a one-liner to a dom0 config, it took me quite a bit of digging to find it, but if people are still having issues I can find it again and post it here. It is an incredibly annoying issue though, considering how many commands need | to work.
