Purism Librem 14 v1

[dallas87]

Qubes-HCL-Purism-librem_14-20220312-173555.yml (847 Bytes)
Here is my HCL report

[Sven]

Thank you @dallas87 for your HCL report, which is online now.

[Sven]

Thank you @bungali for your HCL report, which is online now.

[Sven]

From the posts in this thread, I see the following issues reported with R4.1 (maybe even in general)

@ewokky

• wifi radio is missing when resume from standby
• 3.5mm does not work

@Honza

For audio jack make sure you have installed lastest corebot or pureboot firmware. […] you have to manually change Output device in audio mixer. […] For charging and discharging behavior make sure you have latest EC firmware installed […] and librem-ec-acpi-dkms […] in dom0. […] For wifi after wake up you probably need add correct modules in sys-net /rw/config/suspend-module-blacklist

@whoami

I did a manual pass-through […] Now, wi-fi connection works even after reboot but two issues remain:

• when doing a wi-fi killswitch off and one again (when everything is booted) wi-fi do not recover.
• wi-fi LED light is always off right after LUKS decryption / QOS booting

This does NOT sound to me like the criteria “Graphics, networking, audio & suspend work without troubleshooting” is fulfilled. Are these all new issues with R4.1 or were those issues also present in R4.0?

[whoami]

@Sven

This does NOT sound to me like the criteria “Graphics, networking, audio & suspend work without troubleshooting” is fulfilled. Are these all new issues with R4.1 or were those issues also present in R4.0?

I cannot comment on R4.0 vs. R4.1 but for R4.1:

• Graphics: Only a kind of graphical delay when entering the LUKS password and the terminal looks a bit weird during LUKS boot. I do not see it critical but yes purism should get it fixed.

• Networking: Only the hardware killswitch on/off requires a tweak¹. I also would not define it as critical since I guess if you would perform the same action with an external wifi hardware (unmount & mount) you will face the same issue. tbd

• Audio: Works without any issue on my device. But I did not make a detailed audio performance check. Volume control works and the sound is clear.

• Suspend (to RAM): Maybe this could depend on the active GB you send to your available RAM. I had no issues. Sleep and weak up worked.

¹ I still could not fix it but others did it with a pci reconnection script.

[Sven]

Thank you @whoami, I will restore the Purism Librem 14 v1 to the community recommended list then.

[dom0]

Remarks

Everything that was working on QubesOS R4.0 is working on QubesOS R4.1, and I am loving the update! I love that the Qui-Domains application now includes the option to open a file manager in any running qube. I love the new qube icons and the visual direction that QubesOS is going. And I love the immense speed improvements that I am experiencing (though that could be in part due to installing QubesOS R4.1 on a newer, faster, and larger SSD and leaving more empty space available on it). Where qubes would take up to 12 seconds to boot on my previous R4.0 installation on my older drive, qubes now boot in 3 to 5 seconds, and my Qubes Manager takes 1 to 2 seconds to load as opposed to the 30 seconds or more on my previous installation.

The only issue that I have seen is that there are visual glitches of the mouse cursor when moving it across a button or other item that causes the cursor to change appearance (such as the border of a window, in which the regular mouse cursor arrow becomes a window resize arrow). And there are also some visual glitches that others have mentioned when on the Luks decryption screen.

However, I need to make a correction on my original post at the top of this thread. When I tested that the headphone jack worked, I made a Signal call. I could hear the person on the other end, and they could hear me, so I concluded that everything was working as expected. Well it seems that I was wrong. The headphones were being used for audio output, but the laptop microphones were being used for audio input. And I have now seen posts like this:

@bungali

Microphone input via headphone jack is not yet implemented and is an upcoming feature that will be provided via firmware update.

Sorry for the error everyone. @Sven, could you correct my original post to replace this:

• 3.5mm Headphone Jack (Output and Input)

with this:

• 3.5mm Headphone Jack (Output and Input) ← Correction

Thank you.

Attachments

Qubes-HCL-Purism-Librem_14-20220316-033600.yml (846 Bytes)

[fsflover]

@dom0

@Sven, could you correct my original post to replace this

Thank you for your valuable contribution! I edited your post and also mentioned that the latest report is here.

[Sven]

Thank you @dom0, your new report is online now!

[peterle]

I am thinking about buying a Librem 14 specifically for Qubes. I would like to use the Librem14 mostly between two locations in a kind of “docking station” setup where I connect preferably only a minimum number of cables. I would like to be able to keep my desktop with the open windows running when connecting to the external monitor + periphery (no reboot of the entire system). Does this work? I saw that the Librem 14 has a USB-C port that supports Display port. Does this work for hot swap? Does Power Delivery work together with the other USB-C features? What about Ethernet network and HID via USB-C?

Can anybody recommend a docking station that works w/ Librem 14 + Qubes? Preferable, it would have DisplayPort w/ MST to support 2 monitors (not strict on this, just nice to have), Ethernet, USB for HID and Power Delivery.

Peter

[fsflover]

Looking for dual-monitor dock recommendation (display, USB)

Hello, I am running Qubes OS v4.1.0 on a Librem 14v1 laptop. I intend to typically use this at my desk with a dual-monitor, USB-A mouse, and USB-A keyboard setup. I would strongly prefer to use a dock so that I don’t need to constantly plug/unplug these 4 items into the laptop each time I want to work away from my desk, so I’m looking for a dock. For the display ports, I suppose HDMI or DisplayPort would do. I anticipate that such a port would connect to the laptop via USB-C, of which I have x2…

