Monitors not lighting up DRM problems

[YaLTeR]

Monitors not lighting up DRM problems

[cmeissl]

I can some sort of reproduce this in anvil (and niri) and identified multiple issues. Some of them are non
critical, like resetting planes, but need to be fixed anyway.

But the by far worst issue I was able to reproduce is Case 2, in which case anvil will also panic.
After a bit of back and forth this seems to only happen with multiple monitor connected like reported.
Which kind of makes sense, because this seems to only fail when we try to switch connectors, which can/should
only happen with multiple outputs.

So, what happens is that by calling reset_state after a session resume
we will read out the current connectors. When calling queue_frame we will end in commit which detects some change in the connectors and then tries to disable the current connector and enable the pending connector.
And this is what will fail and print out Atomic Test failed for new properties on crtc.

[ids1024]

I discovered an issue I've seen with this for Nvidia outputs on a dual GPU laptop is due to the VRAM being full. Still not sure what's causing that: pop-os/cosmic-comp#243

Though it's probably unrelated to the issue you're seeing with AMD.

[cmeissl]

The provided drm log also points in the same direction, something is going horrible wrong with the connectors

[88233.574515] amdgpu 0000:03:00.0: [drm:drm_atomic_check_only] checking 000000009b718254
[88233.574519] amdgpu 0000:03:00.0: [drm:drm_atomic_helper_check_modeset] [CRTC:95:crtc-1] mode changed
[88233.574524] amdgpu 0000:03:00.0: [drm:drm_atomic_helper_check_modeset] [CRTC:99:crtc-2] enabled/connectors mismatch

[cmeissl]

The same happens on my intel only laptop, when anvil selects a different crtc then currently active on the tty the next switch back from a different tty will fail. So it seems we have two issues here, or at least one issue and a question.

• Why does it succeed to do the initial crct switch, but fail after a tty switch
• Why is the used crtc non deterministic (or why does it sometimes differ from the crct the tty uses)

[cmeissl]

Okay, I believe to have found the reason why this fails...
We try to update the outputs one by one, this won't work because we can not activate a CRTC while it is still bound to a different connector.

[cmeissl]

The same happens on my intel only laptop, when anvil selects a different crtc then currently active on the tty the next switch back from a different tty will fail. So it seems we have two issues here, or at least one issue and a question.

* Why does it succeed to do the initial crct switch, but fail after a tty switch

* Why is the used crtc non deterministic (or why does it sometimes differ from the crct the tty uses)

The reason why it initially succeeds is the same why #1295 should solve it, we reset all CRTCs

[cmeissl]

Might also explain why turning off and on can help. This should reset the state for one connector, potentially allowing the other to proceed. Might get a bit more tricky with more than two connected connectors.

Side note: turning off might not always result in udev/kernel recognizing that something is no longer connected. But the next turning on can result in fast disconnect followed by a direct connected. This might leave only a short time slot for the other crtc to proceed.