[ericjuta]

Problem

On the 15-inch M3 MacBook Air (apple,j615, apple,t8122) the 14.7 DCP session runs, but no backlight device is ever registered: /sys/class/backlight is empty, so brightnessctl and omarchy brightness display cannot control the panel.

dcp_v14_board_j615 has no .panel_nits = true, and dcp_v14_panel_nits_admit() only allows j514s, j516s, j516c and j613. #312 (eec6458360) enabled the J613 and left the J615 out only because it was untested.

Change

Same as #312, but for the J615:

• dcp_v14_board_j615: .panel_nits = true
• dcp_v14_panel_nits_admit(): add apple,j615
• KUnit: v14_bl_boards now expects the J615 to be admitted; added a v14_bl_j615_swap_levels case; the J615 is out of v14_bl_other_boards_untouched (the J514C is still in it)

The J615 record already uses the J613 DCP image (DCP_V14_J613_FIRMWARE_UUID), and the J615 device tree panel node has apple,max-brightness (500). The firmware UUID and handoff checks are unchanged.

Machine and build

• MacBook Air (15-inch, M3, 2024): apple,j615 / apple,t8122
• os-fw-version 14.7, system-fw-version 27.0
• Omarchy, linux-aurora 7.2.11.aurora14-1 (4fdd0fc), m1n1-aurora 1.6.1.aurora22-1, Hyprland 0.57.1
• Local test build: only appledrm.ko, built from 4fdd0fc with this patch and installed via updates/

Results

• Without the patch (aurora14): fail. No apple-panel-bl; the DCP logs IOMFB: Could not find Backlight service; /sys/class/backlight is empty.
• Module builds against the aurora14 headers: pass (vermagic/depends match the packaged module).
• KUnit: not run locally (CONFIG_KUNIT is off in the packaged kernel). The changed test file adds no compiler diagnostics.
• Boot with the patched module: pass. apple-panel-bl registers; levels 150/325/375/500 nits are applied; brightness changes visibly; brightness keys work (results in the comment below).

[ericjuta]

Hardware results on the J615 (MacBook Air 15-inch, M3; os-fw 14.7, system-fw 27.0), booting aurora14 with only appledrm.ko rebuilt from 4fdd0fc plus this patch:

• apple-panel-bl is registered at boot, max_brightness 500 (DT apple,max-brightness): pass
• brightnessctl 30% / 100% / 75% → actual_brightness 150 / 500 / 375: pass
• omarchy brightness display 10%- → 325: pass
• Panel brightness changes visibly, brightness keys work (confirmed in person): pass
• No DCP refusals or display errors in the kernel log after the changes
• KUnit: not run (CONFIG_KUNIT is off in the packaged kernel)

[mmonari]

Independent test of the same change on a second J615, on a different system firmware from the results above.

Machine and build

• MacBook Air (15-inch, M3, 2024): apple,j615 / apple,t8122
• os-fw-version 14.7, system-fw-version 26.6.2, DCP firmware UUID 90F849E1-B422-367E-B389-50246F8DEC47
• Omarchy, linux-aurora 7.2.11.aurora14-1, m1n1-aurora 1.6.1.aurora22-1, Hyprland 0.57.1
• Local build: only appledrm.ko, from 4fdd0fc with the same two-line driver change (without the KUnit changes), built with clang 23.1.4 against the aurora14 headers (the packaged kernel uses clang 18.1.8)

Results

• Without the patch: fail. /sys/class/backlight is empty.
• apple-panel-bl registers at boot, max_brightness 500: pass
• Brightness keys change the panel visibly (confirmed in person): pass
• Firmware accepted the changes; the log shows 140, 310, 75 and 60 nits:

  UPPipeDCP_H13P.cpp:2564: brightness_changed: brightness value: 20316160
  nifiedPipeline.cpp:5519: send_brightness: dbv: 32557, unit: 0, value: 20316160
  

• actual_brightness matched the requested level (60): pass
• No flip failed, DEVICE LOST, oops or kernel warnings in that boot's log: pass
• Suspend/resume: not tested
• KUnit: not run

Testing and this comment were done with Claude Code at my request; the in-person result is mine.

[scottjones]

Thanks for this, and for the hardware results from two J615s. The driver change is right, but one KUnit case now fails, so this needs a one-line test fix before it lands.

The KUnit suite fails at the PR head. v14_bl_other_boards_untouched (drivers/gpu/drm/apple/iomfb_v14_7_backlight_test.c:357) still lists &dcp_v14_board_j615 in its boards[] array. The PR updates the comment above it but not the array. v14_bl_fixture() sets v14->panel_nits from board->panel_nits, so J615 now runs the nits path, and the case's "untouched" expectations fail:

# v14_bl_other_boards_untouched: EXPECTATION FAILED at .../iomfb_v14_7_backlight_test.c:367
Expected iomfb_v14_7_panel_nits(f.dcp) to be false, but is true
... (also :368, :369, :370, :373, :375, :384)
not ok 8 v14_bl_other_boards_untouched
not ok 1 dcp_v14_backlight

