Working stereo on the internal speakers of the ASUS ProArt PX13 (HN7306*, AMD Strix Halo) — on a stock kernel ≥ 7.1, surviving kernel and alsa-ucm-conf updates.
Kernel 7.1 / 7.2 / 7.3 users: one module source builds on all three — the
two SoundWire/SDCA calls that changed shape are probed from the target
kernel's headers at build time, not guessed from the version. The module is now
based on the 7.3 driver, so the s2idle resume fixes that landed upstream in
7.3 come with it on every kernel (until now the DKMS module was replacing the
in-tree 7.3 driver with a 7.2 one without them). If an earlier checkout left you with a failed DKMS build and the
stock driver silently taking over (stereo gone), pull and re-run
bash install-durable.sh, then bash check-audio.sh. Details in
Kernel updates.
Every SKU. Nothing is hardcoded to one machine: the ALSA card index, the
card long name, the ACP PCI address and the PipeWire node names are all probed
at install time (lib/px13-detect.sh), and the installer now fails loudly
instead of exiting 0 without sound. See
SKU independence.
Tested on CachyOS linux-cachyos 7.1.3, 7.1.8 and 7.2.2 and Fedora 44
7.1.12 (HN7306EAC) and reported working on HN7306EA / HN7306EA-LX005X. The
module compiles clean against Fedora's 7.1.12, 7.1.13, 7.2.3 and 7.3.0-rc1
kernel-devel trees. Should work on Arch, Fedora and other distros with minor path
adjustments — the build follows whatever toolchain the target kernel was built
with (clang on CachyOS, gcc on Arch stock and Fedora), so no manual LLVM=1.
On kernels < 7.1 the tas2783 driver in mainline was not usable and the fix was a patched kernel (nealstar's 16-patch series, packaged for CachyOS as
linux-cachyos-px13+asus-proart-px13-quirks). That method still works but requires a kernel rebuild on every update. The original guide and patch set are kept inpatches/for reference. Everything below is for stock kernels ≥ 7.1.
TI upstreamed a new tas2783 driver in Linux 7.1 (it is not nealstar's series). On the PX13 two problems remain:
| # | Problem | Symptom | Fix in this repo |
|---|---|---|---|
| 1 | On 7.1: the machine driver does not tag the card with spk:tas2783, so alsa-ucm-conf never creates the Speaker device. On 7.2 the kernel does emit the tag — but alsa-ucm-conf ships nothing for tas2783, so UCM now tries to load a sof-soundwire/tas2783.conf that does not exist |
7.1: no sound / "Dummy Output" / only pro-audio. 7.2: the card's UCM fails to open outright (failed to import hw:1 use case configuration -2) |
The three UCM files in configs/ (they are what alsa-ucm-conf is missing) plus the long-name override that pulls in the codec init |
| 2 | The driver initializes both amps with DSP cluster index 0x01 (the ASUS ACPI tables carry no usable SDCA/DisCo function data, so the driver falls back to a static init sequence) |
Mono from one speaker — which one can change between boots — or a phantom "center" image | Small DKMS module (stock driver + channel-selection control) + UCM setting Left/Right per amp |
| 3 | s2idle kills the audio stack in two layers: the slaves drop off the SoundWire bus (a plain PCI unbind/bind of snd_pci_ps does not bring them back), and even when the bus still reports Attached the TAS2783 DSP has lost its firmware (error playback without fw download — silent mute while every mixer level looks fine) |
Speakers dead/mute after suspend; the vanished card also wedges the WirePlumber graph so even Bluetooth audio stops | Detached systemd-sleep hook (systemd-run) + full module-stack reload → re-probe re-downloads the firmware (details) |
Bug #2 is not fixed in 7.2 or 7.3-rc1 either (same fallback init, still no channel control upstream). The one-speaker report in CachyOS/linux-cachyos#737 on kernel 7.1.1 is exactly this.
Firmware note: linux-firmware ≥ 20260519 ships the amp firmware as
ti/audio/tas2783/1714-1-0x8.bin / 1714-1-0xB.bin — no more extracting
blobs from the Windows driver.
git clone https://github.com/ftoleedo/px13-audio-fix.git && cd px13-audio-fix
bash install-durable.sh # asks for sudo when needed
# reboot once if the module can't be live-reloadedsudo bash install-durable.sh works too: the installer needs root for the
module and the UCM files but must not be root for the PipeWire half
(systemctl --user does not exist for root), so when started under sudo it
drops back to $SUDO_USER for those steps. If it cannot find a session to drop
back to it says so instead of half-failing (sudo PX13_USER=<you> bash ...).
The script:
- Probes the card index, the ALSA driver name and the
CardLongName, and aborts with a diagnostic if there is no SoundWire card or no TAS2783 amp. - Installs the patched
snd-soc-tas2783-sdwmodule via DKMS (auto-rebuilds on every kernel update) — falls back to a manual build into/lib/modules/$(uname -r)/updates/if dkms is not installed. - Installs the three UCM files under the long name of your machine, and removes any override this repo previously installed under a different SKU name (dead weight — UCM never reads it).
- Verifies that UCM now exposes a
Speakerdevice and exits non-zero with diagnostics if it does not. No more silent success. - Restarts PipeWire, selects the HiFi profile, checks the SoundWire peripherals, saves the ALSA state.
The suspend/resume recovery is a separate, optional step:
bash install-resume-recovery.sh # hook + recovery script + dry runTo revert the durable installation:
bash uninstall-durable.shIt removes the DKMS/manual module, the UCM files and the rt721 udev rule that
install-durable.sh put in place, then asks for a reboot so the stock module
loads. Files you edited after installing are preserved and reported, and the
separate suspend/resume recovery (with its shared detection cache) is left
alone.
The first version of this repo hardcoded four machine-specific values. Three of them were cosmetic; one silently broke every laptop that was not the machine it was written on:
| Hardcoded | Actually varies with | Symptom when wrong |
|---|---|---|
LONG=ASUSTeKCOMPUTERINC.-ProArtPX13HN7306EAC-1.0-HN7306EAC |
the SKU (DMI product name) | silent total failure |
CARD=1 |
boot order / other sound cards | wrong card poked |
alsa_card.pci-0000_c4_00.5-platform-amd_sdw |
ACP PCI address | profile switch fails |
PCI=0000:c4:00.5 |
ACP PCI address | resume recovery does nothing |
The first one is fatal because of how ALSA UCM resolves configs
(/usr/share/alsa/ucm2/ucm.conf):
conf.d/${CardDriver}/${CardLongName}.conf <- probed first
conf.d/${CardDriver}/${CardDriver}.conf <- package-owned fallback
CardLongName is built from DMI, so it differs per SKU:
ASUSTeKCOMPUTERINC.-ProArtPX13HN7306EAC-1.0-HN7306EAC 128 GB / GOPRO
ASUSTeKCOMPUTERINC.-ProArtPX13HN7306EA-1.0-HN7306EA 64 GB, LX005X, ...
An override installed under the wrong name is never read. UCM falls back to the stock config, the HiFi profile has no Speaker device, PipeWire shows a dummy sink — and the old installer still printed its steps and exited 0.
Check yours with:
amixer -c "$(cat /proc/asound/cards | grep -i soundwire | awk '{print $1}')" info
# Card sysdefault:1 'amdsoundwire'/'<-- this string is the long name -->'Since then everything is probed at runtime and the installer refuses to finish without a working Speaker device. Found by @jamescutts (silent failure on a 64 GB HN7306EA), pinpointed to that variable by @dmicheel (who hit it on a non-GOPRO HN7306EA-LX005X too) and confirmed by @DevGrishin, in CachyOS/linux-cachyos#737.
The DKMS module is a copy of the upstream driver plus one control, so it rides on an API that moves. Several times now an update has degraded the audio silently — and the last three rows are not about the module at all, but about userspace reacting to a half-recovered card:
| Kernel | What changed | What you saw |
|---|---|---|
| 7.2 | sdca_parse_function() lost its struct sdca_function_desc * parameter (now read from function_data->desc), and resume moved to a new sdw_slave_wait_for_init() helper |
DKMS build failed during the pacman transaction, the stock module loaded instead, Channel Playback disappeared → mono from one speaker |
| 7.3-rc1 | the same function also lost its struct sdw_slave * parameter |
same, if built from the 7.2 source |
| 7.1 (after the 7.2 rebase) | a 7.2-only source has neither the 7.1 sdca_parse_function() shape nor sdw_slave_wait_for_init() |
same again, on any distro still shipping 7.1.y (Fedora 44 at the time of writing) |
| 7.2 | the kernel started tagging the card spk:tas2783 — while alsa-ucm-conf (1.2.16.1) still ships no tas2783 config |
on a machine without this repo, worse than 7.1: UCM cannot open the card at all instead of silently skipping the Speaker device |
| (any) | a driver swap under a live WirePlumber | the stored per-route volume can come back at 0% — sink unmuted, HiFi active, paplay exits 0, and nothing comes out |
| 7.3-rc2 | the rt721-sdca jack codec runtime-suspends ~7 s after any probe (boot included) and never resumes — regcache_sync() gets -ENODATA, the peripheral ignores the bus although sysfs says Attached |
no speaker sink at all. The UCM HiFi verb has four mappings and the ACP requires every one of them to probe, so the dead Headphones mapping drops the whole profile and takes Speaker with it — the card is left offering only off and pro-audio. A reboot does not clear it. Fixed by 90-px13-rt721-no-autosuspend.rules (installed by install-durable.sh), which forbids the codec's runtime PM at device-add time so the first suspend never happens |
| (any) | WirePlumber re-probing a profile its saved state wants but the ACP rejects | a retry loop: ~290 kernel messages/minute, the desktop's sound panel flickering, and the amp's capture port rejected on every attempt. Stopping WirePlumber drops it to 1 message per 20 s |
| (any) | after any amp probe, tas2783-N Speaker Volume reads 153/200 — the scale is 0.5 dB/step from −100 dB, so that is −23.5 dB. Who writes it is not pinned down: the driver's regmap paths and tas2783_init_seq do not touch DVC_LVL, its default is 200, and the firmware download bypasses the regcache |
"working but quiet" with every percentage in the UI at 100%. Normally invisible: when WirePlumber manages the card, its route restore raises the control back to 200 on profile activation. It only shows when the card is unmanaged (a rejected profile, a static sink) — then nothing raises it. (An earlier revision of this table blamed the route restore for lowering it; that was backwards.) |
| (any) | a PipeWire restart (the recovery does one, so did every debugging session here) while a browser is open | Chromium/Brave/Electron keep their audio-service connection and never re-enumerate: playback still works, but WhatsApp Web, Meet & co. say "microphone not found" until the browser is restarted (brave://restart). Not a PipeWire or driver problem |
| (any) | the internal DMIC at 100% | speech lands around −38 dBFS — the ACP DMIC has no capture gain control and is simply quiet — which voice-activity detectors treat as silence. install-durable.sh raises the Mic source to 170% (+13.8 dB); a headset in a2dp-sink has no microphone at all (that is the profile, switch to headset-head-unit for its mic) |
Nothing logs an error for either of these, which is why there is a checker:
bash check-audio.shIt verifies the four invariants — patched module in updates/ (extra/ on Fedora), DKMS built for
the running kernel, both amps on different channels, and a speaker sink that is
neither muted nor at 0% — and prints the exact command to fix each one. Run it
after every kernel update; exit code is non-zero if anything is off.
check-audio.sh runs on the machine after an update has already broken it.
To catch the same class of breakage before it ships, bash .gate builds the
module against every kernel header tree installed here (skipping anything older
than 7.1, which the repo does not support) and fails on the first error or
warning:
bash .gate # every /usr/lib/modules/*/build
PX13_EXTRA_KDIRS=/path/to/kernel-devel bash .gate # plus a tree you do not runOne kernel proves nothing about API drift, so it warns when fewer than two are
available. Both regressions above would have been caught by it: install headers
for a second series (or extract a distro kernel-devel and point
PX13_EXTRA_KDIRS at it) before releasing a module change.
check-audio.sh reporting a healthy module, healthy DKMS, correct channels and
a working UCM but no speaker sink is the rt721-sdca failure above, not an
amp problem. Confirm it in two commands:
cat /sys/bus/soundwire/devices/sdw:0:1:025d:0721:01/power/runtime_status # suspended
journalctl -k -b | grep 'rt721.*-61' # pm_runtime_get failingcheck-audio.sh now reports this as jack codec (rt721) alive and names the
fix. A reboot does not clear it — the codec dies ~7 s after every probe. What
clears it is forbidding its runtime PM before that first suspend:
bash install-durable.sh # installs 90-px13-rt721-no-autosuspend.rules
sudo /usr/local/lib/px13-soundwire-recover.sh # re-probes with the rule activeVerified on 7.3.0-rc2: with the rule, the codec stays active (0 ms suspended),
no -61, the HiFi profile probes, and the Speaker sink is back through UCM.
Cost: the jack codec stays powered. Remove the rule once its resume works
upstream again.
If you need sound before running that: a static sink straight on the amp's
PCM (hw:1,2, S16_LE, 2ch, 48 kHz — check with
aplay -D hw:1,2 --dump-hw-params) works without the profile, and a WirePlumber
rule setting device.disabled = true on the card stops the re-probe loop. Both
are stopgaps, not configuration this repo installs, and the static sink leaves
Speaker Volume at −23.5 dB (see the table) — set it to 200 by hand.
Verified on 7.2.2 by pointing ALSA_CONFIG_UCM2 at a copy of the system tree:
with none of this repo's files, alsaucm -c1 list _devices/HiFi dies with
could not open .../sof-soundwire/tas2783.conf; with the two codec files but no
long-name override it dies with variable '${var:SpeakerMixerElem}' is not defined (the base config's If.spk regex still does not list tas2783, so the
codec init is never included). All three files are still required on 7.2 — the
long-name override for a new reason.
The proper upstream fix for this half now belongs in alsa-ucm-conf, not the
kernel: a sof-soundwire/tas2783.conf and codecs/tas2783/ upstream would
retire two of the three files here.
The module is now based on the 7.3 driver. The two calls that differ on older
kernels — sdca_parse_function() and the resume wait — are handled by
build-time probes of the target kernel's headers (module/Makefile), because
LINUX_VERSION_CODE is not a reliable guide: @leepaulmann found Arch
7.1.9-arch1-2 carrying a different sdca_parse_function() than CachyOS 7.1.x
under the same version code. It builds clean on 7.1.13, 7.2.4 and 7.3.0-rc2
(the .gate proves all three). Upstream 7.2 also absorbed two of the three local
patches (the tas25xx_*_misc stubs and the 0x firmware-name prefix, which
upstream implemented better, with a fallback), so the entire local delta is
now the single Channel Playback control — 31 lines over stock.
Three independent failures happen around s2idle on this machine, plus one
self-inflicted trap. All four were diagnosed on linux-cachyos 7.1.5-1:
- The SoundWire slaves vanish. After resume the devices under
/sys/bus/soundwire/devices/sdw:0:1:*are gone (or stuckUNATTACHED). A plain unbind/bind of thesnd_pci_psPCI device — the classic advice, and what the old hook here did — no longer re-enumerates them. - The TAS2783 firmware is wiped even when the bus looks healthy. On some
resumes the slaves stay
Attached, every mixer switch is on, the sink is unmuted, the HiFi profile is active — and the speakers are silent. dmesg has the smoking gun:error playback without fw download. The amp's DSP lost its firmware and only a full driver re-probe re-downloads it (/lib/firmware/ti/audio/tas2783/). This is why "check if it's Attached and skip" is a bug: recovery must run unconditionally. - The wedged card takes Bluetooth down with it. The vanished ALSA card leaves WirePlumber's graph broken ("PipeWire links failed to activate"): BT devices connect but no stream can link to them. Only a PipeWire/ WirePlumber restart clears it.
- The trap: doing any of this inline in a system-sleep hook. Post hooks
block
systemd-suspend.service, and systemd keeps the user session (user.slice) frozen until the service finishes. An inline recovery means a black screen for up to the 90 s service timeout on every wake — and a guaranteed deadlock if the hook tries to restart the session's PipeWire (which is frozen, waiting for the hook).
The fix is therefore split:
| File (repo) | Installed to | Purpose |
|---|---|---|
50-px13-soundwire |
/usr/lib/systemd/system-sleep/ |
post hook: dispatches the recovery as a transient unit (systemd-run --no-block --collect) and exits immediately — the screen is back in ~3 s |
px13-soundwire-recover.sh |
/usr/local/lib/ |
the actual recovery. On kernel ≥ 7.3 the default policy is auto: it waits 10 s for the resume to settle and, if the ACP is bound and every codec is Attached, does nothing — the 7.3-based module re-initialises the amps and re-applies the channel assignment by itself, so a healthy resume costs no silence and no PipeWire restart. Only a broken bus (or PX13_RECOVER_POLICY=always, the default below 7.3) triggers the full reload, ~30 s in the background: unbind PCI → unload the whole SoundWire/ACP module stack (order derived from lsmod at run time — zero-refcount modules first, in passes — so a renamed platform module on a new kernel cannot leave part of the stack loaded, as snd_sof_amd_acp7x did on 7.3) → reload → wait for Attached (probe re-downloads the amp firmware) → always restart the session PipeWire → reapply HiFi profile, unmute, restore default sink only if nothing better holds it |
lib/px13-detect.sh |
/usr/local/lib/px13-audio-detect.sh |
the probes, shared by every script |
| — | /etc/px13-audio-fix.conf |
cache of the ACP PCI address and long name, written while the hardware is healthy — the recovery needs them precisely when the card has already vanished from /proc/asound |
test-sdw-module-reload.sh |
— | interactive version of the same recovery; sudo it to bring audio back right now (plays a test sound and reports SUCCESS/FAIL) |
Install all of it with bash install-resume-recovery.sh (it also does a dry run
with a healthy bus, so you find out it works without having to suspend).
Everything is logged to /var/log/px13-soundwire-resume.log.
| File (repo) | Installed to | Purpose |
|---|---|---|
module/ |
/usr/src/snd-soc-tas2783-sdw-px13-1.2 (DKMS) |
Stock 7.3 tas2783 driver (with its s2idle resume fixes) + Channel Playback control; the two calls that differ on 7.1/7.2 are probed from the target kernel's headers at build time |
configs/ucm-card-override.conf.in |
/usr/share/alsa/ucm2/conf.d/<CardDriver>/<CardLongName>.conf — both probed, template placeholders substituted at install time |
Forces the speaker codec; unowned by any package → survives alsa-ucm-conf updates |
lib/px13-detect.sh |
/usr/local/lib/px13-audio-detect.sh |
Runtime probes: card, driver, long name, amp count, ACP PCI, PipeWire names |
90-px13-rt721-no-autosuspend.rules |
/etc/udev/rules.d/ (only if an rt721 is on the bus) |
Keeps the jack codec out of runtime suspend — on 7.3-rc2 it never resumes, and PipeWire drops the whole HiFi profile with it |
check-audio.sh |
— | Post-update health check; non-zero exit if any invariant broke |
configs/sof-soundwire_tas2783.conf |
/usr/share/alsa/ucm2/sof-soundwire/tas2783.conf |
Speaker device for the HiFi profile; sets tas2783-1 = Left, tas2783-2 = Right on every profile activation (guarded on the second amp existing, so a single-amp variant still gets a mono Speaker instead of a broken profile) |
configs/codecs_tas2783_init.conf |
/usr/share/alsa/ucm2/codecs/tas2783/init.conf |
Volume-control remap (supports both driver generations) |
50-px13-soundwire |
/usr/lib/systemd/system-sleep/ |
Recovers SoundWire after s2idle |
configs/99-echo-cancel.conf |
~/.config/pipewire/pipewire.conf.d/ |
Optional: echo-cancelled mic source for calls |
configs/51-amd-sdw-channels.conf |
~/.config/wireplumber/wireplumber.conf.d/ |
Optional: FL/FR channel positions on the speaker node |
The DKMS module is the stock 7.3 tas2783-sdw.c — which carries Andrey
Golovko's three s2idle resume fixes (drop the stale regcache on re-attach,
power the Function up before preparing the port, writeable_reg so a cache
sync does not try to write read-only SDCA controls) — with one functional
addition, nealstar's channel-selection control rebased onto it, plus two
build-time-probed shims for the calls that differ on 7.1/7.2:
tas2783-N Channel Playback : enum { Off, Left, Right }
It writes the SDCA control PPU21 / UDMPU CLUSTERINDEX (values 0 / 1 / 4),
which tells each amp's DSP which channel of the stereo stream to render.
Without it both amps stay at the boot value 0x01 written by
tas2783_init_seq.
uname -r # stock kernel, >= 7.1
modinfo -k $(uname -r) snd_soc_tas2783_sdw -F filename
# -> .../updates/... or .../extra/... (the DKMS/patched module, not .../kernel/sound/...)
C=$(awk '/soundwire/ && /^ *[0-9]+ \[/ {print $1; exit}' /proc/asound/cards)
alsaucm -c "$C" list _devices/HiFi | grep Speaker # must print "Speaker"
amixer -D "hw:$C" cget name='tas2783-1 Channel Playback' # values=1 (Left)
amixer -D "hw:$C" cget name='tas2783-2 Channel Playback' # values=2 (Right)
pactl list cards | grep "Active Profile" # HiFi
speaker-test -D pulse -c2 -l1 -t wav # voice L/R from the correct sideIf the sides are physically swapped, exchange the two cset values in
/usr/share/alsa/ucm2/sof-soundwire/tas2783.conf and restart PipeWire.
- "Dummy output" / no Speaker device — the long-name override is missing or
installed under another SKU's name.
bash install-durable.shnow detects the right name and refuses to finish without a Speaker device; if you are fixing it by hand, compareamixer -c <card> info(the string after the/) with the file names in/usr/share/alsa/ucm2/conf.d/amd-soundwire/. As a last resort you can force it:PX13_LONGNAME='<name>' bash install-durable.sh. - Mono / one speaker only, right after a kernel update — the DKMS build
failed and the stock module took over.
bash check-audio.shsays so in one line;dkms statusand/var/lib/dkms/snd-soc-tas2783-sdw-px13/<version>/build/make.logsay why. If the driver API moved again, the module source needs a rebase (see Kernel updates); otherwisebash install-durable.shis enough. Without dkms:cd module && makethen reinstall — the Makefile picks the right toolchain on its own. - Everything looks right and nothing comes out (sink unmuted, HiFi active,
paplayexits 0,speaker-testruns) — check the volume, not the mute:pactl get-sink-volume <speaker sink>. WirePlumber persists a per-route volume, and a driver swap under it can bring it back at0% / -inf dB. The installer now raises a 0% speaker sink to 60%;bash check-audio.shflags it. - Sound goes to pro-audio profile / "Invalid argument" — switch profile:
pactl set-card-profile "$(pactl list short cards | awk '/sdw/{print $2;exit}')" HiFi. - Dead after suspend —
bash install-resume-recovery.sh; recover immediately withsudo /usr/local/lib/px13-soundwire-recover.shorsudo ./test-sdw-module-reload.sh. - Silent speakers although everything looks right (sink default and
unmuted, HiFi active,
amixerswitches on) after a resume — that is the wiped TAS2783 firmware (dmesg | grep 'without fw download'). Same fix as above: full module reload; a rebind alone will not re-download it. - Bluetooth connects but plays nothing after a resume — wedged WirePlumber
graph:
systemctl --user restart wireplumber pipewire pipewire-pulse. If the BT device then only offers headset (mono) profiles, disconnect and reconnect it to rediscover A2DP. - Audio jumps to Bluetooth after profile switch — set the default sink
once:
wpctl set-default <id of Audio Coprocessor Speaker>. Failed to connect to user scope bus ... $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined— you are on a version older thanff53876and ran the installer entirely as root. Pull and re-run; the system half is already installed, the script is idempotent.
The proper fix belongs in the kernel: either the Channel Playback control
or an ACPI/platform quirk mapping each amp's SoundWire unique_id to a
channel, since the PX13's ACPI provides no usable SDCA function data
(function type only supported as DisCo constant). Until something lands,
this repo keeps working setups alive across updates. Progress is tracked in
CachyOS/linux-cachyos#737.
The s2idle behavior is a second kernel bug worth reporting upstream
(ALSA/SoundWire): tas2783-sdw should re-download the DSP firmware in its
system-resume path (today it can come back Attached with no firmware and
mutes silently), and the AMD SoundWire manager (soundwire_amd /
snd_pci_ps) fails to re-enumerate its slaves after s2idle on Strix Halo —
a full module reload should not be necessary.
- nealstar — original 16-patch series, including the channel-selection control this module carries.
- fecet — CachyOS packaging (
linux-cachyos-px13,asus-proart-px13-quirks) for the < 7.1 era. - TI / Niranjan H Y, Baojun Xu, Kevin Lu — upstream tas2783 driver.
- jamescutts, dmicheel, DevGrishin — found and pinpointed the silent SKU dependency (the UCM long name), which is what made this repo SKU-independent.
Guide and scripts: CC0. Kernel module: GPL-2.0 (derived from the upstream driver).