`DrmDevice::new` with disable_connectors = true causes vrr_capable property to get stuck at 0

[YaLTeR]

Still unclear if this is an AMDGPU issue or Smithay issue or what. I have a Lenovo Legion 7 Gen 7 AMD with FreeSync Premium that is supposed to work on the internal display. The vrr_capable property is 1 on:

• TTY
• sway (1.8.1 with 0.17.1 wlroots, and latest upstream with latest upstream wlroots)
• mutter
• Smithay if the DrmDevice is created with disable_connectors = false

However, if a Smithay DrmDevice is created with disable_connectors = true, then the vrr_capable property for the internal display connector resets to 0 and never comes back to 1. This situation remains consistent across VT switches back and forth, and also if starting sway with eDP disabled and enabling afterwards.

I also have a HDMI screen plugged in which always has vrr_capable = 1, and another DP screen which always has vrr_capable = 0. It's just the internal laptop panel on eDP which has this problem.

drm_info of sway and niri, the only difference seems to be the vrr_capable property value on the internal connector:

• niri-drm-not_vrr_capable.log
• sway-drm-vrr_capable.log
• also TTY for good measure: tty.log

DRM debug dmesg of starting niri with disable_connectors = false (vrr_capable = 1) and disable_connectors = true (vrr_capable = 0):

• dmesg-reset-vrr0.log.gz
• dmesg-vrr1.log.gz

The EDID from /sys/class/drm/ is the same between vrr_capable 0 and 1 starts.

Fedora 39, kernel-6.7.9-200.fc39.x86_64, mesa-dri-drivers-23.3.6-1.fc39.x86_64

[YaLTeR]

Just noticed that sleep-resume while niri is running switches the vrr_capable property to 1. And a subsequent VT switch back and forth brings the property back to 0 (I guess due to the call to reset_state()).

[YaLTeR]

It's also possible to switch VRR on in sway and switch VT back to niri, which results in a combination of vrr_capable = 0 and VRR_ENABLED = 1. Unfortunately, on this laptop screen it doesn't seem to do anything (and neither it does in sway).

[YaLTeR]

Some new developments (Fedora 40, kernel-6.8.4-300, mesa-dri-drivers-24.0.4-1):

• when vrr_capable is bugged to 0, setting VRR_ENABLED on that connector succeeds but does nothing (same as setting VRR_ENABLED on a connector that is normally not vrr_capable)
• unplugging an unrelated monitor causes vrr_capable to unbug and become 1, then setting VRR_ENABLED will work and enable VRR
• when vrr_capable is bugged to 0 and VRR_ENABLED is at 1 left over from another TTY, setting VRR_ENABLED to 0 does not succeed. It remains at 1 which sometimes does nothing and sometimes enables VRR on a different monitor? Not sure.