Board 8D87: keyboard lighting end to end, plus the AMD SMU mailbox and iGPU Curve Optimizer corrections found beside it

[tempestnano]

Everything here was found on one machine — OMEN MAX 16-ak0098nr, board 8D87, BIOS F.07, EC 40.38, Ryzen AI 9 HX 375 — and every claim below is scoped to it unless it cites upstream source. Two tracks landed together because the second was found while verifying the first: the AMD tuning page was open beside the lighting page throughout, and its slider turned out to be mislabelled and its mailbox misaddressed on this silicon.

• Keyboard lighting — the per-key picture, brightness, colour pickers, the Fn+1/Fn+2 cycle, and the two owners that were taking the picture away.
• AMD SMU — a mailbox address that was wrong for Strix Halo, an iGPU Curve Optimizer gate that shipped a slider the silicon refuses, and the label above it.

---

Part 1 — Keyboard lighting

The per-key picture is the MCU's colour map, not the LampArray

This keyboard has two lighting interfaces, and which one carries the picture decides almost everything else:

	what it is	brightness?	who redraws it
mi_04	HID LampArray, addressed by lamp id	yes — a per-lamp intensity byte	the host, every frame
mi_03	the MCU's own 176-entry static colour map	no — raw RGB, drawn as handed over	the MCU, autonomously

Per-key painting goes to mi_03, so the picture survives the Fn overlay — the MCU redraws its base layer from state it owns, which a LampArray frame is never part of. mi_04 is reached only as the fallback for a board whose lamp ids cannot be resolved to colour-map positions.

The runtime log shows the split exactly:

[KeyboardMap] Apply: 176 LEDs ledsOk=True, 0 keys keysOk=True, bar=True barOk=True

176 LEDs through the colour map; zero lamps through the other interface.

Brightness: a master over the picture, and a level per cell

The Brightness slider did nothing on this board. DojoPerKeyBackend stored its value in _brightness and applied it only where an intensity byte exists, which is mi_04 — so on every board that has a layout, _brightness was written and never read.

Nothing surfaced that. The slider moved, the view-model held the value, the backend held the value, and the write returned True. There is no colour readback on either interface, so "accepted" was the entire software claim — and it was accurate. Only the keyboard disagreed.

Brightness is now host-side arithmetic in DojoPerKeyBackend.WriteColorMap, the single point every colour map passes through on its way to mi_03, scaled linearly and rounded to nearest exactly as mi_04's intensity channel scales a lamp. It is two controls, because one slider was doing two unrelated jobs — it scaled the whole picture and drove the light bar, so "dim these four keys" had no expression and dimming the keys dimmed the bar with them:

• The master is the backend's, applied on the way to the wire.
• The per-cell level is applied in the view-model, as a separate field rather than a rewrite of the picked colour. Baking it into the hex is lossy and one-way — drag a key to 10% and back to 100% and the colour is gone, quantised to whatever survived. A test fails if someone simplifies it that way later.
• Light bar zones take a level too. HP's frame carries one brightness byte for all four zones, so per-zone dimming cannot go to the firmware and is the same host-side arithmetic. The master still rides the byte.

Three things that had to be right alongside it:

• The retained map is unscaled. SetBrightnessAsync re-sends the same picture at a new level; keeping the scaled bytes would compound every change on the last dimmed copy.
• _mcuShowsHostMap tracks whether the map is what the keyboard is drawing. A brightness change repaints a static picture, but must never freeze a running device animation into a still frame, never un-blank a keyboard whose backlight is off (the colour write carries 0x09/0x01, which would turn it back on), and never fight host lamp ownership.
• The caps preview their own level but not the master — at master 3 the whole editor goes near-black and you cannot see what you are painting. The preview's rounding is pinned to the backend's by a test: with no colour readback, a disagreement between what the cap shows and what the key does has nothing to settle it.

A device-rendered effect cannot be dimmed on this board

That is a hardware limit, and it now rests on measurement rather than on inference. The claim used to rest on [4] of the effect record reading back unchanged through every frame ever sent — but every one of those frames carried 0, so a firmware treating 0 as "leave alone" would have looked identical to one that ignores the field. --effect-brightness was added to LightingProbe and measured:

sent	read back	rest of the frame
0 (historic)	200	consumed
60	200	consumed — effect → Wave, colour → #FF0000
160	200	consumed — colour → #00FF00

