ES8336 (sof-essx8336): jack detect never asserts on Huawei MateBook D15 BOHB-WAX9-PCB-B2 Arch Linux, leaving speaker/headphone GPIOs latched

[miguelgonrod]

Summary

On a Huawei MateBook D15 (DMI board BOHB-WAX9-PCB-B2) in Arch Linux, the Headphone Jack
kcontrol never changes state — it reads off both with and without headphones
plugged in.

Because the speakers-enable and headphone-enable GPIOs appear to be driven
solely by the jack detect event, they stay latched in their boot state for the
entire session. The result is that the speaker amplifier is permanently
powered and cannot be muted from userspace by any means: Speaker Switch has
no audible effect, UCM device switching does not move the GPIOs, and the lines
are owned by the driver so gpioset cannot touch them either.

Hardware / software

Machine	Huawei MateBook D15
sys_vendor	HUAWEI
product_name	BOHB-WAX9
board_name	BOHB-WAX9-PCB-B2
Card longname	HUAWEI-BOHB_WAX9-M1120-BOHB_WAX9_PCB_B2
Kernel	7.1.9 (Arch)
sof-firmware	2025.12.2
alsa-ucm-conf	1.2.16.1
PipeWire	1.6.8
Topology	intel/sof-tplg/sof-cml-es8336-dmic2ch-ssp0.tplg

Quirk currently applied

With no module parameter override (quirk parameter reads -1), the DMI table
selects 0x1a0:

sof-essx8336 sof-essx8336: quirk mask 0x1a0
sof-essx8336 sof-essx8336: quirk SSP0
sof-essx8336 sof-essx8336: quirk DMIC enabled
sof-essx8336 sof-essx8336: quirk headphone GPIO enabled
sof-essx8336 sof-essx8336: quirk headset at mic1 port enabled

Observed behaviour

1. Jack control never asserts.

$ amixer -c 0 cget numid=27
numid=27,iface=CARD,name='Headphone Jack'
; type=BOOLEAN,access=r-------,values=1
: values=off

Identical output with headphones inserted and removed. Same for
Headset Mic Jack (numid=28).

Because HiFi.conf declares JackControl "Headphone Jack" for
SectionDevice."Headphones", PipeWire never creates a headphones sink — only
Speaker and the three HDMI sinks appear in wpctl status.

2. Headphones output itself works.

Enabling the device manually with PipeWire stopped produces sound in the
headphones:

$ systemctl --user stop pipewire.socket pipewire.service wireplumber.service
$ alsaucm -c hw:0 set _verb HiFi set _enadev Headphones
$ speaker-test -D plughw:0,0 -c2 -t wav -l1

…but the internal speakers keep playing at the same time.

3. Speaker cannot be muted.

$ amixer -c 0 set 'Speaker' off
$ amixer -c 0 get 'Speaker'
Simple mixer control 'Speaker',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]

Speaker output remains audible with the switch reported as off.

4. GPIO state.

$ sudo cat /sys/kernel/debug/gpio
gpiochip0: 312 GPIOs, parent: platform/INT34BB:00, INT34BB:00:
gpio-47 ( |speakers-enable ) out lo ACTIVE LOW
gpio-48 ( |headphone-enable ) out hi ACTIVE LOW
gpio-278 ( |ESSX GpioInt(0) ) in hi IRQ

Given ACTIVE LOW polarity, speakers-enable is asserted and
headphone-enable is deasserted, regardless of jack insertion. The lines are
owned by the driver (gpioset returns Device or resource busy), so this
cannot be worked around from userspace.

5. UCM device switching does not affect the GPIOs.

With PipeWire stopped and playback running via plughw:0,0:

$ alsaucm -c hw:0 set _verb HiFi set _disdev Speaker set _enadev Headphones
$ sudo cat /sys/kernel/debug/gpio | grep -E "speakers|headphone"
gpio-47 ( |speakers-enable ) out lo ACTIVE LOW
gpio-48 ( |headphone-enable ) out hi ACTIVE LOW

Unchanged. The GPIOs appear to be driven solely by the jack detect event, so
with jack detection non-functional they remain latched in their boot state and
the routing cannot be corrected from userspace by any means.

Things tried

• quirk=0x1e0 (i.e. 0x1a0 + SOF_ES8336_JD_INVERTED): headphones become
  audible — consistent with a different boot-time GPIO state rather than any
  actual switching — but speakers stay on and the jack control still never
  toggles.
• quirk=0xa0, quirk=0x180: no change in jack behaviour.
• Removing all /etc/modprobe.d overrides so the DMI default 0x1a0 applies:
  no change.
• Manipulating the lines directly with gpioset: refused, lines busy.

Question

Is BOHB-WAX9-PCB-B2 covered by an existing DMI entry, or is it matching a
generic fallback? The jack detect line appears either not wired to the codec on
this board revision or routed through a GPIO the driver is not reading. I'd be
happy to test patches or dump additional ACPI/codec state if useful.