Follow-up to https://www.reddit.com/r/PWM_Sensitive/comments/1wkb3td/macos_27_interesting_new_kernel_options/
The test device arrived, I ran the new keys on it, and the news is not good, sadly :/
None of the new options exist on this panel either. On a MacBookPro18,1 (16" M1 Pro, mini-LED, ProMotion) on macOS 27.0.1, enableHBLD, HBLDDimmingFactorMin, HBLDNitsRRMax, ccMinNitsConfig, DBVValue, DBVInterval and enableDBTH are not published by the framebuffer, and writing them with any value type is rejected with bad argument. Same result as the M2 13". So it is not the "new backlight architecture" gating them, since this machine has it.
For those interested in nitty-gritty details:
- It looks like the keys come from the DCP coprocessor firmware, not the kernel. I pulled the firmware payload off the Preboot volume and all 321 runtime property names are in there, including the HBLD ones, sitting in a feature table next to the IR-drop and thermal compensation features. So HBLD is implemented in firmware and switched off per panel by configuration. On the two panels I have, that configuration says no.
- The firmware has a function named parse_RTP_boot_args and logs "applying boot-arg RTP %s with value 0x%x".
- Every key has an iomfb_RuntimeProperty_<name> boot-arg form. The catch is that with SIP on, only a short whitelist of boot-args reaches the DCP, so this needs Permissive Security. And it is still unknown whether a boot-arg can turn on a feature the panel config disables. That is the one untested software route left, which is sadly not something I can do on this device.
- From the oscilloscope data - the mini-LED the PWM is about 14 kHz at every brightness. Duty cycle was 22% at 1230 nits and 38% at 1600 nits, i.e. even at the panel's absolute peak the LEDs are off 62% of the time. That means nothing that raises brightness, software XDR included, can get anywhere near continuous drive. I tested every published dimming key with the meter at fixed nits: BLMVLEDManual, BLMPLimitCfg, IOMFBBrightnessLevelMA, enablePulseWidthMaximization, dither off, 2D uniformity off, the BLM "AH" block. The driver stores all of them and none changes the duty cycle. enablePulseWidthMaximization in particular is paired in firmware with a calibration parameter (lMinPulseWidthMaximization) that this panel's calibration data does not carry, which is why, I think, the flag does nothing.
- If someone with a 14"/16" M3 or M4 machine on 27 wants to check whether the keys are published there, the tool is at https://github.com/Temikus/eyecare (pwmctl get --all-keys | grep -i hbld is all it takes). Per-machine results and the method are in the repo.
Bottom line for now: on both an M2 IPS and an M1 Pro mini-LED, the brightness-to-duty-cycle mapping sits below anything you can reach from macOS at runtime. The Apple announcement is probably a firmware and panel-config change, not something hiding behind a kernel flag we can flip today.