[DjDeveloperr]

Problem

On M1 and M2, the DCP firmware takes the panel level as a DAC value in each swap and shows it at once, so every brightness change is a visible jump. Automatic brightness makes it obvious: GNOME moves the level a step every 0.8 s, and each step snaps. The driver's 250 ms fade covers only the firmware that presents nits (H17P, 14.7 panels) and the M4.

Fix

• Fade on DAC firmware too: a new level starts a fade from the level set last. A worker steps it every DCP_BL_FADE_STEP_MS over DCP_BL_FADE_MS.
• Presenting each step: a step rides on the compositor's next swap, or is presented on its own when no swap took it within a step.
• Still jumps: blanking, unblanking, and a display with no mode.
• No more sleep on write: a write no longer sleeps 42 ms before returning.
• Lifetime: the worker is cancelled with the other backlight work in dcp_backlight_stop().

Tested

On a J414s (M2 Pro, firmware 13.5) with GNOME automatic brightness, running Aurora Fedora 44 kernel 7.3.0-16 with this change in appledrm.ko:

• A write returns at once.
• A change from 380 to 120 ramps through about 13 levels over 250 ms, read back from actual_brightness, instead of jumping.
• After the room went dark, the drop from 500 to 153 looked smooth.

Build-tested on this branch's base 56da950: appledrm.ko with W=1, no new warnings.

🤖 Generated with Claude Code

[RyanTheTide]

Fleet17 gate (integration/aurora 2661d71, 11-06): the apple-dcp host selftests are now 83/85. panel-takeover-registration and desktop-brightness-notifications no longer compile. Their extracted host.c references dcp_dac_fade_starts and struct apple_dcp members level, fade_from and fade_work, and the fixture structs don't declare them. This is test-only drift; the hardware is fine, and fleet17 on the M2 shows the fade and 0 new warnings. Tracked as aurora-ctl t-4732, together with an asahi-m4 test-publication.py break after #455.