[samucarre]

The J516C (16" M3 Max) uses the J516S panel, but the v14.7 brightness path (#183) only admits J514S and J516S, so the J516C has no /sys/class/backlight device.

Change. Set panel_nits on the J516C board record and admit apple,j516c. Its own 14.7 DCP image takes the same level block in the swap as the J516S (present byte +0x354, binary64 nits +0x35c, at most 500 nits), which is how the e272b67 path presented brightness on this machine.

Checked on a J516C (64 GB) since 26 October, on integration/aurora plus local patches: apple-panel-bl appears (max 500) and writing brightness changes the panel level. Builds cleanly on 30a6518 together with my three other PRs of today, which touch other files.

Not checked. Other J516C configurations; this branch alone on hardware.

🤖 Generated with Claude Code

[malik-na]

Independent source review, agreeing with the diagnosis. On a J516C /sys/class/backlight is empty: dcp_v14_board_j516c has no .panel_nits, and dcp_v14_panel_nits_admit() only accepts apple,j514s and apple,j516s. Because of that, dcp_v14_configure_backlight() returns early and the apple-panel-bl device is never registered. The firmware messages about a missing Backlight service and the compensation table are not on this path. This patch fixes both gates, and the KUnit change keeps the J514C, J613 and J615 cases as "untouched".

I have not run it on hardware yet. If another J516C owner can confirm the max brightness (500), brightness 0, display off/on and suspend/resume, that would settle it. I will report back here after a boot test on a J516C.

[samucarre]

Thanks for the review. Results from my J516C (MacBook Pro 16" M3 Max, 64 GB), which has run this patch since 24 Oct; today on integration/aurora 2f725546d6ac plus local patches (HDMI on dcpext0, #258, #261, #288, and the sleep work of #274 ported to the J516C):

• /sys/class/backlight/apple-panel-bl: max_brightness 500.
• brightness 0 → actual_brightness 0, panel dark; 500 → 500; back to 150 → 150.
• DPMS off/on of the panel (Hyprland, hyprctl dispatch dpms off|on eDP-1), three cycles: actual_brightness 0 while off and back to 150 on every power on, bl_power 0 throughout.
• s2idle and resume: the level is kept (150 → 150 after one sleep today, 450 → 450 over three 30 s rtcwake sleeps yesterday), panel back each time.

No backlight or DCP errors in the kernel log during these; the firmware's "Could not find Backlight service" and compensation-table messages still show at boot, as you said, not on this path.

Prepared with an LLM (Claude Code) and run on the hardware.

[malik-na]

Tested on a J516C (16-inch M3 Max, MacBook Pro) through Mac Lab, PR head a91ccf0 built on top of 7.2.11.

Before (stock 7.2.11-10-1): /sys/class/backlight is empty, so the display brightness keys do nothing.

With this PR:

• apple-panel-bl appears (type platform, max_brightness 500).
• With the panel on, writes of 500, 0 and 250 read back the same values in actual_brightness.
• Inside a running Hyprland session, injected F2, F2, F1 key events went through omarchy-brightness-display and moved actual_brightness from 250 to 275 (+5% steps). Turning the panel off reads 0 and turning it back on restores 275.
• No "brightness present failed" or "backlight unavailable" lines in the kernel log.
• omarchy-m-test against the stock kernel reports display.backlight as fixed.

One thing to know when testing: writes read back 0 while the lock screen had blanked the panel, so run the check with the screen on.

Not checked: actual light output (only the firmware's readback), physical key presses (events were injected), brightness 0 darkening the screen, suspend/resume.

[malik-na]

Follow-up from the same J516C (16-inch M3 Max): this has now been checked by hand, not only by injected key events.

On this PR's kernel (a91ccf0), pressing F1/F2 changes the display brightness on the real panel. Display brightness control works.

Still not covered: suspend/resume, and whether the lowest setting turns the screen fully dark.

[samucarre]

Thanks for testing it by hand. The two points still open, from my J516C:

• Lowest setting: brightness 0 (actual_brightness 0) leaves the panel fully dark, checked by eye just now; setting the previous level back restores it.
• Suspend/resume: covered in my comment above (drm/apple: v14.7: admit panel brightness on the J516C #259 (comment)): the level is kept across s2idle (150 → 150, and 450 → 450 over three 30 s rtcwake sleeps), with the panel back each time. Those runs were on integration plus local patches (the sleep work of Make M3 Pro sleep use 1.4 W instead of 2.6 W, and add the RTC wake alarm #274 ported to the J516C, among others), since suspend on T6031 needs them.

[chriskearney]

Reviewed exact head a91ccf0abdeeed7d3bd696b4c01d861a9756a0a2: the J516C board capability and machine admission reuse the existing bounded 500-nit path. Independent host controls passed 75 assertions, with an intended baseline failure and four semantic mutants caught. Public exact-head J516C evidence now includes physical F1/F2 panel changes; the author's sleep observations are on a mixed local stack and are not an exact-head suspend qualification.

No source blocker for this standalone brightness change. Normal current CI and full merge-group CI remain required. Keep #283 held: if its panel hardware-off change later lands, #284 or an equivalent per-board guard is needed so this brightness capability does not silently admit J516C A472 hardware-off behavior. No new physical or sleep test is required for this bounded standalone delta.