Pipe key producing # on Librem 13 v2, v3 UK and DE model devices
Open, HighPublic

Description

Directly related to T431.

Librem 13 v2, v3 US model devices have a wrong mapping of the pipe key. We introduced a workaround in PureOS and forwarded it upstream. However, the workaround also affects UK and DE models which do not have this problem! The result is that the pipe key on these models is now acting like the # key.

A stable workaround is to add file /etc/udev/hwdb.d/70-keyboard.hwdb:

# Purism Librem 13 V2/V3/V4
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v[2-4]*:pvr*
 KEYBOARD_KEY_56=102nd

and running:

sudo systemd-hwdb update
sudo udevadm trigger

which enables correct functioning of the pipe key again on UK and DE models.

I suggest the following:

  1. Remove the workaround from our systemd as well as removing it from upstream (hardware manufacturer should deal with the bug at the keyboard EC firmware level themselves);
  2. For affected hardware create a separate package with the workaround,and instruct users with the hardware to install the package.

Another solution:

Create a package with hwdb files that will revert this workaround from systemd and instruct users with Librem 13 UK/DE devices to install it.

mladen created this task.Jun 19 2018, 9:29 AM
mladen created this object with edit policy "Restricted Project (Project)".

However, the workaround also affects UK and DE models which do not have this problem

Urgh. This is a total mess :(

First, are we 100% sure that removing this fixes it for UK? I have a Librem13 v3 with a UK keyboard but I am pretty positive I needed the firmware fix to make it work *even in Grub*. Thus any change to hwdb seems orthogonal.

Secondly, would this not regress everyone on a US device? Therefore requiring the majority of our users to get the firmware update? I worry that many would just apply dirty hacks to their own systems, thus making it harder to debug the issue.

I suggest we take extra care with precise communication around this issue to prevent having to make any *further* changes to this and really get it right this time. :)

First, are we 100% sure that removing this fixes it for UK?

Yes, a user tested on his device.

I have a Librem13 v3 with a UK keyboard but I am pretty positive I needed the firmware fix to make it work *even in Grub*.

That was different issue. :D

Secondly, would this not regress everyone on a US device? Therefore requiring the majority of our users to get the firmware update?

Yes, indeed.

I worry that many would just apply dirty hacks to their own systems, thus making it harder to debug the issue.

How about creating a package and instruct users to install it? The package will just contain the hwdb file with the fix.

> I have a Librem13 v3 with a UK keyboard but I am pretty positive I needed the firmware fix to make it work *even in Grub*.

That was different issue.

Wait, what? Please clarify this in as much detail as possible. This is not only to benefit anyone else reading/following this, the conflation and confusion of all these interrelated issues is a cause for concern moving forward. Perhaps a table of the models vs the keyboard layout and their status wrt to this bug is required. Or multiple tables, as you are now implying there are multiple issues...

How about creating a package and instruct users to install it? The package will just contain the hwdb file with the fix.

Sorry, I don't follow this. *Exactly* what fix are you referring to? What package? (systemd?..if so, that does not make sense as you are suggesting we remove something from hwdb)

mladen added a comment.EditedJun 19 2018, 11:11 AM

Purism's Librem devices come in few variants: Librem 13 and Librem 15, with US, UK and German keyboard layouts.


Librem 13 US devices have incorrect key mappings in their keyboard EC firmware, it is not fixed yet by Purism.

Librem 13 and 15 UK devices *had* an issue where two keys haven't been mapped at all, but Purism flashed fixed keyboard EC firmware to all un-shipped devices and RMAed all devices which were shipped before the issue is discovered. (Some users asked to flash the firmware themselves.) UK devices no longer have any hardware issues with keyboard.

Librem 13 German devices do not have any hardware issues with keyboard.


Systemd applies a software workaround for Librem 13 v2 and v3 devices so that the keys on those devices are correctly mapped. However, it turns out that this also remaps keys on UK and DE devices, which do not have any hardware problems.

My suggestion:

  1. Revert the workaround in systemd (also upstream), ie, remove this part from /usr/lib/udev/hwdb.d/60-keyboard.hwdb:
# Purism Librem 13 V2
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v2*:pvr*
 KEYBOARD_KEY_56=backslash

# Purism Librem 13 V3
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v3*:pvr*
 KEYBOARD_KEY_56=backslash
  1. Create a package (for example named "librem13us-keyboard-fix") with just one file /usr/lib/udev/hwdb.d/60-keyboard-librem13us.hwdb, with the following content:
# Purism Librem 13 V2
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v2*:pvr*
 KEYBOARD_KEY_56=backslash

# Purism Librem 13 V3
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v3*:pvr*
 KEYBOARD_KEY_56=backslash

and tell people with affected devices that they can workaround their keyboard issue by simply installing "librem13us-keyboard-fix" package.

