asus-expertbook-linux

The pad's HID report descriptor gives Tip Pressure no Logical Maximum of its own, so it inherits the Y field's 2601 and the kernel reports that as the ABS_MT_PRESSURE maximum. Real presses sit far below it, so libinput's pressure thresholds never see a proper touch and every motion is rejected as a "kernel bug: Touch jump." The sister pad 093A:4811 was fixed upstream in libinput 1.32 with AttrInputProp=+INPUT_PROP_PRESSUREPAD; 4F05 has no upstream entry yet.

$ journalctl -b | grep -c "Touch jump"   # libinput logs through the compositor
1873                                    ← without the module
0                                       ← with the module

After install, libinput quirks list /dev/input/event9 confirms the quirk is loaded.

1. B9406CAA firmware describes an unfitted RT722. Kernels that retain its UNATTACHED endpoint create a duplicate SDW3-Playback-SimpleJack, abort sof_sdw with -EEXIST/-12, and expose no ALSA card at all.
2. The Cirrus CS35L56 speaker amps need per-OEM tuning firmware. As of linux-firmware-cirrus >= 20260519 it ships upstream for 1043:15e4; on anything older the amps boot FIRMWARE_MISSING and the bundled blobs fill in. This unit has no CirrusSmartAmpCalibrationData EFI variable, so the kernel skips per-unit calibration silently and no "Calibration applied" line appears; the tuning still loads.
3. The card reports a combined speaker-codec string — spk:cs35l56+cs42l43-spk (or two spk: tags on older kernels). Stock alsa-ucm-conf 1.2.15.x has no UCM dir for it and its SpeakerCodec regex drops the trailing -spk, so alsaucm fails (codecs/cs35l56+cs42l43/init.conf: -2). WirePlumber then uses stereo-fallback, which plays to the Jack PCM (device 0), not the Speaker PCM (device 2) — silent speakers, even though aplay -D plughw:0,2 works.
4. On kernels before 7.1 the generic SOF topology declares an unused SSP2-BT hardware-offload PCM with no firmware blob; WirePlumber's probe of it spams the kernel log (~40% of all kernel errors at boot). The 7.1+ function topologies no longer expose it.
5. SOF firmware and topologies are the separate sof-firmware package. A minimal install can lack it, and then no card appears even with the ghost-RT722 fix (SOF firmware and/or topology file not found).

$ sudo dmesg | grep cs35l56
cs35l56 sdw:0:2:01fa:3556:01:0: FIRMWARE_MISSING                         ← without
cs35l56 sdw:0:2:01fa:3556:01:1: FIRMWARE_MISSING                         ← without
──────────────────────────────────────────────────────────────────────────────
cs35l56 sdw:0:2:01fa:3556:01:0: DSP1: Firmware: 1a00d6 vendor: 0x2 v3.13.4, 41 algorithms  ← with
cs35l56 sdw:0:2:01fa:3556:01:0: Tuning PID: 0x23134, SID: 0x470200, TID: 0x84b06           ← with

The proper fix is the upstream HiFi UCM, not a profile hack — named ports, headphone-jack auto-switching, working volume + mic-mute LED. It's upstream as of alsa-ucm-conf 1.2.16, and the speaker firmware is upstream as of linux-firmware-cirrus 20260519. On current packages this module therefore installs only the SSP2-BT drop-in and, where needed, the DKMS overlay; the UCM and firmware rows below are dropped in only as a fallback on older packages (the NoExtract pin is removed automatically once alsa-ucm-conf crosses 1.2.16). Install also pulls in sof-firmware when it is missing.

3.2 stopped installing the bundled firmware next to a current linux-firmware-cirrus. The copies were byte-identical to the package's, but as uncompressed files they shadowed it, and their per-amp -l2uN.wmfw names, which upstream never uses, are looked up before the package's generic 104315e4.wmfw. A newer Cirrus firmware would never have loaded. Updating removes copies identical to the bundled ones and leaves any other file alone.