160 is a value this firmware has itself been observed holding, not an out-of-range guess. Both frames were demonstrably acted on — effect, colour, speed and direction all took — and brightness alone was ignored at zero and non-zero alike. So it is not a zero-sentinel.

MCU command 0x0C is still sent and still expected to fail here: it is not acknowledged at any payload value (0, 1, 2, 3, 50, 100) while 0x03, 0x83, 0x09, 0x0A and 0x10 are all acknowledged through the same handle and the same frame builder. Five accepted and one refused across six payloads is the command being rejected, not a bad value or a broken transport. It costs one frame and is the right lever on a board that implements it, so it stays.

Two silent drops made loud

KeyboardLightingServiceV2.SetPerKeyBrightness returned false for any non-DojoPerKeyBackend backend and said nothing; it now logs which backend declined, and KeyboardMapViewModel surfaces that in the Apply status line rather than leaving a user to infer a dead slider from a keyboard that did not dim.

Colour pickers on the two cards that never had one

The device-effects card and the light bar card took custom colours as hex text and nothing else, so choosing one meant already knowing its hex. Both now use the same ColorPickerDialog the per-key editor has always had, with the same gesture — the swatch is the picker button — reused rather than reimplemented, because two colour-picking implementations in one app is how they end up disagreeing about what a hex string means.

The swatches render on every keystroke, since the hex boxes bind with UpdateSourceTrigger=PropertyChanged. Typing #FF8800 walks through #, #F, #FF… and a converter that throws on those turns ordinary typing into a stream of binding failures; they fall back to black instead. One intermediate state is not what it looks like: WPF's ColorConverter reads four-character hex as #ARGB shorthand, so #FF88 is a real colour rather than a parse failure, and the swatch briefly shows it on the way to #FF8800. Found by asserting the obvious guess and watching it fail.

The Fn keys were already a profile switcher

Polling the MCU's 0x83 state read in-process at 10 Hz while the keys were pressed, with HP's OmenCommandCenterBackground stopped:

• Fn+1 and Fn+2 are one control — next and previous through a single list. Fn+3 through Fn+0 do nothing to lighting.
• The list holds what a host wrote to it. Two entries in the observed cycle were this project's own probe writes, and an ordinary 0x03 effect frame was enough to install one.
• One slot per effect type, holding that effect's last parameters. Wave was written red then green in one session and only green appeared — not an append-only history.
• 0x0A StoreLightingToFlash neither creates nor reorders slots.

A new "Fn+1 / Fn+2 cycle" card stages effects, marks one as Showing, and writes them. Profiles written this way are recalled by the keyboard itself — with OmenCore closed, uninstalled, or on a machine where it was never installed. Two firmware rules live in FnCyclePlan where they can be tested rather than in the view model: duplicate effect types collapse to the later one (the firmware would overwrite anyway, and the survivor keeps the earlier position so removing a duplicate does not silently reorder a cycle someone has learned), and the Showing profile is written last, because the keyboard displays whatever arrived most recently and no command says which one to show.

The card says out loud what cannot be discovered by trying: writing adds to or updates what the keyboard holds, nothing in the mapped command surface removes or reorders a slot, and 0x83 reads only the effect currently showing — so a profile taken off the staged list stays on the keyboard with no readback that could reveal it. Swipe staged with a theme is flagged before any frame goes out, since it has no preset palette on this firmware and renders black, which inside a cycle is discovered days later by pressing Fn+1 into a dead keyboard.

One correction worth recording. The 0x83 poll tears while any key is held — around 17% of samples come back with a corrupt leading byte, giving an effect id of 236, a colour count of 36, or a speed of 8, none of which those fields can hold. That is not the Fn write: it happens just as much while pressing Fn+3..Fn+0, which change nothing, and the same poll runs at 0% torn over 400+ samples at rest. It is ordinary HID input traffic colliding with the feature read. Filter on field plausibility and the signal is clean; print the torn frames as state and you will invent a finding.

Windows repaints the keyboard the moment we let go of it

Reported as "the keyboard colors don't seem to stick if I close the program". Nothing about the apply failed — the colours applied, held while the app was open, and were gone at the next launch.

It is not OmenCore erasing its own work. The whole picture goes through mi_03, the MCU holds that map and redraws it autonomously, and Dispose's comment says exactly this and is correct. Windows Dynamic Lighting is the second owner, and it wins whenever no application holds the device. While OmenCore holds host control it is incidentally locking Windows out; releasing on the way down ends that, and Dynamic Lighting repaints within one refresh interval — 33 ms on this board, which the device itself reports as its minimum update.

