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.
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.
Librem 13v2, German keyboard & PureOS: "angle brackets & pipe" key dysfunctional
@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.
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.
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!
@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.
Either, it isn’t Purism’s to release or they would have released it, I would assume.
I guess the first part is true … ??? Should we ask?
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 :
(the new thing from there was that Paul K is now working on porting
origami-ec for the librems).
The EC firmware and the coreboot image is on the same flash chip (MX 25L512E)?
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.
This thread and https://ubuntuforums.org/showthread.php?t=1325093 led us to a solution:
xmodmap -e "keycode 94 = backslash bar"
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,
sudo nano /etc/rc.local
Put this in the file.
setkeycodes 56 43
Ctrl-X, Y, Enter.
sudo chmod 750 /etc/rc.local
sudo chown root:root /etc/rc.local
Thanks to logicprobe and dirkx …
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.