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:
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
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.
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.
@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:
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.
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.
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.
Here is an updated HCL report with PureBoot 24 and the latest EC firmware (upload doesn't work. So here the file content):
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.
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.