Measured the only way this hardware allows, since there is no colour readback anywhere: with AmbientLightingEnabled = 1 the picture reverted on exit; with Dynamic Lighting off and nothing else changed, the same picture held. One registry toggle, two outcomes, no rebuild and no reboot between them.

HidLampArray's class comment already named this hazard almost word for word, down to the 33 ms — "Arbitrating with Dynamic Lighting is a policy decision, not a transport one." The hazard was understood and written down, and then no policy was ever decided. This is that decision:

DynamicLightingState reads the master toggle and the per-device card and reports whether Windows will take the device back. Read-only on purpose — these are another feature's settings and the user owns them, so the editor explains and offers to open the Settings page rather than quietly switching off a Microsoft feature to make ours look better. The per-device card is treated as a veto rather than as something that tracks the master, because it was only ever observed in one state and inferring the other would be guessing at semantics nobody measured.

Registering as a Dynamic Lighting-aware app was costed and rejected for this symptom, recorded here so it is not proposed again as an oversight. Ambient control requires MSIX package identity — enforced by the AmbientLightingServer, which only accepts clients that have it — and, decisively, control of either kind ends when the process ends. Neither foreground nor ambient registration produces a picture that holds with OmenCore closed.

Save to keyboard, and a picture written down

With Windows no longer taking the device, the keyboard draws its own colour map — and nothing made that map durable or wrote the picture down anywhere.

Autonomous mode is the contract rather than a workaround. Microsoft describes a device Windows is not driving as one that "operates in Autonomous mode … the hardware falls back to default behavior as defined by its firmware". On this keyboard that firmware default is the mi_03 colour map, so storing the map to flash is how an application participates correctly.

StoreToFlash existed, was documented, and was reachable through the service — and only the Fn-cycle write ever called it, which persists the effect record. No per-key apply flashed anything, so a painted picture was volatile MCU state and a power cycle took it.

That the colour map is flashable at all is not an assumption: HP's own client does it on every per-key apply — DojoKbLightingModel.SetKeyColor passes isWriteRegistry: true unconditionally, so 0x0A follows every colour round, and that is what makes a picture set in OGH survive a reboot. We deliberately do not copy that literally, because 0x0A writes MCU flash and "every apply" in an editor with a brightness slider is a flash write per slider drag. One button, one write, one intent — and it applies before flashing, since flashing whatever happens to be installed would persist the previous picture and report success.

config.json keeps a second copy, as painted — colour and per-cell level stored apart rather than flattened, for the same lossiness reason as above — restored at startup, where it takes precedence over the four-zone fill because the two describe the same keyboard at different resolutions and the fill would erase a picture completely. Restoring the editor and repainting the hardware are kept separate: the constructor restores cells and sends nothing, because the keyboard may already be showing this picture from its own flash, and painting on construction would overwrite a device effect the user chose since.

---

Part 2 — AMD SMU corrections

Strix Halo was given Phoenix's mailbox

ConfigureSmuAddresses grouped StrixHalo with VanGogh, Rembrandt, Phoenix, Mendocino and HawkPoint on MP1 address set 2 — message 0x3B10528, response 0x3B10578. It belongs on set 3 with Strix Point: 0x3B10928 / 0x3B10978.

RyzenAdj's nb_smu_ops.c selects set 3 for FAM_KRACKANPOINT, FAM_STRIXPOINT and FAM_STRIXHALO in one case group. UXTU reaches the same split independently and from the other direction: Socket_FT6_FP7_FP8 shares a single message table across the socket group but branches the mailbox addresses for exactly those parts. Two implementations, no coordination, same answer — and the value they agree on is the one already in use for Strix Point.

While Strix Halo sat in the set-2 arm, every MP1 message sent on a Ryzen AI MAX landed on registers that part does not read. Nothing caught it, because a write to an address the SMU ignores does not report an error — it reports nothing, and the readback path then compared one unrelated value against another.

The doc comment claimed the addresses were cross-checked against nb_smu_ops.h. They are defined in nb_smu_ops.c; the header carries no per-family selection at all, so that cross-check could not have found this.

The iGPU Curve Optimizer gate shipped a slider the silicon refuses

