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.
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.
My sys-net is not disposable.
Thanks for testing.
Didn’t helped for me unfortunately.
I have tested on my Librem 14 and confirm 1.1GHz issue exists.
The 1.1GHz issue seems to be fixed. Doing stress testing with qvm-start --all I get up to 2.8GHz also my compile times are much shorter. Anyone has a better idea how to stress test the full 4.7GHz?
This is only a problem for me if the charger is connected after the laptop is resumed from suspend. Connecting the charger while it is still sleeping works fine.
This occurs only after an EC and Coreboot update for me now. Several restarts fix the problem.
---
layout:
'hcl'
type:
'laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
''
remap:
'yes'
brand: |
Purism
model: |
librem_14
bios: |
PureBoot-Release-24
cpu: |
Intel(R) Core(TM) 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: |
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
memory: |
32642
scsi: |
usb: |
1
versions:
- works:
'FIXME:yes|no|partial'
qubes: |
R4.1
xen: |
4.14.5
kernel: |
5.15.94-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
---
Qubes OS 4.1.2, as expected, runs perfectly on the Librem 14, and there is one notable update.
Microphone input via the headphone jack has been implemented by Purism developer Jonathon Hall with the releases of Librem-EC 1.13 and coreboot 4.19-Purism-1/PureBoot 25, as described here:
@fsflover, I think that my other HCL Reports here and here should be edited to reflect this update and link to this post.
Even though Qubes OS 4.0 is EOL, a Librem 14 on Qubes OS 4.0 with the latest Librem-EC and coreboot would have working microphone input via the headphone jack.
Obviously, I recommend updating to Qubes OS 4.1.2, as there are no drawbacks, and it has new features and security updates.
Qubes-HCL-Purism-Librem_14-20230330-172504.yml (846 Bytes)
Thank you @dom0 for your updated HCL report, which is online now! The remark makes clear that coreboot 4.19 is required to make the microphone work. Since your other two reports are for the identical machine with different BIOS versions, I think this makes the point rather clear.
I agree, the remark in the HCL is quite clear.
Thank you @Sven for continuing to maintain the HCL, as well as your posts here in the forum.
---
layout:
'hcl'
type:
'laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
''
remap:
'yes'
brand: |
Purism
model: |
librem_14
bios: |
PureBoot-Release-27.1
cpu: |
Intel(R) Core(TM) 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: |
6.1.35-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
---Qubes-HCL-Purism-librem_14-20230730-013440.yml (846 Bytes)
No issues found. I will do another report when Qubes OS 4.2.0 is released.
As promised, here is an updated HCL report of my same Librem 14 v1 laptop.
---
layout:
'hcl'
type:
'Laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
'2.0'
remap:
'yes'
brand: |
Purism
model: |
librem_14
bios: |
PureBoot-Release-28.3
cpu: |
Intel(R) Core(TM) 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 [168c:0034] (rev 01)
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
memory: |
65410
scsi: |
usb: |
1
certified:
'no'
versions:
- works:
'FIXME:yes|no|partial'
qubes: |
R4.2.0
xen: |
4.17.2
kernel: |
6.1.62-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
Qubes-HCL-Purism-librem_14-20231220-024442.yml (917 Bytes)
As far as I know, I am pretty sure the TPM is not supposed to be a value of 2.0. My experience with the Librem 14 v1 so far using Qubes OS is still seamless, even on R4.2.0.
I’ve never run an HCL report, but in my Qubes Global Config it says that my TPM is “2.0 (not yet supported)”, so maybe the HCL report is just missing that caveat?
You can use the following instructions to generate a HCL report:
Also, I have confirmed that the TPM used in the Librem 14 is originally 1.2, but can be upgraded to 2.0.
Some Librem 14s did come with TPM 2.0 by accident, as mentioned at the end of the thread.
Strangely, though, my dmesg reports that my TPM is 1.2 and I got my laptop shipped with PureBoot so it shouldn’t have slipped through the cracks. But my HCL report also shows 2.0. My /etc/issue says that I’m still on rc5, although based on this post it sounds like that might just be a bookkeeping error.
This is my full HCL report, not sure if it’s useful to have multiple reports from the same model but it can’t hurt:
---
layout:
'hcl'
type:
'Laptop'
hvm:
'yes'
iommu:
'yes'
slat:
'yes'
tpm:
'2.0'
remap:
'yes'
brand: |
Purism
model: |
librem_14
bios: |
PureBoot-Release-28.3
cpu: |
Intel(R) Core(TM) 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: |
Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
memory: |
32642
scsi: |
usb: |
1
certified:
'no'
versions:
- works:
'FIXME:yes|no|partial'
qubes: |
R4.2.0-rc5
xen: |
4.17.2
kernel: |
6.1.62-1
remark: |
FIXME
credit: |
FIXAUTHOR
link: |
FIXLINK
Qubes-HCL-Purism-librem_14-20231221-093206.yml (849 Bytes)
Multiple HCL reports is fine as it is useful feedback for the Qubes OS team. No feedback would make it very difficult for anyone, including them, to determine how much Qubes OS is still compatible with the hardware.
Thank you for your HCL report.
It’s not just fine: It’s necessary to include the hardware into Community recommended computers.
So in the end what TPM do you have?
I do see same message on global config that 2.0 is not yet supported, but dmesg gives me 1.2 output.
So not sure now. I do have 1.2 or 2.0?
Based on the link that @FranklyFlawless shared, my interpretation of the output is that the global config understands that the chip could theoretically be flashed to support 2.0, but is currently running 1.2. I don’t know enough about the TPM specifications to say if there are actually hardware components that are needed, which would mean that it is useful to know if the chip supports it in theory and be a good explanation for the output.
But that’s just my interpretation, and this is far outside the technologies I normally work with. Others might know more.
Looked through some more of the thread, I’ve had some issues that I assumed were hardware problems but maybe not.
Regarding CPU frequency, I’m seeing > 3.0GHz on all my CPUs while compiling a large codebase (Guix), as reported by xenpm start 1 | Grep "Avg freq". I’m not exactly in the best thermal setup (my latpop is literally sitting on a carpet right now, I treat my computer so well) so I wouldn’t expect it to go to the maximum frequency.
I’ve had issues with my laptop turning off when I unplug it from the charger. I did not think this was due to QubesOS because it wasn’t a problem when I initially got the laptop, so I attributed it to a problem with the battery itself. I ordered it with QubesOS pre-installed. I’ll try booting from some ISOs and see if the problem also occurs with them (tonight, once I’m done doing stuff for the day).
I’ve also had a problem with USB devices becoming disconnected when they are jostled slightly, but the sensitivity varies by USB device so I again attributed this to hardware problems. But if the battery is actually a software issue this might be too.
Sorry if this has any impact on your commit @flavio