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.
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.
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.
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.
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.
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.
@cmorche: Thanks for the tip! I also use iPXE on an X220 with Coreboot.
Maybe we should ask @kakaroto to include an option for additional payloads into their script, so that you can configure iPXE and additional settings for e.g. driver.
I spoke with Youness/KaKaRoToKS via email and he informed me that they do not have the source code for the embedded controller after all, otherwise they would have released it.
I was however able to use an Intel 8051 disassembler called B52 to convert the dumped firmware into Assembly code.
You should be able to do all of this on your own Librem (at your own risk, and only using the read switch). I am not sure on the legality of posting the reverse engineered source so I will abstain from that until given further notice.
Youness very strongly discouraged any movement on this project as there is not a feasible way to recover the embedded controller from a bad flash. At this point, I am mainly interested in understanding the Assembly functions within the attached code from my Librem 13v3. I think the best bet would be to compile a similar EC firmware intended for the OLPC, then run it through the same disassembler just to see how they compare. Please note, I am a novice reverse engineer so take all of this with a grain of salt.
I did also receive the below message from Youness regarding a new EC firmware that would be open source. I’ve pasted the content of his reply below.
The good news is that we do have the developer of Origami-EC working
on finishing his project and making it work for the librems as well.
You can also read this thread for more information : https://www.mail-archive.com/coreboot@coreboot.org/msg51060.html
(the new thing from there was that Paul K is now working on porting
origami-ec for the librems).
No, the EC firmware is much smaller 64k I believe. The EC only handles things like sending keystrokes to the OS, interfacing with the battery and power states, etc. The chip that holds Coreboot is completely separate and that chip can be reflashed fairly easily. The EC, however, cannot.
Thus I don’t see any progress being made on this unless Purism is able to offer some information, like did they just purchase off the shelf embedded controllers, or did they work to customize the firmware for this laptop?
Check out my blog if you want more information on the seperation of the BIOS and EC, specifically with ThinkPads.
I was flummoxed by Qubes requiring this command in each app/template VM as well as dom0, but putting this in a startup script is a viable workaround. There are probably many ways to fix this issue!
The fix that works for me is on here, but it is either lengthy, incomplete, or hard to remember when I do a fresh install for whatever reason. Here is the solution that works for me condensed. From a shell,
