Had to use a current kernel-latest iso downloaded from openqa for installation.
The installation dialog seems to have some type of refresh/artifact problem as a lot of the active windows are pixelated and “load” very slowly. It is possible to click through the installer with some effort.
Problems after installation:
- refresh/artifact problem can be fixed by applying:
- wifi is not working:
laptop uses a newer ax211 wifi card, i’ve spent 2 nights trying all kinds of different kernel / firmware versions but could never get it running. Supposedly the ax211 uses some “magic” that is embedded into the cpu and not in the wifi card anymore, that might cause problems with xen. I just put an ax210 card in it.
- sound only works through headphone jack, speakers don’t work:
i’ve tried booting different distros, currently only ubuntu 22.04lts has working sound, but it seems to not use the integrated amplifier and the sound quality is only ok and quiet in comparison to windows. I will open a bug to ubuntu in the next few weeks to see if the amp can be enabled somehow.
- suspend doesn’t work:
s3 suspend just reboots while going to sleep, deep suspend goes to sleep but reboots on resume
Qubes-HCL-HP-HP_EliteBook_860_16_inch_G9_Notebook_PC-20220709-214138.yml (742 Bytes)
Thank you @tze for your HCL report, which is online now!
Was finally able to get the speakers to work.
Just documenting this here in case somebody else uses Qubes on a G9 Elitebook.
The problem was caused by the Cirrus amplifiers not being initiated by the kernel.
On kernel-latest 5.19.6 there’s the following error:
[ 20.015240] Serial bus multi instantiate pseudo device driver CSC3551:00: error -ENODEV: failed to allocate SPI device CSC3551:00 from ACPI: -19
In order to get the amp to be initialized correctly, I built a 6.0rc5 kernel and added the following unofficial patch:
After that the amps are initialized correctly and bound by alsa:
Serial bus multi instantiate pseudo device driver CSC3551:00: Instantiated 2 SPI devices.
snd_hda_codec_realtek ehdaudio0D0: bound spi0-CSC3551:00-cs35l41-hda.0 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
snd_hda_codec_realtek ehdaudio0D0: bound spi0-CSC3551:00-cs35l41-hda.1 (ops cs35l41_hda_comp_ops [snd_hda_scodec_cs35l41])
Futzed around with this hardware for some time, then reinstalled and determined what the minimal changes were for (what I considered to be) basic functionality. For me, minimal changes were:
- Needed kernel-latest 6.0.8 in dom0 for external monitors to work.
- kernel-latest 6.1.12 is not good in dom0, as there’s a regression introduced in 6.1.7 that kills the Thunderbolt port at least (possibly all USB ports) under Xen. It was reverted in 6.2, but I don’t see a revert in the 6.1 branch yet. The Qubes community probably knew about this already, but the research process was instructive for me, I suppose.
- Display artifacts/lag: This was fixed by using 20-intel.conf as specified in Contents/intel-igfx-troubleshooting.md at master · Qubes-Community/Contents · GitHub. Just specifying the driver is enough; UXA, TearFree, etc. aren’t needed (though they probably don’t hurt).
- Wi-Fi: This is fixed by using kernel-latest 6.0.8+ in sys-net as well. The driver in the old kernel package has certain firmware versions it wants to see, and the linux-firmware package has moved on past those.
- Audio: Initially, I fixed this one by installing alsa-sof-firmware in dom0, which took a bit of doing since it wasn’t on the package whitelist (probably a good sign you shouldn’t do that). When you’re running audio through dom0, you’ll need to disable suspend-on-idle as well. Then I got a sys-audio Qube working, and with a sys-audio Qube, it doesn’t appear that you need to disable suspend-on-idle.
I suppose Qubes is not a unique Linux distribution in being somewhat cranky with new hardware. Fun fact: When doing the install, external monitors didn’t work out well either, and that looks like it falls under the umbrella of an anaconda bug that’s been open for almost 12 years now. … Good.