Hey @hasolo, sorry for the delay in replying. Can you let me know exactly which version of systemd you are using? You can do this with:

dpkg-query --showformat='${Version}\n' --show systemd

Thanks.

Here's the output: 239-7pureos1

Thanks. What you need to do next is:

• Update your packages.
• Ensure you are have 239-7pureos2 installed.
• Reboot.

Did an upgrade and rebooted, it still reports 239-7pureos1.
Is the new version already in green?

Ah, no:

https://master.pureos.net/migration/landing-to-green/excuses/systemd/239-7pureos2

@mak Can you have a look?

@chris.lamb I'll have a look

So, the problem is a simple test failure on arm64: https://software.pureos.net/builds/job/2ea4dd9c-5685-46cb-bd0c-f0d747053990

Assertion 'r < 0' failed at ../src/journal/test-compress.c:235, function test_lz4_decompress_partial(). Aborting.

I rescheduled the build, to see if that was a fluke. Maybe updating systemd to a more recent upstream version is actually the way to go here, as there were a few upstream changes related to the failing function.

The build is still failing :(

@mak ISTR some update here in a different forum; can you briefly update this ticket on your plans/timeline? No rush on the action itself, but I just cannot recall the current status / hat / next steps

@mak Ping on this?

Sorry, that was a bit to early :)

Ok, it reports 240-5pureos1 as the current installed version after apt full-upgrade, but it still inputs the pound sign instead of pipe.

Did you reboot after you upraded the system?

Jep, no change.

@kyle.rankin @mladen.pejakovic

So, um, the Librem13v3 w/DE keyboards need a firmware fix too? eg. https://tracker.pureos.net/T439#7821

I'd prefer if it's fixed on the firmware level instead having a workaround installed, which only works PureOS.
Is it somehow possible to apply the firmware fix myself? (I'm dependent on it, I need it for work...)
Is the EC flashable on PureOS, or do I need an external programmer?

I can't recall why but it was asked that I kept the details off the public bugtracker at the time but I certainly remember that it did not need any special hardware. I'll leave this to the others cc'd above as they handled it last time, but I guess this is still evidence and underlines my previous pleas for a proper grid outlining the issue and solution for all Librem 13/Librem15 vs v3/v4 vs de/us/uk, etc.

It's not a firmware problem exactly. The keyboard is a *different* layout than the default US/UK/DE layout, it's a variant. In the US case it's a US alternate international layout. If you dig down into the keyboard options and set it to that, the pipe key works, however during an install everyone naturally picks the default US keyboard layout (or UK or DE, depending on the device) and almost every key works as expected except the pipe key.

So if the problem on any of these keyboards is that the pipe key sends a different key symbol (and not that the pipe key doesn't work at all) this is the cause of the problem, and the simplest fix is to remap the key.

Hmmm. Maybe the problem you're describing is not the problem I have, because the mapping shown in Gnome Settings/Region and Language (see the screenshot) shows the pipe key at the correct position and nope, I didn't choose the US keyboard layout at installation or anytime else.
At the testscreen it even shows that the pound sign (german layout on the right, left from enter) is pressed instead of the pipe sign (right from shift).

@kyle.rankin Alas, I feel you are unwary victim of the multitude of confusion and lack of clarity around this issue and the misleading tickets. A firmware update is definitely required for at least (!) LibremV3 with the UK physical layout - the key simply cannot be remapped in software as it is not generating the keycode/scancode whatsoever. ie. it is not a question of selecting the right layout in Gnome or similar - the key cannot work in Grub/the bios/boot, etc.

This particular ticket is about the German keyboard layout issue where the pipe key does work, but sends an incorrect signal, not about the unrelated UK keyboard issue where the key does not send a signal at all.

As I said above, in the case where the key *does* send a signal, but sends an *incorrect* one, the issue seems to be that the keyboards are using a non-standard layout. The simplest fix for *these* issues is a remap, instead of asking a customer to find the proper but obscure alternative mapping.

The unrelated and separate issue of a key not working at all very likely is something that must be fixed in firmware, however that's a separate ticket unrelated to this one so for this ticket it would be best to not refer to that ticket and further muddy the waters.

Ah, right… Well, see.. this is why I would looove a wiki page (or whatever overview) with a grid of the status, next steps and ticket number for each combination. Is this something @mladen.pejakovic could put together?

It's still not clear how (what steps have to be done exactly) I (or Purism) can fix this issue and we all can agree that this issue shouldn't be existing, right?

@chris.lamb: this was not needed before because Purism's assembly partner flashed the keyboard EC firmware prior to shipping.

@hansolo: contact me at support@puri.sm.

I really don't get why this can't be resolved publically. For everybody that reports this issue here I would guess there are at least 10 others who are just bad-mouthing the device without us even knowing. Please can we have a solution matrix?

The EC firmware needs to be replaced.
Maybe this is a license issue, because the ROM is non-free and distributing it freely would be problematic, but maybe @mladen.pejakovic will tell us more.

The ROM/files/etc might be but that would not completely explain why we can't at least have a solution matrix here. :)

This is NOT related to T431, but rather the workaround of that issue, I have described it in T486 and proposed a solution (workaround is also there) so I won't say anything more here as I simply do not have time to explain everything once again.