systemd applies a software workaround for Librem 13 v2 and v3 devices so that the keys on those devices are correctly mapped. However, it turns out that this also remaps keys on UK and DE devices

So, I have a UK device and am not seeing this subsequent remapping. What, exactly, should I be looking for?

mladen edited the task description. (Show Details)Jul 5 2018, 4:11 PM

(Diff of description appears to be:)

- Removing the lines from `/usr/lib/udev/hwdb.d/60-keyboard.hwdb`:
+ Removing the lines from `/lib/udev/hwdb.d/60-keyboard.hwdb`:

:)

mladen added a comment.Jul 5 2018, 9:05 PM

Yes, there was a typo. :)

So, I have a UK device and am not seeing this subsequent remapping. What, exactly, should I be looking for?

Sorry, I just realized I never replied: L15 is not affected, and only OSes with latest systemd are affected.

In T486#8954, @mladen.pejakovic wrote:

Yes, there was a typo. :)

So, I have a UK device and am not seeing this subsequent remapping. What, exactly, should I be looking for?

Sorry, I just realized I never replied: L15 is not affected, and only OSes with latest systemd are affected.

I have a L13 so by your logic I should be affected. I am not.

@mladen.pejakovic Hey hey, what's the status of this? I'm just wondering what my next steps here — the ticket is currently assigned to me, but I have no obvious 'next action' as far as I can tell.

mladen added a comment.Sep 7 2018, 5:43 PM

@chris.lamb Let's hand it over to Mak?

@mladen.pejakovic For what purpose? (What can he do here that I cannot?)

@mladen.pejakovic and @chris.lamb (cc @todd )

I've read and re-read this whole thread,
to help put this issue to bed,
Mladen and Chris,
the thing I still miss,
which models don't work like we said?

@kyle.rankin

Librem 13 US models have a problem with their keyboard EC firmware, causing the pipe key to give incorrect scan code.

Librem 13 UK and Librem 13 DE devices do not have this problem.


We introduced a software fix for this problem (actually, the workaround is applied upstream, systemd), check the file: /lib/udev/hwdb.d/60-keyboard.hwdb, section Purism:

###########################################################
# Purism
###########################################################

# Purism Librem 13 V2
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v2*:pvr*
 KEYBOARD_KEY_56=backslash

# Purism Librem 13 V3
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v3*:pvr*
 KEYBOARD_KEY_56=backslash

This above workaround fixes the problem with Librem 13 US devices, but it has negative effect on Librem 13 UK and Librem 13 DE devices, because systemd applies this fix for them as well, causing their pipe key to give scan code of the # key: https://forums.puri.sm/t/librem-13v2-german-keyboard-pureos-angle-brackets-pipe-key-dysfunctional/2828

@chris.lamb Since you have a UK model, could you please apply the patch @mladen.pejakovic is referencing above and see if you can recreate this regression?

Kyle, alas I think you are regrettably missing a lot of back-and-forth on this issue. The UK Librem 13 does have this issue in the sense that I needed to apply a /keyboard firmware/ update to fix it. No systemd patch could have possibly fixed it. There is nothing for me to apply now given that I applied the "BIOS"-level update.

This is why I'm trying to narrow everything down to specifically which models are having the specific issue referenced in this ticket. Today I've gotten two different explanations:

  1. UK and DE Librem 13s with a functioning | key suffer a regression when applying the systemd update aimed at US Librem 13s.
  1. Chris's UK Librem 13 suffered from a possibly different issue prior to this systemd update (that ideally has its own ticket) that required a keyboard firmware update.

So far am I on the right track?

Today I've gotten two different explanations

This additional distinction is new to me, alas. /o\ I did not regress after applying a systemd update; the systemd updates did nothing. This would suggest this is another, separate, issue that needs cataloguing and triaging. AIUI there are some (private) tickets elsewhere around Purism too, adding to the. An, there is another ticket for US devices! What a mess! *grin*

@jonas.smedegaard Can you briefly chime in with your exact model and whether you have applied a BIOS/firmware-level update? :)

I use a Librem 13 v2 UK (see T443).

I have not applied any firmware update since I received it last fall.

lshw reports motherboard as "product: Librem 13 v2" and "version: 2.0", and firmware as "version: 4.6-a86d1b-Purism-4" and "date: 06/29/2017".

@jonas.smedegaard are you able to recreate the problem listed in this ticket with your Librem 13 UK?

jonas.smedegaard added a comment.EditedSep 11 2018, 5:49 PM

Yes, my _problem_ is that pipe key gets mis-interpreted (see T443).

I cannot _fix_ my problem through changing udev files, however: Like Chris, my problem is experienced also in Grub - i.e. before udev is loaded at all (and was experienced last fall - I seem to recall the udev change was applied in Debian later).

@mladen.pejakovic so far we don't have anyone in-house who is able to re-create this specific problem but clearly you are getting some kind of support request that motivated you to file this ticket.

