Keyboard backlight
How it tests
Two hands-on tests on every Mac with the LED. Blinks: the light goes dark, blinks a random 2 to 4 times at full (0.8 s on, 0.8 s off) and stays dark until the tester picks the count; nothing on screen follows the blinks. Keys: the tester presses the key-light keys (KEY_KBDILLUMUP/DOWN, F6 and F5 on most Macs); each press moves the LED a tenth of its range, as omarchy-brightness-keyboard does. Writes go through the kernel's LED class (approved) and the light is put back. The quick pass only notes the LED (uncertain).
How it decides
Blinks: supported for the right count (challenge); partial for a wrong count twice; failed for no LED, refused writes, or no change seen. Keys: supported when brighter and dimmer each changed the LED and the tester saw the light follow; partial when only one did; failed when neither did, or the LED moved and the light didn't. Merged: supported only when both are, failed only when both are, else partial; a skipped one gives way to the other. Not tested (live limit) without the applesmc fix or the install kernel.
How sure it is
A count the tester can't guess proves the light, and the keys prove the path Omarchy binds.
On a real Mac
- On a MacBook Air (13-inch, Mid 2012): 4 blinks counted, both keys moved the LED, merged supported.
What could mislead it
- Could pass when it shouldn'tThe keys' “the light followed” is a plain answer; the LED's read-back backs it, the blinks are the challenge.
- Could fail when it shouldn'tOn a keyboard set to F-keys first, F6 without fn moves nothing, as on Omarchy; the screen says to hold fn, but a tester who misses that answers that the keys do nothing.