SetIgpuCO's PSMU 0xB7 arm listed Strix Point, Strix Halo and Mendocino alongside the four families upstream actually maps. RyzenAdj's set_cogfx (lib/api.c, v0.19.0) has Cezanne/Renoir/Lucienne on MP1 0x64 and Rembrandt/Phoenix/HawkPoint/VanGogh on PSMU 0xB7, and no others. Strix Halo is the pointed one: it has a case in set_cogfx carrying only the comment "0xB7 is rejected on this architecture" before falling through to default — so of the four names SupportsIgpuUndervolt let through, the one that resolved to a real arm resolved to the message upstream measured as refused. 7945H and 7845H are Dragon Range and reach no arm at all. Only 6900H was ever aimed at a supported id.

None of that surfaced because _lastIgpuCO was assigned regardless of the mailbox's answer, so a refusal read back as the requested offset. Families with no confirmed id now return UnknownCmd rather than Failed, and the warning tells "no message exists for this family" apart from "the SMU refused the message we sent".

Strix Point stays shut, and now for a measured reason rather than an inherited table. RyzenAdj gives it no set_cogfx case; UXTU's socket table would send 0xB7 anyway. SmuProbe --igpu asks the part, on a Ryzen AI 9 HX 375:

PSMU 0xB7 -> CmdRejectedPrereq        MP1 0xB7 -> UnknownCmd

identically for CO −20 and CO 0, so the refusal is about machine state and not the argument. The two statuses differing is the finding: UnknownCmd would mean the message does not exist, CmdRejectedPrereq means the PSMU knows it and declined. It also corroborates the mailbox above — a wrong address gives timeouts, not a clean "no such command".

--prereq chases the precondition. It is OC mode, and OC mode is itself refused: enable-oc returns CmdRejectedPrereq — the same status as the thing it would unlock — while disable-oc returns Ok. Refusing to enable and permitting to disable is what a locked-off capability looks like. Run as enable/retry/disable/retry so a coincidence would have shown itself.

A refusal status is still not an outcome, so the offset was applied under load and measured anyway. That required changing the metric. Raw clock and raw voltage are each useless alone: they drift with the operating point and they drift together, so a phase running warmer shows higher clock and higher voltage — the V/F curve being traversed, not shifted. The first run returned a raw clock mean of +2.0%, above threshold and a positive if clock were the measure, with voltage up +1.4% beside it. An undervolt does not raise voltage. A Curve Optimizer undervolt shifts the curve — less voltage for the same clock — so the verdict turns on V/MHz, whose spread across identical pairs is 1.2pp against raw clock's 4.1pp:

run	V/MHz mean	range	sign consistent
CO −20 (real)	−0.30%	−0.94 … +0.28	no
CO 0 (sham)	+0.25%	0.00 … +0.69	no

The real run sits inside the sham's noise. Effect size is what makes that decisive rather than merely inconclusive: 20 counts at ~4 mV is ~80 mV against a measured ~0.89 V, so a working offset moves V/MHz by roughly 9%. This is thirty times smaller and changes sign.

The instrument needed correcting before it could be trusted

RyzenAdj's PM table map for 0x005D000B is shifted by one field on this board: its "gfx power" is voltage and its "volt" is temperature. Its clock offset still lands on a clock only because three adjacent fields are clocks — the coincidence that keeps a wrong map looking right. Reading 0x4B4 as watts reports a saturated 890M pulling 41 W as 0.86 W, and nothing in the output looks wrong. The offsets used here are measured, and the header comment records the idle-vs-loaded pairs that fix them.

A side finding worth having: the PSMU query messages answer in the argument registers, so this path is not write-only. get-pbo-scalar returning 1.0f is exactly the shape of a stale buffer, so it was moved — 1.000x → 2.000x → 1.000x through the same transport — rather than trusted on a first read.

The slider the user moved was labelled L3 Cache on an AMD part

"CACHE OFFSET / L3 Cache" was hardcoded in TuningView, and on AMD that slider's value goes to the iGPU Curve Optimizer, not to a cache domain. Three labels for one number, two of them wrong on this vendor. Both label lines now bind to the view model.

---

Scope

Board-specific in origin and confined to what it touches. The lighting work is DojoPerKeyBackend, which serves OMEN MAX per-key keyboards only — HidPerKeyBackend (the 0x03F0 OMEN family), WmiBiosBackend and EcDirectBackend are untouched, and the mi_04 fallback path behaves exactly as before. The Fn-cycle card appears only where a backend reaches the MCU (0D62:54BF). The SMU changes are per-family switches, and core Curve Optimizer is untouched — that is MP1 0x4C and a separate question from the graphics curve.

