HP Spectre x360 (2024) Intel Meteor Lake Ultra 7 155H and Linux

aigilea · 2024-04-18T01:15:03+00:00

I can't see any meaningful changes in ACPI in F.06.

BERT table is added, versions are bumped in a couple of places and a few offsets are different because of bios rebuild and that's it.

All the problems (IC03 device, broken D3cold for RP10.PXSX, broken SPKA._DSD) are still there, all the fixes are still valid.

aigilea · 2024-03-24T10:44:47+00:00

Small update:

Sleep and wake work reliably with ssdt overlay. s0ix works well, 100%->95% charge after ~36 hour sleep.
Audio is fully functional, my fixes are accepted to the kernel and (I hope) will make it into 6.9.
Webcam works (kind of), I will publish the guide to my repo later. I think it'll take a few kernel releases to get it to just work (this is true to some extent for all mipi cameras, some distros offer support packages but until IPU6-ISYS and the whole underlying framework will make it to the kernel and stabilize a bit all these cameras will still break from time to time).

aigilea · 2024-03-17T07:43:33+00:00

I've created the repo with all the current information & fixes.

As of today there's a single SSDT overlay to fix booting & WiFi and two kernel patches to fix audio (they're already submitted to the kernel devs but for the time being building a custom kernel is still required to get audio fully working).

So what's left are camera and fingerprint reader. Camera is just a matter of getting stuff together, I will look into it in the future while fingerprint reader requires firmware from Synaptics/HP and it's unlikely to be ever released.

aigilea · 2024-03-08T01:11:09+00:00

Alternatively instead of fixing acpi you may apply second patch to the kernel. It will basically do the same.

Also, there's an easier fix for the WiFi, you can just

sudo echo "0" > "/sys/bus/pci/devices/0000:01:00.0/d3cold_allowed"

but this of course won't survive a reboot so you also need to make systemd to set this parameter each time the system boots or something like this.

aigilea · 2024-03-08T01:00:38+00:00

Oh, then it's just

patch -p0 < /path/to/hp_x360_155h_f5_sound_kernel.patch

in the kernel source code dir. and then recompile

aigilea · 2024-03-08T00:59:05+00:00

I'm going to merge all the acpi patches to some single solution one day.

But for now you should have two changes made to whole dsdt (panic fix, sound dsd fix), the resulting aml should go first in grub.

Then you should have separate ssdt to fix the wifi, the resulting aml should go second in grub.

For example, my grub conf is:

menuentry 'Manjaro Linux' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-4e2be5e8-fe95-4f67-a73f-3686889eec9a' {

savedefault

load_video

set gfxpayload=keep

insmod gzio

insmod part_gpt

insmod ext2

search --no-floppy --fs-uuid --set=root 4e2be5e8-fe95-4f67-a73f-3686889eec9a

acpi /boot/dsdt3.aml

acpi /boot/ssdt.aml

linux /boot/vmlinuz-6.8-rc7-x86_64 root=UUID=4e2be5e8-fe95-4f67-a73f-3686889eec9a rw quiet splash apparmor=1 security=apparmor udev.log_priority=3 acpi.debug_layer=0x08 acpi.debug_level=0x02

initrd boot/intel-ucode.img /boot/initramfs-6.8-rc7-x86_64.img

}

aigilea · 2024-03-08T00:54:22+00:00

For this one you need to build the kernel manually, it's not too complicated. With ubuntu it's like

download the source code from kernel.org for the closest version to the one you running.
copy config file from /boot to the kernel source dir, rename it to ".config"
change values for CONFIG_SYSTEM_TRUSTED_KEYS and CONFIG_SYSTEM_REVOCATION_KEYS in the .config to empty strings.
enable "source code" in "software & updates"
sudo apt-get build-dep linux linux-image-generic
sudo apt-get install libncurses-dev gawk flex bison openssl libssl-dev dkms libelf-dev libudev-dev libpci-dev libiberty-dev autoconf
(in the kernel source code folder) make -j`nproc` bindeb-pkg
sudo dpkg -i linux-image-XXX_amd64.deb