[kenosen]

Remarks

Function buttons do not work after suspend.
No suspend on lid close.
Pureboot issues after any Qube Update.

layout:
‘hcl’
type:
‘laptop’
hvm:
‘yes’
iommu:
‘yes’
slat:
‘yes’
tpm:
‘’
remap:
‘yes’
brand: |
Purism
model: |
Librem 14
bios: |
4.16-8-gf88975265a
cpu: |
Intel(R) Core™ i7-10710U CPU @ 1.10GHz
cpu-short: |
FIXME
chipset: |
Intel Corporation Device [8086:9b51]
chipset-short: |
FIXME
gpu: |
Intel Corporation Comet Lake UHD Graphics [8086:9bca] (rev 04) (prog-if 00 [VGA controller])

gpu-short: |
FIXME
network: |
Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
65410
scsi: |

usb: |
1
versions:

• works:
  ‘FIXME:yes|no|partial’
  qubes: |
  R4.1
  xen: |
  4.14.5
  kernel: |
  5.15.57-1
  remark: |
  FIXME
  credit: |
  FIXAUTHOR
  link: |
  FIXLINK

[Sven]

Thank you @kenosen for this report, which is online now.

@kenosen

Pureboot issues after any Qube Update.

Can you please be a bit more descriptive – what do you see? …what do you expect?

[kenosen]

Absolutely; after any update through Qubes Update, I would have to follow regenerate TOTP/HOTP secret in Librem Key, and reset TPM, sometimes this would not validate and eventually the Qubes image was not found and I’d be forced to reinstall. I’m virtually certain that this is user-error, but it became a major hurdle to logins and for now presented too much worry about whether my system would reboot properly after a full shutdown.

EDIT: I expect to use the Librem Key to verify the boot, but not have to reset the key, et.al., each time.

I was also able to manage the lid shut suspend by editing logind.conf in /etc/systemd/ by uncommenting HandleLidSwitch=suspend

And as noted by others in this thread, I’m still experiencing erratic xfce4-power-manager status notifications, but I am one update behind on the EC firmware. Will test with new EC firmware next week along with the librem-ec-acpi-dkms from Purism.

[kenosen]

@Sven just an update. I was able to switch back to PureBoot without too many issues, but with dom0 and kernel updates, it’s still preferable to keep Coreboot.

I also now believe the issues with function buttons are a product of ongoing kernel issues, not Librem specific. I also note that after updating the librem-ec-dkms the “killswitch” LED for wifi went dark. Here’s how to fix that:

sudo -i
modprobe ledtrig-netdev
echo netdev > /sys/class/leds/librem_ec\:airplane/trigger
echo wls6 > /sys/class/leds/librem_ec\:airplane/device_name
echo 1 > /sys/class/leds/librem_ec\:airplane/rx
echo 1 > /sys/class/leds/librem_ec\:airplane/tx
exit

[wqpw]

Here is my HCL report.
Qubes-HCL-Purism-librem_14-20221230-105916.yml (845 Bytes)

Unfortunately I have the following problems:

• The CPU frequency maximum is at 1.1GHz (related to this issue I guess CPU Frequency Scaling Broken · Issue #4604 · QubesOS/qubes-issues · GitHub).
• After suspend the following things don’t work (reliably)
  • Charging (the connected charger is not detected by Qubes but it charges extremely slow).
  • The wifi passwords in sys-net seem to get forgotten (after a reboot I have to enter them again).
  • The screen brightness keys stop working.
• Graphical glitches on disk unlock LUKS screen.
• If the camera and mic is turned of via the hardware switch the wifi PCI device is not discovered during boot. Switching it off when Qubes has been started works fine though.

Heads and Coreboot work fine.

[wqpw]

Regarding the 1.1GHz issue. Could whoever reads this and has a Librem 14 check if it affects also their device?

Run those commands in dom0

xenpm get-cpufreq-states
xenpm start 1 | grep "Avg freq"

and report back if anything bigger then 1.1GHz shows up.

[fsflover]

@wqpw

The wifi passwords in sys-net seem to get forgotten (after a reboot I have to enter them again).

This is expected, if you are using a disposable sys-net. See this: Convert sys-net to disposable - #8 by fsflover

@wqpw

Graphical glitches on disk unlock LUKS screen.

Laggy and pixelated disk decryption passphrase entry screen

[fsflover]

@wqpw

The screen brightness keys stop working.

Just tried suspending and, after getting back, the brightness keys are working. Try to switch on “Handle display brightness keys” in Xfce Power Manager, “General” tab.

@wqpw

Run those commands in dom0

xenpm get-cpufreq-states
xenpm start 1 | grep "Avg freq"

and report back if anything bigger then 1.1GHz shows up.

Yes, the first command shows max 1.1 GHz. No such problem with Librem 15 though (the latter shows up to 2.5 GHz).

But the second command showed up to 2.2 GHz for me under a load on L14.

[wqpw]

@fsflover

This is expected, if you are using a disposable sys-net .

My sys-net is not disposable.

@fsflover

But the second command showed up to 2.2 GHz for me under a load on L14.

Thanks for testing.

@fsflover

Just tried suspending and, after getting back, the brightness keys are working. Try to switch on “Handle display brightness keys” in Xfce Power Manager, “General” tab.

Didn’t helped for me unfortunately.