I'm wondering whether it makes sense to have one of these customers who is experiencing this problem to try the same firmware solution that worked for Chris (if possible) and see if that is the solution we want to use going forward, or not.

lshw reports motherboard as "product: Librem 13 v2" and "version: 2.0", and firmware as "version: 4.6-a86d1b-Purism-4" and "date: 06/29/2017".

@jonas.smedegaard What does your dmidecode report for Product Name?

Also, you probably meant on T443 here.

Result of running dmidecode -s baseboard-product-name as root:

Librem 13 v2

I believe lshw uses dmidecode internally, and I therefore more answered above already - but more sloppily: Thanks for reminding be of how to find the concrete command :-)

(and yes, I mistyped the issue above - corrected now)

dmidecode -s system-product-name provides same result - if that is what you wanted.

The full contents of /sys/class/dmi/id/modalias (usable for udev matching):

dmi:bvncoreboot:bvr4.6-a86d1b-Purism-4:bd06/29/2017:svnPurism:pnLibrem13v2:pvr2.0:rvnPurism:rnLibrem13v2:rvr2.0:cvnPurism:ct9:cvr:
chris.lamb removed chris.lamb as the assignee of this task.Oct 1 2018, 2:21 PM
chris.lamb added a subscriber: chris.lamb.

I'm going to go ahead and make the executive decision of un-assigning myself from this ticket - feel free to assign back if there is a "Next Action" for me of course, but I do not have an obvious step to proceed.

mladen edited the task description. (Show Details)Oct 17 2018, 5:05 PM
mladen edited the task description. (Show Details)Oct 17 2018, 5:15 PM

@kyle.rankin @mladen.pejakovic

so far we don't have anyone in-house who is able to re-create this specific problem but clearly you are getting some kind of support request that motivated you to file this ticket.

OK, I'm one of those customers.

I've got a Librem13v3 with a German (DE) keyboard. I'm using Debian Buster but since you upstreamed the workaround mentioned by Mladen (see task description) my pipe key produces #. When I remove the lines…

# Purism Librem 13 V2
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v2*:pvr*
 KEYBOARD_KEY_56=backslash

# Purism Librem 13 V3
evdev:atkbd:dmi:bvn*:bvr*:bd*:svnPurism*:pn*Librem13v3*:pvr*
 KEYBOARD_KEY_56=backslash

…from /lib/udev/hwdb.d/60-keyboard.hwdb and restart my pipe key works as expected. Please tell me if you need more information.

I'm wondering whether it makes sense to have one of these customers who is experiencing this problem to try the same firmware solution that worked for Chris (if possible) and see if that is the solution we want to use going forward, or not.

I don't get that… You want someone who is affected by an issue introduced by a workaround to try a firmware solution?

JK added a subscriber: JK.Oct 30 2018, 5:39 PM

I received my Librem 13 v2 with UK keyboard today and the pipe key is also mapped to hash\tilde.

There is no

/lib/udev/hwdb.d/60-keyboard.hwdb

for me to amend- indeed there is no file in that directory at all.

indeed there is no file in that directory at all

Is it possible that you are talking about /etc/udev/hwdb.d/? If your /lib/udev/hwdb.d/ is empty: which OS are you using?

JK added a comment.Oct 30 2018, 5:54 PM

Is it possible that you are talking about /etc/udev/hwdb.d/? If your /lib/udev/hwdb.d/ is empty: which OS are you using?

Yes, thanks! I was looking at the wrong directory.

I've removed the Purism lines as above from the /lib/udev/hwdb.d/60-keyboard.hwdb and restarted but still getting hash\tilde for the backslash\pipe key.

Using PureOS.

This comment was removed by stefannagy.
JK added a comment.Oct 30 2018, 5:57 PM
This comment was removed by JK.

I've removed the Purism lines as above from the /lib/udev/hwdb.d/60-keyboard.hwdb and restarted but still getting hash\tilde for the backslash\pipe key.

Run:

sudo systemd-hwdb update
sudo udevadm trigger

Make sure you don't have any other hack or workaround applied.

JK added a comment.Oct 30 2018, 6:33 PM
In T486#11164, @mladen.pejakovic wrote:

Run:

sudo systemd-hwdb update
sudo udevadm trigger

Make sure you don't have any other hack or workaround applied.

Working now, thanks.

tanuk added a subscriber: tanuk.Mar 8 2019, 7:21 AM
mladen edited the task description. (Show Details)Apr 9 2019, 3:55 PM
mladen edited the task description. (Show Details)Jun 21 2019, 8:56 AM

Since this bugreport may be used as inspiration for users wanting to work around the issue, I have adjusted the description to talk about adding file below /etc, because editing existing file below /lib is lost when package udev is updated.

Thanks Jonas!

Add Comment