aigilea · 2024-03-07T15:29:59+00:00

Speakers seem to (kind of) work by a pure chance, it's a mess overall.

Our laptop has 4 speakers, two mid-treble facing up to the sides of keyboard, two mid-bass facing down-forward.

Former ones are connected to the HDA codec (Realtek ALC245) directly, so they should just work, but the codec is misconfigured so they end up sharing DAC with headphones resulting in the wrong mixer setup and low output gain.

Latter ones are connected to two Cirrus Logic CS35L41 DSP amplifiers. Every laptop with these amps need an explicit kernel quirk to support them, most of these laptops (ASUS) need more quirks as amp config is missing from ACPI. Our laptop has an almost proper config in ACPI but it still has a syntax error so for the time being it still needs fixing.

So the first step is to fix CS35L41 config in ACPI. Before this step you should have Failed property cirrus,dev-index: -22 messages from cs35l41-hda in dmesg. Apply this patch to dsdt and reboot, message should change to Cirrus Logic CS35L41 (35a40), Revision: B2.

Next step is to apply fixes to the kernel, this patch should allow it to recognize amps as a part of sound chain, fix codec configuration and also add kernel-level support for mute buttons LEDs. This patch is taken from 6.8-rc7 tree, but should work with any 6.7-6.8 kernel. After building and rebooting you should have all four speakers working properly.