Verification

Full suite: 1510/1510 passing, 0 failed, 0 build warnings (1485 OmenCoreApp.Tests + 25 OmenCore.Linux.Tests), on main merged in at 5667f3a. New coverage: DojoPerKeyBrightnessTests, KeyboardMapBrightnessTests, DeviceLightingSwatchTests, FnCyclePlanTests, DeviceLightingFnCycleTests, DynamicLightingStateTests, PerKeyPersistenceTests, PerKeyCellKeyAgreementTests, RyzenSmuTransportTests, AmdPowerLimitTests.

Two of those are load-bearing in a way worth naming:

• DojoPerKeyBrightnessTests pins the scaling — full intensity is byte-for-byte transparent across all 256 channel values (a rounding error there would tint every colour a user picks), zero is black, the scale is linear and monotonic, and the channel * intensity product never overflows the byte it is cast to. The device end cannot be tested — DojoKeyboardMcu is sealed over a raw handle and neither interface reads colour back — so the arithmetic is the last automatically checkable point.
• PerKeyCellKeyAgreementTests — the editor and the stored record compose a cell identity in two different files and agree only by convention. When two such formats drift, nothing throws: the restore matches nothing and the editor comes back at its defaults, which is indistinguishable from the save never having happened. Those tests assert the two sides equal each other rather than a hard-coded string, since asserting the string would pass just as happily if someone changed one side and updated the test to match.

Exercised on real 8D87 hardware via LightingProbe --per-key --zones FF0000 --brightness N --commit (both interfaces open, the layout resolves, the scaled colour map is accepted at each level; --brightness alone correctly reports accepted: False, which is 0x0C being refused as documented), LightingProbe --effect-brightness, the 10 Hz 0x83 state poll for the Fn cycle, the Dynamic Lighting registry A/B, and SmuProbe --igpu --scan / --prereq / --sham plus the loaded outcome runs.

Two red CI jobs, fixed here

Both were already failing on main at 5667f3a and neither comes from this branch. They are fixed in one commit here so the checks on this PR mean something.

Run Unit Tests (linux-qa.yml) has never passed - red going back at least to 2026-05-25. It ran dotnet test OmenCore.sln on ubuntu-latest, and the solution contains OmenCoreApp and OmenCoreApp.Tests, which target net8.0-windows10.0.19041.0 and cannot be restored on Linux at all: NETSDK1100, before a single test is discovered. EnableWindowsTargeting would get it past restore only to run WPF tests on a machine with no Windows, so the job now runs the one genuinely cross-platform test project - OmenCore.Linux.Tests, which main added in 64ebae0 and which nothing had pointed a job at yet. The Windows suite is already covered by build-and-test in ci.yml.

GameLibraryViewModelTests failed on the Windows runner and passes on a developer machine, which is the tell. It asserts IsScanning is true immediately after the constructor's fire-and-forget scan - which holds only while that scan is still running. With no game platforms installed, all six per-platform scanners short-circuit, the Task.WhenAll over them is already complete, the await resumes synchronously, and the whole of ScanLibraryAsync (finally block included) runs inline inside the constructor; IsScanning is back to false before it returns. The test now subscribes to ScanCompleted before constructing and accepts either outcome - still running, or already finished - since both prove a scan was started and neither is reachable if one was not.

What is not verified, and should be read before merging

• The durability of Save to keyboard. Nobody has applied a picture, pressed the button, power-cycled the machine and looked. The mechanism is established — 0x0A is documented, it is what HP's own client calls on every colour round, and the colour map is what the MCU draws autonomously — but every link in that chain comes from the decompiled client and this board's command table rather than from watching the outcome. The tooltip promises a picture that survives a power cycle, so until someone looks, that promise rests on inference.
• The Strix Halo mailbox fix is untested against hardware — there is no Strix Halo part here. The two new transport tests pin each family to its cited address set, so the next edit to that switch has to argue with a citation rather than a hunch. It is a correction derived from two independent upstream implementations agreeing, not from a measurement.
• Whether the Fn cycle list survives a power cycle. The one flash write made while probing was within a single power session, so it shows only that 0x0A does not disturb the list — not that unflashed entries come back after a cold boot. Nothing in the UI claims otherwise.

🤖 Generated with Claude Code