The fix is the same edit #312 made for J613:

	const struct dcp_v14_board *boards[] = {
		&dcp_v14_board_j514c,
	};

With that one change, dcp_v14_backlight and dcp_v14_backlight_lifetime both pass.

What we checked:

• We ran the dcp_v14_backlight* suites on an arm64 KUnit kernel under QEMU with KVM (kunit.py build --arch=arm64 LLVM=1, with DRM_APPLE, DRM_APPLE_KUNIT_TEST and DRM_APPLE_DISPLAY_KUNIT_TEST). integration/aurora passes. The PR head fails as shown above. The PR plus the fix passes.
• The new tests do catch the change. With the fix applied, removing .panel_nits from the J615 record fails v14_bl_boards and v14_bl_j615_swap_levels. Removing apple,j615 from dcp_v14_panel_nits_admit() fails v14_bl_boards.
• The driver change is the same as #312's J613 change. #312's debugfs line is already in the tree. The J615 record uses DCP_V14_J613_FIRMWARE_UUID and the same handoff, so the swap uses the same level block (+0x354/+0x35c) as on J613. t8122-j615.dts sets apple,max-brightness = <500>, so the cap is min(500, 500) = 500, which matches the reported max_brightness of 500.
• No other board changes. Only the J615 record and the J615 admit entry are new. The J613, J514C, J516C and T6030 records are unchanged, and the J514C is still covered by the untouched case. The 25G83 (v26) J615 path doesn't use these records.
• Boot behaviour is the same as on J613. No level is sent until userspace sets one; until then the device reports the default as its requested level. There are no fades, and the Type-C and external gates apply as they do on J613.

Main Kernel CI hasn't run on this PR (the fork run is waiting for maintainer approval), so the KUnit failure hasn't shown up there yet.

[ericjuta]

Thanks @scottjones. Pushed the fix: v14_bl_other_boards_untouched now lists only &dcp_v14_board_j514c, the same as #312 for J613.

KUnit at the new head, arm64 under QEMU/KVM (kunit.py run --arch=arm64 LLVM=1, DRM_APPLE + DRM_APPLE_KUNIT_TEST + DRM_APPLE_DISPLAY_KUNIT_TEST, filter dcp_v14_backlight*):

dcp_v14_backlight (14 subtests) ............ PASSED
dcp_v14_backlight_lifetime (7 subtests) .... PASSED
Testing complete. Ran 21 tests: passed: 21

(AI-assisted; run by me.)

[scottjones]

Thanks, 01166df is exactly the fix. CI ran on it and two jobs failed:

• ci / commits: 01166df has no Signed-off-by: trailer, which this repo requires on every commit. git commit --amend -s on that commit (or squashing it into the first one with a sign-off) and a force-push should clear it.
• ci / host tests (aurora-sep): test_m3_max.SurveyTest.test_ctrl_c_stops_the_load failed (0 != 130). That's an M3 Max survey tool test, unrelated to this change, so we're not asking you to do anything about it.

KUnit, package and boot were skipped because of those two, so we'll approve once a run with the sign-off comes back green.

[ericjuta]

Rebased onto current integration/aurora (bed544bdf93a); the conflicts were with the J504 and J516M brightness admissions (#429 and the J504 panel commits).

Resolution: J615 is added to dcp_v14_panel_nits_admit() alongside J504 and J516M. In v14_bl_boards the two expectations that J615 is not admitted are dropped, since J615 was the machine used there as the unadmitted example; the J504 expectations are kept as they were.

dcp_v14_backlight and dcp_v14_backlight_lifetime KUnit suites pass on the rebased head (21/21, arm64 QEMU). Not re-booted on J615 at this exact head; the same two-line change has been running on this machine in local combined builds with working panel brightness.

Rebased with Claude Code.

[scottjones]

Thanks for the rebase! The second commit (16c9e16) is missing a Signed-off-by, so could you add one, or squash it into the first commit, whichever you prefer? I've started the full kernel CI build for this head and it's running now. If it's easy, one boot on a J615 at the new head to confirm brightness still works would be great, since the earlier hardware passes were on the pre-rebase head. Once those are in I'll approve.

[stevederico]

Another J615 seeing this on the current packaged kernel, in case a third data point on a different system firmware is useful.

Machine and build

• MacBook Air (15-inch, M3, 2024): apple,j615 / apple,t8122
• os-fw-version 14.7, system-fw-version 15.6, DCP firmware UUID 90F849E1-B422-367E-B389-50246F8DEC47
• Omarchy, stock linux-aurora 7.2.11.aurora16-1, m1n1-aurora 1.6.1.aurora23-2, Hyprland 0.57.2

Results (unpatched aurora16)

• /sys/class/backlight is empty; no apple-panel-bl: fail
• DCP logs IOMFB: Could not find Backlight service at boot
• The panel node has apple,max-brightness, compatible apple,panel-j615
• brightnessctl -l lists only kbd_backlight and the keyboard LEDs; brightness keys do nothing, and the panel stays at the level it booted with
• The eDP connector has no brightness property (modetest -M apple -c)

I have not built or booted the patch, so this only confirms the problem on aurora16, not the fix.