Skip to content

drm/apple: Switch desktop 26.x external displays to VRR without a DRM mode set - #776

Merged
RyanTheTide merged 1 commit into
aurora-wipfrom
j616s/ext-vrr
Nov 1, 2026
Merged

RyanTheTide merged 1 commit into
aurora-wipfrom
j616s/ext-vrr

Conversation

@RyanTheTide

Copy link
Copy Markdown
Contributor

GNOME never turned on variable refresh for a fullscreen game on the J616s external displays. mutter flips VRR_ENABLED in a plain page flip. The external processors turned that into a mode set, so the flip failed with EINVAL ("Page flip failed: drmModeAtomicCommit: Invalid argument").

The panel takes a new adaptive-sync minimum on a live mode (#763). The external processors don't. On an MSI MPG 325CQRXF, a live minimum of 280, 279 or 240 Hz all left the idle desktop at its 48 Hz floor. macOS switches such a display between fixed and variable refresh by reselecting the same timing and colour IDs, with the adaptive-sync parameter set just before the mode set.

Fix. Accept the VRR_ENABLED change in atomic check. When it changes on a live VRR timing of an external processor, reselect the mode once from the commit's flush. As before, the mode set installs adaptive sync at the timing's minimum when VRR_ENABLED is set, and fixed refresh when it isn't. A compositor that only turns VRR on for fullscreen clients gets one reselect each time such a client starts or ends.

How tested. J616s (T6041, DCP 26.6.2), on the fleet14b kernel with this change loaded as a test appledrm, docked with an MSI MPG 325CQRXF (48-280 Hz) on dcpext.

  • Plain (non-ALLOW_MODESET) commits flipping VRR_ENABLED at a 77 fps flip cadence, VRR off 6 s, on 10 s, then off 6 s:
    • On: the firmware logs "IOMFBParameter_adaptive_sync Req minRR = 0x300000" and "mode_set_gated 2560x1440@280 Hz DSC=YES VRR=YES".
    • Off: it logs "minRR = 0x0" and "mode_set_gated ... VRR=NO".
    • No failed commits.
  • The idle GNOME desktop stays fixed at 280 Hz with VRR_ENABLED=0. That's mutter's desktop default with the +vrr mode selected.
  • Host selftests (tools/testing/selftests/drivers/gpu/apple-dcp/run.py): 84/84. vrr-rejection now checks that a VRR_ENABLED change is never a DRM mode set on desktop 26.6.
  • arm64 LLVM W=1 build of drivers/gpu/drm/apple: no warnings.

🤖 Generated with Claude Code

… mode set

GNOME never turned on variable refresh for a fullscreen game on the
J616s external displays: mutter flips VRR_ENABLED in a plain page flip,
and the external processors made that a mode set, so the flip failed
with EINVAL. Their firmware takes adaptive sync only with a mode set: a
new minimum rate on a live mode is ignored (an MSI MPG 325CQRXF stayed
at its 48 Hz floor with 280, 279 or 240 Hz), and macOS too reselects the
same timing to switch such a display between fixed and variable refresh.

Accept the VRR_ENABLED change in atomic check and, when it changes on a
live VRR timing, reselect the mode from the commit's flush, once. The
mode set installs adaptive sync at the timing's minimum when VRR_ENABLED
is set and fixed refresh otherwise, as before. A compositor that toggles
VRR only for fullscreen clients sees one reselect each time one starts
or ends.

Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
@RyanTheTide
RyanTheTide merged commit c14ccc9 into aurora-wip Nov 1, 2026
@RyanTheTide
RyanTheTide deleted the j616s/ext-vrr branch November 1, 2026 06:30
mchalunderscore pushed a commit to mchalunderscore/linux that referenced this pull request Nov 4, 2026
…tion/aurora

Bring integration/aurora up to aurora-wip b359258, the source of
7.3.0-aurora-fleet14f, promoted on the M1 Pro, M2, Neo and J616s on
2026-11-01 and 11-02. The range also covers the fleet14c, fleet14d and
fleet14e sources (f41ac3d, 4759557, 757fc07), each booted on
hardware. It adds aurora-silicon#773, aurora-silicon#776, aurora-silicon#777, aurora-silicon#737, aurora-silicon#713, aurora-silicon#785, aurora-silicon#786, aurora-silicon#788,
aurora-silicon#789 and aurora-silicon#787. No conflicts.

Assisted-by: LLM
Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant