drm: apple: Adaptive Sync/ProMotion

[chadmed]

Tested:

• Adaptive Sync over DisplayPort (Dell S2721DGF, [48, 165] Hz)
• Apple ProMotion on 14" and 16" MacBook Pros (tested [24, 120] Hz)

Not tested:

• Adaptive Sync over HDMI (I have no HDMI 2.x displays)

What works:

• "Modesetting" in and out of Adaptive Sync
• mpv... mostly
• Games running via Proton via Steam via FEX via muvm
• Native AArch64 games
• Forcing Adaptive Sync on and sitting at the desktop at minimum refresh rate

What doesn't

• Firefox will always render at the display's refresh rate
• On the internal MBP displays only, mpv's gpu and gpu-next outputs leak file descriptors and halt the GPU when in fullscreen. Other backends work fine, other applications work fine, gpu and gpu-next work fine when not in fullscreen...

What needs work

• The VRR timestamps are best guesses only. We know they are always within a few frames of each other, meaning that they are likely something to do with swap submission and presentation time, but what exactly remains unclear.
• Wrapping set_digital_out_mode in a dcpep callback seems kind of silly? There's probably a smarter way to do this.

[jannau]

How did you verify this does anything at all on MacBook Pro internal displays? I would expect that this does nothing without EDID with adaptive sync data.

[jannau]

This should also work if compositor allows modesets with enabling vrr without the module parameter set. I expected here something like

if (!force_vrr && dcp->vrr_enabled != crtc_state->vrr_enabled) {
    dcp->vrr_enabled = crtc_state->vrr_enabled;
}

if (mode->vrr) {
    if (force_vrr || dcp->vrr_enabled)
        dcp_set_adaptive_sync(dcp, mode->min_vrr, cookie);
    else
        dcp_set_adaptive_sync(dcp, 0, cookie);
} else {
    		dcp_set_digital_out_mode(dcp, false, &dcp->mode,
					 complete_set_digital_out_mode, cookie);
}

[chadmed]

I don't see the point in accommodating for this when it is explicitly forbidden and unexpected as of right now. Exposing the connector property while we require a modeset also causes Kwin to get confused. It never actually enables VRR but it says it has, which I can foresee resulting in questions from users. I'd rather just hide all of this from userspace for now and pretend it doesn't exist until a decision has been made upstream.