3.5 headphone jack microphone does not work. The same issue on all OS.
I will make a more thorough post about this and some may not be 4.1 specific but for Purism Librem 14:
-
constant charging/discharging alerts/notifications when computer into power (and yes i have followed all the instructions on forums for fixing this on 4.0 - the only workaround is to completely disable power notifications in dom0)
-
wifi radio is missing when resume from standby
-
3.5mm does not work
other
for some reason occasionally on startup sys-net and sys-firewall does not run and requires manual start ā¦this i noticed started with rc4.
Many people on Purism forums say that their Librem 14 with Qubes works flawlessly. I guess you should ask there and troubleshoot your problems.
Could you also upload the HCL report for Qubes 4.1?
For charging and discharging behavior make sure you have latest EC firmware installed on the laptop and librem-ec-acpi-dkms installed in dom0. Then you can even change start/stop charging thresholds.
For wifi after wake up you probably need add correct modules in sys-net /rw/config/suspend-module-blacklist
Iām not sure which exactly, but some of these (Others, what modules work best for you?):
ath9k
ath9k_common
ath9k_hw
ath
For audio jack make sure you have installed lastest corebot or pureboot firmware. Automatic switching when you plugin headphones does not work (hopefully in in future releases of firmware), so you have to manually change Output device
in audio mixer.
done this and the problem persists. this is for 4.1 it may work for 4.0.
On 4.1 it does not work is all i can say i have tested it thoroughly
i will check it out
Also I need to add to the list working an external monitor over the single USB-C PD port on Librem 14 does not work. Only HDMI.
Everything i wrote was about 4.1.
I ended up with only ath9k
in suspend-module-blacklist
.
Would you be able to submit the HCL report here? It should help us to update the list of recommended laptops.
Remarks
Working
- Wi-Fi
- Ethernet
- MicroSD-card reader
- Webcam
- Microphones
- Speakers
- Touchpad
- All USB ports
- Headphone jack (requires that you manually change it as output, no microphone input)
- Suspend (not tested thoroughly)
- Brightness and Volume keys
- HDMI port
Not tested
- Bluetooth
- Hibernation
Recommended tweaks
Installing librem-ec-acpi-dkms kernel module
EQ profile for speakers (PulseEffects)
Automatic script for Wi-Fi killswitch
Ensuring that the kernel module xen-acpi-processor is loaded
Enabling Trim
Attachments
Qubes-HCL-Purism-librem_14-20220308-192518.yml (847 Bytes)
So microphone input does not work for you either?
What about external display over USB-C (the right hand side usb-c port)
Microphone input via headphone jack is not yet implemented and is an upcoming feature that will be provided via firmware update.
DP over USB-C on the other hand is bit more tricky and the reason that I didnāt mention it at all is because it depends on the devices that you own (in this case most likely; a USB-C monitor, hub or dock).
What I can tell is that if your current monitor/dock/hub works with Librem 14 in Linux distros such as Ubuntu or Fedora it will also work with Qubes OS.
My Dell monitor DP over USB-C works on the right side USB-C port as intended, delivering power (USB PD) and getting an image but I have had issues with USB-C docks. This is most likely caused by the Librem 14ās USB chip that handles protocols like DP over USB-C as other laptops I have had did not have issues.
@bungali,
Which version of Qubes did you install in the Librem 14?
Which version of the EC firmware are you using? (use sudo purism_ectool info
to get the EC version and see this post to upgrade)
Qubes OS 4.1. Iām using the latest stable EC firmware (Librem-EC v1.5 (2021-10-28_5fdd1e51)).
Try to follow these instructions but I stuck at
sudo dkms build librem_ec_acpi/1.0
it returns
Error! echo
Your kernel headers for kernel 5.10.90-1.fc.32.qubes.x86_64 cannot be found at
/lib/modules/5.10.90-1.fc32.qubes.x86_64/build or /lib/modules/5.10.90-1.fc32.qubes.x86_64/source.
You can use the --kernelsourcedir option to tell DKMS where it's located.
Did you @bungali face the same issue?
How would the --kernelsourcedir
command look like?
I did not face this issue, but I would recommend updating dom0 as newest stable kernel is 5.10.96. Rebooting might also help.
Ok, thanks I will try to upgrade the dom0 kernel.
My Wifi doesnāt work in any condition (switched on before bootā¦) I guess it requires this dkms tweak first. Can you confirm?
WiFi should work without any tweaks as long as you add the WiFi card to sys-net devices.
- updated kernel to latest version 5.10.96-1.fc32 (had to do a āEnable updates for qubes without known available updatesā ?!, anyways)
followed your the recommended tweaks
-
dkms installation done and verified
-
automatic script for wi-fi killswitch: Here, when I check the s
ystemctl status killswitch.service
it returns:
killswitch.service - Killswitch fix for L14
Loaded: bad-setting (Reason: Unit killswitch.service has a bad unit file setting.)
Active: inactive (dead)
... ... dom0 systemd[1]: killswitch.service: killswitch.service: Cannot add dependency job, ignoring: Unit killswitch.service has a bad unit file setting.
... ... dom0 systemd[1]: /etc/systemd/system/killswitch.service:7: Unbalanced quoting, ignoring: "usr/bin/sh -c '\"
... ... dom0 systemd[1]: killswitch.service: Unit configuration has fatal error, unit will not be started.
I have already reboot my notebook two times with wi-fi on.
I made following observation:
My wi-fi light is currently off even if it is switched to the right position. It is on during boot but when QOS is booted it is off.
My sys-usb is displaying a usb-device(!) when the wi-fi killswitch is switch on:
sys-usb:2-3 - 13d3_3487
When I switch off the wi-fi killswitch this usb device disappears (pop up notification: device removed). So, it is somehow seen as USB device not as wi-fi.
When I do a qvm-pci
it shows me the
dom0:01_00.0 Network controller: Qualcom Atheros AR9462 Wireless Network Adapter
Any suggestion to fix my wi-fi issue?
status update:
I did a manual pass-through How to use PCI devices | Qubes OS and a reboot. 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
⦠keep you posted.
Librem 14 actually removes power completely from the Wi-Fi card when killswitch is in off position and this is why Wi-Fi killswitch needs to be on when Qubes OS is booting as boot phase is when PCIe devices are detected by Qubes OS. If you switch the killswitch to off position after boot you need to reboot to enable Wi-Fi again.
Wi-Fi LED is on when there is traffic not when its āonā and receiving power.
The automatic killswitch script only detects if the Wi-Fi card is present during boot and attaches it to sys-net if it is. If Wi-Fi card is not present, script detaches it from sys-net, this occurs only when Wi-Fi card is already assigned to sys-net.
You may want to add more lines like Before=qubes-vm@sys-net.service
for other VMās that may start during boot and require sys-net (such as sys-firewall).
You may have type error in the script, output should look like:
ā killswitch.service - Killswitch fix for L14
Loaded: loaded (/etc/systemd/system/killswitch.service; enabled; vendor preset: disabled)
Active: inactive (dead) since Sat 2022-03-12 12:26:55 EET; 24min ago
Process: 2509 ExecStart=/usr/bin/sh -c if qvm-pci | grep -q dom0:01_00.0 ; then qvm-pci attach sys-net dom0:01_00.0 --persistent || true ; else qvm-pci detach sys-net dom0:01_00.0 || true ; fi (code=exited, status=0/SUCCESS)
Main PID: 2509 (code=exited, status=0/SUCCESS)
CPU: 223ms
Mar 12 12:26:46 dom0 systemd[1]: Starting Killswitch fix for L14...
Mar 12 12:26:55 dom0 sh[4870]: 'device 01_00.0 of class pci not attached to sys-net'
Mar 12 12:26:55 dom0 systemd[1]: killswitch.service: Succeeded.
Mar 12 12:26:55 dom0 systemd[1]: Finished Killswitch fix for L14.