audio-fix 3.1 uses a small B9406CAA-only snd-soc-sof-sdw DKMS overlay only on kernels that still need it. It discards only an RT722 that the SoundWire core has positively marked UNATTACHED; real RT722 hardware and every other model are untouched. The permanent DMI fix is already accepted upstream as 90af3209742d. Install inspects every installed kernel module rather than guessing from its version, skips DKMS on kernels containing the upstream quirk (Linux 7.3+), and removes the overlay automatically once every installed kernel has it. The quirk carries no Cc: stable, so no 7.2.y or 6.18.y release has it yet and 7.2 kernels still need the overlay. 3.1.1 fixes the overlay build on 7.2.y kernels whose soc_sdw_utils API gained the dev, ctx arguments through a stable backport (3.0.0 silently failed to rebuild there and audio fell back to Dummy Output); it probes the header instead of trusting the version, and no longer forces LLVM=1 on GCC-built kernels.

The F1 speaker-mute LED needs asus-wmi's platform::mute (WMI device 0x0004001C), which lands in Linux 7.4. Until then only platform::micmute exists; the kernel's audio-micmute trigger drives it.

The core problem is 802.11be (EHT / Wi-Fi 7) itself on the Intel BE211 (8086:e440) under iwlwifi/iwlmld: the EHT RX path can collapse to MCS0 / NSS1 and MLO sessions tear down, so the "Wi-Fi 7" link is slower and flakier than plain Wi-Fi 6 on this laptop.

$ journalctl -k -b | grep -c "missed beacons exceeds"
7228    # possible with Linux 7.2 C106 even on a strong, connected HE link

Drop the broken 802.11be layer so the radio runs as Wi-Fi 6 (HE). Same approach Omarchy ships; verified at ~2.1 Gbit/s over 160 MHz HE here:

Linux 7.2 additionally loads C106 firmware, and the driver can log thousands of missed beacons ... but receiving data warnings while the link remains strong, fast and connected. On the reference machine the bursts followed a single access point every 30–37 minutes and vanished on others, which points at an AP pausing its beacons (off-channel scanning, for example) more than at C106. Status shows the loaded firmware and count; it does not silence the warning or rewrite packaged firmware. Version 2.1 retires the old global ASPM-performance, power-scheme and offload tunables because they did not stop the warnings and were broader than the demonstrated bug. Linux 7.3 loads C107 and 7.4 is set to take C108; EHT stays off until a retest there shows the RX collapse is gone.

This is a deliberate Wi-Fi 7 → Wi-Fi 6 downgrade. Normal power management, offloads and iwlwifi.bt_coex_active=Y are retained, so Bluetooth coexistence continues to work.

The Samsung Display Corp panel in this laptop reports IEEE OUI 00:aa:01 in DPCD register 0x300 and supports Panel Replay Selective Update (Early Transport), which is the self-refresh mode Linux 7.2's xe picks by default on Panther Lake. In that mode the panel comes up visibly desaturated after every HDR-enabling modeset (KWin's HDR toggle, a fresh login with HDR on), and stale content lingers on screen after updates. The colors come back as soon as anything streams frames with the SDPs again (a KWin color-accuracy toggle, a write to i915_edp_psr_debug), so the panel appears to miss the new BT.2020/PQ signaling once Panel Replay stops the stream on a static desktop. Dropping only Early Transport keeps the washed out colors and slows cursor motion to ~20 fps, so Panel Replay itself is at fault.

Disabling Panel Replay alone (xe.enable_panel_replay=0, or the first version of the upstream-patches/0001 quirk) is worse: xe falls back to PSR2 selective update over the panel's DSC link, and every screen update paints red/green speckle garbage, goes black, then parks on garbage or the correct image at random. The most plausible cause is that the driver gates PSR2 + DSC on platform generation only, never on sink capability, while this panel advertises DSC selective update for Panel Replay alone. Disabling only selective fetch (xe.enable_psr2_sel_fetch=0) is not an option either: it keeps Panel Replay without selective update, which on Panther Lake freezes the panel on the boot console text until a VT switch repaints it.