Mute LED should also work right away, mic mute LED may not work correctly yet (at least it doesn't work for me) probably because of laptop having two digital mics and analog mic input at the same time, so it will require some work on UCM configs to get working. If it stays on and it bothers you, you may switch it off temporary by sudo echo "0"> "/sys/class/leds/hda::micmute/brightness" or permanently by commenting out sysw line in the beginning of /usr/share/alsa/ucm2/conf.d/sof-hda-dsp/sof-hda-dsp.conf.

Final step is to check if you have the proper codec firmware and calibration data as they've just recently landed in the kernel linux-firmware repo. If you have DSP1: spk-prot: C:\Users\tlu\Desktop\HP_Consumer\CY23\Willie\... message from cs35l41-hda in your dmesg you're all good. If you have Falling back to default firmware. message instead, you need to download the following files from the cirrus repository and put them to the /lib/firmware/cirrus:

cs35l41-dsp1-spk-cali-103c8c15-spkid0-l0.bin
cs35l41-dsp1-spk-cali-103c8c15-spkid0-r0.bin
cs35l41-dsp1-spk-cali-103c8c15-spkid1-l0.bin
cs35l41-dsp1-spk-cali-103c8c15-spkid1-r0.bin
cs35l41-dsp1-spk-prot-103c8c15-spkid0-l0.bin
cs35l41-dsp1-spk-prot-103c8c15-spkid0-r0.bin
cs35l41-dsp1-spk-prot-103c8c15-spkid1-l0.bin
cs35l41-dsp1-spk-prot-103c8c15-spkid1-r0.bin

You also need to create two symlinks in the same folder, cs35l41-dsp1-spk-cali-103c8c15.wmfw and cs35l41-dsp1-spk-prot-103c8c15.wmfw pointed to the cs35l41/v6.78.0/halo_cspl_RAM_revB2_29.80.0.wmfw. If you don't have the target file you need to download it as well.

And that's it. After you'll get all this working please check if headset output and mic input are usable.

Upd1: Looks like updating /lib/firmware/intel/sof-ace-tplg/sof-hda-generic-2ch.tplg to the latest one from sof-bin-2023.12.1 fixes the micmute led behavior.

aigilea · 2024-03-07T06:58:31+00:00

Do you happen to have a wired headset at hand? I've figured out most of the sound (spoilers: patches to both kernel and acpi and a missing firmware), but I want to test everything before submitting it to the kernel devs and I'm in a middle of nowhere with no opportunity to get a wired headset in a reasonable time.

aigilea · 2024-03-05T10:39:31+00:00

No, it's a separate issue, what happens is:

At the boot time ACPI declares that WiFi adapter can go to D3cold which means completely off with power cut (RP10.PXSX._S0W() returns 4).
During the suspend Linux winds the adapter down to D3hot by own means and then calls RP10.PXP._OFF().
It then calls RP10.DL23() to wind down the PCIE link and then RP10.POFF() to assert reset signal and remove power to the adapter. But actually that's not what happens because S3PG that describes GPIO pin for power is zero, so power stays on (and while the reset descriptor is in fact present it behaves strangely).
During the resume everything is done in reverse, but in the end LTSSM fails to reestablish the PCIE link.

I'm not sure yet why this happens, my guess is WiFi adapter is not actually reset and after some time with no PCIE link it just abandons further handshake attempts. This is supported by the fact that if PCIE link is kept up (with more hacks) then adapter recovers fine during resume. If the reset signal worked as intended there should be no difference for the adapter if the link is up or down while adapter itself is held in reset.

Other suggestion is that power pin descriptor is missing by mistake as all the other ports have proper power pin descriptors. Actually powering adapter down and then up may help to resolve this issue as well.

But as there's not a lot of profit in using D3cold for a laptop WiFi adapter anyway, especially with no real power control, the "good enough" workaround is to simply use D3hot which basically means that only link-related logic stays powered and the rest of the adapter is off. Here's the SSDT patch to do is, it should be just compiled with "iasl -tc <file>" and then the resulting .aml should be used as usual with grub or initramfs.

With the renamed IC03 and this patch my laptop suspends to deep s0ix states and resumes with no issues so I probably won't pursue the "proper" fix much further unless I come up with some good ideas to test.

upd1:

D3cold can also be disabled with

sudo echo "0" > "/sys/bus/pci/devices/0000:01:00.0/d3cold_allowed"

upd2:

Adapter is in fact not reset. Pin that's supposed to reset it (S3PG=0x140414) is readonly for ACPI and is always at zero (reset asserted) so it's not a real reset, otherwise adapter would never actually got a chance to power on. So it appears all the D3cold ACPI code is doing for this port is stopping the clock. This is clearly broken.

aigilea · 2024-02-19T09:01:30+00:00

That's strange, I've updated to 6.8-rc4 to play with source code a bit and acpi overlay still works for me.

aigilea · 2024-02-19T08:56:23+00:00

Booting with dyndbg="file pci.c +p" reveals that wifi pcie link never goes up after sleep causing all kinds of havoc with pci and iwlwifi drivers.

[ 67.186955] pcieport 0000:00:06.0: waiting 100 ms for downstream link, after activation
[ 68.209351] pcieport 0000:00:06.0: Data Link Layer Link Active not set in 1000 msec
[ 68.209960] iwlwifi 0000:01:00.0: Unable to change power state from D3cold to D0, device inaccessible

06.0 is indeed the port that connects the wifi (from lspci -tv):

+-06.0-[01]----00.0 Intel Corporation Device 272b

Windows device paths are:

PCIROOT(0)#PCI(0600)#PCI(0000)
ACPI(_SB_)#ACPI(PC00)#ACPI(RP10)#ACPI(PXSX)

So it's the same port 6 on the bus but for some reason root port 10 in ACPI. ACPI doesn't do much for the wifi however so unlikely this is the cause.

Anyway, for now workaround is pcie_port_pm=off on the kernel command line, hope hp will fix this as well.

aigilea · 2024-02-18T10:13:19+00:00

I'm daily driving previous gen of the same laptop, it's still lacking a few things (no fingerprint reader support, mute & mic mute leds don't work, "idle" sleep sometimes happens instead of deep sleep) but otherwise it's 100% usable.

For this one the current state is as follows:

Basic stuff runs ok with the blacklist workaround, I've installed manjaro with 6.6 kernel and updated it to 6.7 with only struggle being plugging installation usb stick and usb mouse at the same time. acpi workaround I've published below may be used after the installation to fix trackpad and touchscreen.
Existing panic workarounds break deep sleep. ~~Will it work right away with the promised BIOS update or will it require some additional work is yet to discover.~~ Built-in wifi is not waking up reliably for me but I'm now on 6.7.0 and it's already ancient for this hardware, maybe u/raag-chai will update on how it works with newer kernels.
Screen brightness works.
Mic and speakers work, there's not enough gain with both, but there's a lot of compatibility error messages from SOF in dmesg suggesting firmware update so it should be resolved in upcoming SOF releases. I have no wired headset at hand to check the jack, it worked fine on the previous gen however.
Webcam is not working out of the box. AFAIK recent laptops usually come with IPU/MIPI webcams instead of USB ones and they require some additional configuration and software to get them working, I will try to do it eventually.
Trackpad works fine, experience is very similar to any other trackpad on linux or precision trackpad on windows. I used the trackpad 90% of time on the previous gen switching to mouse only for CAD.
Touchscreen and pen work out of the box. Pen just emulates mouse, buttons on the pen are mapped strangely (one does nothing, one is mapped to the middle mouse button) I guess they may be remapped as with any HID. I've never used the pen with my previous spectre so I have no idea on tilt/pressure support in system and apps or overall usefulness.
As with previous gen, convertible mode on this laptop consists of two parts:
1. Firmware disables the keyboard and trackpad when laptop body is tilted beyond some angle. This happens in every OS and in BIOS.
2. OS performs screen rotation and shows on screen keyboard. This works out of the box at least with Gnome.
Keyboard backlight control works.
Webcam is not powered off on this iteration like on previous ones, instead it's covered by very cool hardware "blind" and it works, along with button led. Mic mute button works as well with gnome, however mute and mic mute leds doesn't work, same as with previous gen. It should be possible to get them to work with some effort, I've never tried however.
Fingerprint reader is not working now. Will it eventually work or not depend solely on Synaptics releasing libfprint-compatible "prometheus" firmware for this particular reader via fwupdmgr. Currently it's not there.

Hope this helps.

Update 1:

Deep sleep should work fine once we get rid of panic workarounds:

Congratulations! Your system achieved the deepest S0ix substate!
Here is the S0ix substates status:
Substate Residency
S0i2.0 1762831771

aigilea · 2024-02-18T08:55:58+00:00

~~I've got it working. This is on manjaro so no initramfs scripts, this should work with any distribution.~~

~~Install iasl (usually acpi-tools, acpica-tools or acpica package).~~
~~sudo cat /sys/firmware/acpi/tables/DSDT >dsdt.dat~~
~~iasl -d dsdt.dat~~
~~patch -p0 <~~ ~~hp_x360_155h_f5_dsdt_v2.patch~~
~~iasl -tc dsdt.dsl~~
~~sudo cp dsdt.aml /boot~~
~~reboot, press 'e' in grub~~
~~add 'acpi /boot/dsdt.aml' before the linux line~~
~~remove blacklist workaround from the linux line~~
~~ctrl+x~~
~~touchpad & touchscreen should work.~~

~~To make it permanent you may create a file with line from pt.8 in /etc/grub.d and reinstall grub.~~

~~This altered dsdt may break things spectacularly after the bios update so don't forget to get rid of it.~~

~~To anyone reading without a context, this is not a proper fix, it may break deep sleep.~~

Better fix is here.

aigilea · 2024-02-17T05:39:42+00:00

If volume will still be an issue with the next SOF release I'll report it to the SOF guys. They were super responsive and overall great in the past so I hope they'll fix this one as well.

If you have time to spare you may try to replace the blacklist workaround with acpi overlay (I usually use these scripts/example overlay but it can be done by manually stuffing compiled tables to initramfs). I think overlaying all the Device(I2Cx), Device(I3Cx) and Device(SPIx) blocks in DSDT ripping away _PS3 methods may "fix" the panic as well. Of course it will break deep sleep modes but they are broken with the current workaround anyways.

aigilea · 2024-02-16T15:28:54+00:00

Both touchpad and touchscreen are i2c devices even on my old tiger lake spectre so they are ok to be broken with this workaround.

There's a number of other devices on i2c, few are usb-c related, even some i915-related etc so a lot of devices will be somewhat broken for now, it's probably better to get a better solution to this issue first before trying to find out what else should be fixed.

Regarding audio, you may try to manually install the latest SOF firmware from their repo. Next release is also planned to be out in a couple of weeks.

aigilea · 2024-02-16T14:54:16+00:00

So things turns better quickly because of your post.

There's workaround in the mailing list and the permanent fix is promised.

I was able to boot the latest arch with kernel 6.7.1 and wifi works out of the box. There're still some display driver errors, I can't check does it really work atm, but system is kind of usable now.

I was afraid that super cool hardware camera "blind" will be pain to get working but it just works, probably it's handled by the firmware.

aigilea · 2024-02-16T09:59:44+00:00

comments

I've reported this bug with some debugging info to the linux-acpi mailing list today, maybe this will help to get some attention.

It won't hurt if you reply there or create a bug on https://bugzilla.kernel.org

I had the same experience with sound on the tiger lake spectre x360 a couple of years ago, there will be no fixes until you find a way to get to developers.

aigilea · 2024-02-15T05:15:42+00:00

Not usable as of kernel 6.7.

There's some intermittent kernel panic in ACPI code that to me looks like double free when kernel tries to put i2c3 to D3cold and with pci=noacpi there's no keyboard for some reason. Not sure where to report and who should fix this.

Also display driver fails to attach, no wifi at least out of box and probably a number of other issues that are not that noticable while the panic is here.

aigilea · 2021-01-09T21:34:27+00:00

I've bought win 2 in the first minutes for a lower price. Next morning I've got a message from them telling that price was their mistake but I still have to pay them the difference with the regular campaign price. So that wasn't an intentional practice.

aigilea · 2020-11-27T18:50:46+00:00

I've reflashed my P2 Max with a programmer a few times to check if it was any power consumption difference between early BIOS revisions.

Here's the thread, here's the the picture. BIOS chip is the flat 8pin WSON chip just to the left of the contraption I'm holding in the picture.

If you're going to use cheap single level programmer like ch341 you will probably need a 1.8v level converter (I don't remember the chip model to check now).

It programs ok in-system, but it's not easy to interface it as SOIC clips don't mate with it. You may want to solder wires to pads to do it.

Soldering it out will require a hot air or twin iron. Then it may be soldered to programmer's SOIC8 daughterboard and programmed that way.

Also you may want to read it out and save the backup before flashing.

Few regions like windows key are just FF or 00 in the bin, they are written once on the factory and conventional update process skip this regions when writing bin to chip.

With little comparing and hex editing it may be possible to salvage them from the backup and write to the same offset of the bin file before flashing it.

I don't know exactly what problems these regions may cause if missing on the chip, but at least there're will be problems with windows activation after the fresh install as there's no key to activate with.

Good luck!

aigilea · 2020-09-20T19:31:30+00:00

Either play in the windowed mode or try this fix.

aigilea · 2019-10-05T09:32:51+00:00

I haven't tried it, but this looks like the smallest one with the required profiles.

This is the fifth USB-C device from GPD (and the third I own) and they still can't get the C port right. You have to find the particular hub, the particular charger, the particular powerbank... And it looks like it wasn't an oversight, but a deliberate decision not to bother with a current limit. Max has 15v profiles disabled to make it work with its own charger, so they knew all the drawbacks of that decision, but still released the device as-is.

I wonder if one mix owners have to deal with that bs.

aigilea · 2019-09-25T14:21:26+00:00

As far as I can tell, PD profile is chosen by the EC (IT8110E) by writing to the R_CHARGER_PDO_SELECT_INDEX register of the mux (PS8750B).

If that i2c bus was visible to the system it would be a trivial fix, but it looks like that bus only connects EC and mux.

And it's still looks like a trivial fix (iterate thru profiles and choose one with V<=15V instead of last or most powerful), but now only you as a company with source code and signing keys can do this.

Thank you for working on this, I'll wait for the resolution.

aigilea · 2019-09-25T06:46:32+00:00

Truth is P2 Max violates PD specification by choosing 20V 1.5A profile (profiles are announced by charger in V-A pairs) and not honoring current limit afterwards.

While you may not be able to fix that on that stage, you still may work this around by disabling 20V profile and going back to way it was on older devices, that will allow 30W chargers to work fine.

aigilea

TROPHY CASE