Linux 7.0/7.1 also wedged the display engine outright, and 7.2 has not retired that signature under the Panel Replay default:

xe 0000:00:02.0: [drm] *ERROR* Timed out waiting PSR idle state
xe 0000:00:02.0: [drm] *ERROR* [CRTC:151:pipe A] DSB 0 timed out waiting for idle
kwin_wayland: Pageflip timed out! This is a bug in the xe kernel driver

On 7.0/7.1 a selective-fetch DSB deadlock under heavy compositing (a screen capture was enough) took the whole kernel down silently. A 7.2.0 boot with only the backlight parameter still logged DSB 0 poll error, CPU pipe A FIFO underrun and Timed out waiting PSR idle state, with corruption visible on screen (issue #7). The mismatch in vsc dp vsc sdp error and intel_modeset_verify.c WARN that 7.2 logs on every HDR modeset are a separate false positive: the driver's VSC SDP readout rejects the revision 7 packet it emits itself for Panel Replay with colorimetry, so the state checker compares against zeros. The upstream fix, "drm/i915/dp: Handle VSC SDP revision 7 in unpack" (fd2e337ba66f), is in drm-intel-next and should reach Linux 7.4.

PSR1 (full-frame self-refresh without selective update) passes everything testable on this panel: vivid colors across HDR off/on toggles, a smooth cursor, none of the stale-content artifacts, and self-refresh still saves power on a static screen. Both PSR parameters are needed. xe.enable_psr=1 alone leaves Panel Replay on, since Panel Replay bypasses the PSR2 validity check that parameter feeds into, and xe.enable_panel_replay=0 alone lands in the PSR2 + DSC garbage described above. To try it without a reboot, write 0x43 to /sys/kernel/debug/dri/*/i915_edp_psr_debug as root (0x40 disables Panel Replay, 0x03 forces PSR1; never write 0x03 on its own, which keeps Panel Replay and drops only selective update, the combination that freezes the boot) and confirm PSR mode: PSR1 enabled in /sys/kernel/debug/dri/*/eDP-1/i915_psr_status.

The older xe.enable_panel_replay=0 xe.enable_psr2_sel_fetch=0 pair that some owners already boot with lands on PSR1 as well: Panther Lake has no PSR2 hardware tracking, so without selective fetch the driver drops PSR2 and runs PSR1. xe.enable_psr=1 says the same thing directly, and ./patch.sh status display-fix accepts either pair.

Version 1.4 replaces 1.3's "keep the Linux 7.2 defaults" stance. With only the backlight parameter on the cmdline, owners reported PSR idle timeouts, DSB poll errors, FIFO underruns and on-screen corruption on 7.2.0, panel flicker and VRR smearing on 7.2.4, and washed-out HDR with stale frames on 7.2.2 (issue #7). Install removes the old xe-disable-psr.conf, which turned self-refresh off entirely. It no longer touches Omarchy's own /etc/limine-entry-tool.d/asus-expertbook-b9406-display.conf: that file sets only xe.enable_panel_replay=0, which agrees with PSR1. Version 1.3 archived it; 1.4 puts it back. Only a hand-edited copy that sets xe.enable_psr or xe.enable_panel_replay to something else is archived, because it sorts after this module's drop-in and would override it. ./patch.sh status display-fix warns when Panel Replay stays on, when xe.enable_panel_replay=0 appears without a PSR2 disable, when xe.enable_psr=0 turns self-refresh off, and when the panel's debugfs status reports anything but PSR1 (with VRR active the driver keeps PSR off, so the debugfs line reads disabled).

GRUB users put the same three parameters on GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub and run grub-mkconfig -o /boot/grub/grub.cfg; the modprobe.d half of the module still applies.

• Selective fetch area calculation failed in pipe A once per boot is an informational fallback to a full-frame update. It is harmless and goes away with PSR1, which does not use selective fetch.
• Stock 7.2.y kernels (Arch, Omarchy) carry only half of the fix for the trace-less hard freeze from display page tables in stolen memory (drm/xe #7513). The second half, 0687ec06f51b ("Do not allocate into stolen for new framebuffers"), is in 7.3; CachyOS kernels carry it since 7.2.1 (CachyOS#986).
• DSB 0 timed out / flip_done timed out with VRR's short vblank is fixed by b201029ca695 ("Ensure a non-zero safe window from PTL onwards") in 7.3, with no stable tag.
• Fullscreen switches on a Panther Lake Samsung OLED under KDE have been reported to cause plane faults and DSB poll errors on 7.2.7 (drm/xe #9385); KWIN_DRM_NO_DIRECT_SCANOUT=1 avoids them.
• With PSR1 active, KWin may be unable to turn VRR on at runtime, because the change needs a full modeset (drm/xe #9359).
• A 5K Apple Studio Display on this CPU can stay black after a cold boot even though the link trains; a physical replug brings it up (drm/xe #9153, open).
• Poweroff or reboot can hang in nhi_pci_remove on 7.2.y with a Thunderbolt/USB4 dock driving DisplayPort monitors; reproduced on a B9406CAA with a CalDigit TS5. Fixes are queued for 7.3 with Cc: stable (CachyOS#1047). Unplug the dock before shutting down, or boot the 6.18 LTS kernel.

Windows Studio Effects on Copilot+ PCs runs background blur, smart framing, eye-contact correction, and voice focus on the NPU. None of these are shipped on Linux out of the box, even though the Intel Panther Lake NPU itself is fully supported by the kernel (intel_vpu driver, /dev/accel/accel0 exposed) and the userspace stack (OpenVINO 2026, level-zero) is available via the AUR.

Without this module the NPU sits idle, the webcam feed has no AI processing, and there's no virtual-cam target for video chat apps to read from.

The user is also added to the render group as defensive future-proofing for stricter NPU device permissions. /dev/accel/accel0 ships world-writable today.

After install, the user opens OBS, adds a Video Capture Device source pointing at the real webcam, attaches the Background Removal filter, and starts the virtual camera. Any video chat app then sees the processed feed as "AI Camera".

Reality check — no NPU offload in OBS on Linux. obs-backgroundremoval has no OpenVINO/NPU execution provider on Linux (installing openvino does not add an "NPU" device); the filter runs on the CPU — fine for 720p30 background blur. For an actual NPU route see ericjchang/linux-studio-effects (OpenVINO + v4l2loopback), but it's validated on Arrow Lake, not yet Panther Lake, and installs via git + pip. Also: if another tool already uses v4l2loopback (e.g. linuxdrop on video_nr=20), this module's global options line collides — share one devices=2 video_nr=10,20 config instead.

Panther Lake is an "adaptive" thermal platform: the firmware carries the OEM's own thermal tables (Intel DTT: PL1/PL2 limits, passive trip points, a power-slider condition). The kernel's int340x drivers expose the sensors and limits, but nothing in the kernel runs that policy.

Scheduling is not the gap it looks like. This 16-core CPU has no SMT, so the kernel places work by core capacity ("Hybrid CPU capacity scaling enabled", P 1024 / E 701 / LP-E 625) instead of ITMT.

Package and service calls go through lib/distro.sh, so the hook also runs on apt systems. On Debian and Ubuntu only the thermald half is useful for now: Debian has no intel-lpmd package, and Ubuntu 24.04's 0.0.3 (February 2024) predates Panther Lake and exits within milliseconds of starting (verified on Pop!_OS 24.04). With INTEL_PERF_LPMD=1 the module warns when the enabled unit is not running and points at its journal; the unit stays enabled so a package upgrade that adds support starts it.

Version 1.2 stopped enabling intel-lpmd by default. Intel labels 0.1.1 (the CachyOS build) a test release not meant for distributions, and upstream main no longer changes cpusets by default. A public Panther Lake A/B test (XPS 16, battery, balanced) found no significant idle-power gain and roughly doubled app launch time with it; apps started while confined also size their thread pools to four CPUs. Updating from 1.1 disables the service unless INTEL_PERF_LPMD=1 is set. The earlier "parks idle work on a single LP-E core" and "≈2–2.5 W idle" claims were never measured on this laptop.

power-profiles-daemon stays in charge of profiles. thermald reads its slider state; intel-lpmd, when enabled, touches the same intel_pstate and SoC-slider settings, so the three are not fully independent layers.

This module ships no payload files — it's purely package install + service enable in the post-install hook. The patcher tracks it the same way it tracks file-based modules (versioned, idempotent, status-checked). Package and service calls go through lib/distro.sh, so the same hook runs unchanged on pacman and apt systems.

The bucketized ambient light response (ALR) curve is Microsoft's documented Windows 11 default for Keyboard Backlight Autobrightness, reproduced verbatim down to the registry string format:

The keyboard is dimmest-but-on in the dark, brightest between 40 and 100 lux, and off above 200–300 lux. That shape is the counter-intuitive part and it is intentional: in true darkness a keyboard at full power is glare against a dark-adapted eye, and in a bright room the keycap legends are already readable by ambient light, where backlighting only washes out their contrast.

Apple's Computer light adjustment patents (US 7,839,379 and family) describe the simpler inverse relationship instead. We follow Microsoft's because it is an exact, numeric, currently-maintained table rather than a prose description.

Finding the keypress took some digging. The Fn backlight keys emit no input event at all — verified on 2026-09-02 by listening on all fifteen /dev/input/event* devices while they were pressed, which captured nothing but touchpad traffic. The Asus WMI hotkeys device advertises KEY_KBDILLUMUP/KEY_KBDILLUMDOWN only because asus-nb-wmi's sparse keymap declares them.

The OS is not blind to them though. The kernel reports EC-initiated changes through the LED class's brightness_hw_changed attribute (POLLPRI) — which is how UPower notices and relays BrightnessChangedWithSource(level, "internal"), and in turn what raises KDE's on-screen display. That attribute carries the real level, unlike the plain brightness node stuck at 0, so the daemon both detects the press and learns what you chose:

EC set level 3/3 | manual override active for 0.0-18.5 lux (reading 9.2)
EC set level 0/3 | manual override active for 0.0-18.4 lux (reading 9.2)

One adaptation to the spec remains: Microsoft's host holds a specific percentage during an override, while here it means "stop writing" — the level you picked is yours until the ambient reading leaves the window. A value matching what the daemon itself last wrote is treated as its own change echoing back, so it never starts a spurious override. To stop the daemon touching the backlight at all, set enabled = no or sudo systemctl stop kbd-backlight-auto.

Watch it decide without letting it touch the backlight:

sudo kbd-backlight-auto --probe -v

17.3 lux | bucket 3 (12-32 lux, 70%) | would set level 2/3
20.4 lux | bucket 3 (12-32 lux, 70%) | level 2/3 (unchanged)

Everything is tunable in /etc/kbd-backlight-auto.conf, including the curve and the override table in Microsoft's own string format. The one knob worth knowing about is calibration: the curve's thresholds are absolute lux, so a mis-scaled sensor puts the keyboard in the wrong bucket.

Versions 1.x claimed the BIOS's SLKB ACPI method clamped OS-initiated brightness writes to zero, and shipped asusd to translate them into the OEM-tested 0x100..0x103 range. Re-measured on 2026-09-02 with asusctl not installed, /etc/asusd absent and asusd inactive:

The SLKB disassembly was accurate; the claim about which branch Linux reaches was not. Mainline asus-wmi never writes the bare 0..3 range that the buggy branch clamps:

static void kbd_led_update(struct asus_wmi *asus)
{
	int ctrl_param = 0;

	scoped_guard(spinlock_irqsave, &asus_ref.lock)
		ctrl_param = 0x80 | (asus->kbd_led_wk & 0x7F);
	asus_wmi_set_devstate(ASUS_WMI_DEVID_KBD_BACKLIGHT, ctrl_param, NULL);
}

0x80 | level lands in 0x80..0x83 — SLKB's second branch, the one v1.x itself documented as working. asusd's range translation had nothing to fix.

The real defect is kbd_led_read(): the firmware's query returns nothing usable, so the level always masks down to 0. asusd does not fix that either — it is a firmware read path, not a range problem.

The defect is in the query path only, though. The LED's sibling attribute brightness_hw_changed does report the real level whenever the EC changes it — that is how UPower relays BrightnessChangedWithSource(…, "internal") and how KDE's on-screen display appears on an Fn keypress. It is a notification, not a queryable state, so cat brightness stays broken; keyboard-backlight-auto uses it to stay in sync with a hand-set level. The visible cost is that systemd-backlight@leds:asus::kbd_backlight saves 0 at every shutdown and restores a dark keyboard at every boot; keyboard-backlight-auto is ordered After= it and overrides it within a second.

The v1.x status check was a false negative by construction — it wrote a level and read it back, and the read is always 0, so it reported FAILED on a perfectly working backlight. That check is gone.

What stays unknown is whether software control was genuinely broken on BIOS B9406CAA.304, the firmware v1.x was written against; the reference machine has since moved to 312 and 304 is no longer testable. What can be said is that the mechanism v1.x blamed cannot have been the cause. That uncertainty is why the module is kept rather than deleted:

sudo KBF_FORCE=1 ./patch.sh install keyboard-backlight-fix

Most of it transfers. The audio-fix firmware blobs are matched on PCI subsystem 1043:15e4 (this exact laptop). Sibling subsystems 104315d4 and 104315f4 ship different per-OEM tuning files in upstream linux-firmware. The camera capsule is strictly B9406CAA-only. The touchpad-fix, wifi-fix, display-fix, intel-perf-fix, webcam-ai-fix, keyboard-backlight-auto and keyboard-backlight-fix modules are hardware-agnostic or match by family-level identifiers and apply more broadly.

PRs adding module.sh entries for sibling models are welcome.

Yes. The FocalTech FT9349 (2808:a97a) is supported by upstream libfprint 1.94.100 and later. Install the normal libfprint + fprintd packages, then enroll with fprintd-enroll. No out-of-tree patch is needed on current Arch/CachyOS.

No. The Wi-Fi module deliberately leaves iwlwifi.bt_coex_active=Y alone. Bluetooth audio, HID, and file transfer keep working as usual.

Yes — on purpose. 802.11be / EHT is broken on the BE211 (RX collapses to MCS0/NSS1, MLO tears down), so wifi-fix disables it (disable_11be=Y) and the link runs as stable Wi-Fi 6 / HE instead — ~2.1 Gbit/s over 160 MHz 6 GHz here, faster in practice than the flaky EHT link. Drop the module (or set disable_11be=N) once Intel fixes the iwlwifi EHT path upstream.

The HiFi UCM (active since audio-fix v2.0.0, and upstream in alsa-ucm-conf 1.2.16) drives the mic-mute LED (platform::micmute) correctly. The speaker-mute LED (F1) stays in its EC default state before Linux 7.4, because until then this laptop exposes no speaker-mute LED device to Linux — there's nothing for the UCM SetLED hook to bind to. Linux 7.4's asus-wmi adds platform::mute (WMI device 0x0004001C) with an audio-mute trigger. A bridge for older kernels is under review in #16. It's a missing-device limitation, not a profile issue.

That's the goal — see upstream-patches/. The UCM and firmware are already released, and the B9406CAA ghost-RT722 kernel quirk landed in Linus' tree as 90af3209742d after Linux 7.2. audio-fix detects backports from the installed module itself, so its DKMS compatibility overlay disappears as soon as all installed kernels contain the upstream fix. The camera module remains a safe bridge for ASUS's Windows-packaged firmware capsule.

./patch.sh diff <module>          # before/after for the files in the module's MODULE_FILES

Output marks each file as unchanged / would update / would create with a coloured unified-diff for the changed ones.