KMS: Blank screen after disconnect/reconnect if HDMI mode requires HDMI2.0 scrambling

[timg236]

Describe the bug
If the HDMI cable is disconnected then re-attached to the same display then the display is not restored. This only happens if the HDMI mode requires scrambling e.g. 4Kp60.

To reproduce
Add hdmi_enable_4kp60=1 to config.txt
Reboot
Use arandr to select 4Kp60
Disconnect HDMI cable
Reattach HDMI cable

Expected behaviour
Reconnecting to the same display should work. The FKMS firmware monitors the hotplug interrupt and attempts to restore HDMI scrambling if it was previously enabled. This does not happen with KMS.

Hotplugging to different display resolutions doesn't work, but that's a more difficult problem and requires interaction with userspace DRM client to pick alternate modes. However, until userspace supports this we the display driver should support the most frequent use-case which is coping with the HDMI cable being removed e.g. when moving a monitor.

Actual behaviour
Display remains blank

System
Raspberry Pi OS latest
Pi 4B 1.1
rpi-update 6edb3992f5df1ec1107f4c5e62b6d63b074f24c3

Additional context
I think this also fails with LibreElec. Raising a specific bug because this is a blocker for enabling KMS by default on Raspberry Pi OS.

[6by9]

Title says KMS. Comments reference FKMS. Could you confirm which we're talking about?

KMS has supported hotplug interrupts since #4313

Hash 6edb3992f5df1ec1107f4c5e62b6d63b074f24c3 appears not to exist in https://github.com/Hexxeh/rpi-firmware/commits/master either.

[timg236]

KMS. KMS does not restore scrambling when a 4Kp60 display is reconnected.

raspberrypi/firmware@6edb399 maps to
Hexxeh/rpi-firmware@6e61ab5

[6by9]

OK, ack.

Having unplugged, DRM is still registering the CRTC as enabled when viewed via /sys/kernel/debug/dri/1/state.
I thought the whole DRM state was destroyed automagically on hotplug, but quite possibly not.

[HiassofT]

I've hit this bug in LibreELEC as well when putting my LG 55C8 into standby and back on. See also my comment here #4371 (comment)

[popcornmix]

Ping @mripard

[mripard]

I discussed it and it indeed seems we should restore the scrambling status on reconnection. I don't really see another driver doing so at the moment, so I'll have to dig into how to do that exactly, but it's on my plate

[6by9]

Comparing to i915 on my laptop (Ubuntu 20.04 on a 5.4 kernel), it seems to trigger a whole load more stuff within the framework. Note this was at the console to ensure that X and stuff in the Window Manager didn't get involved.
connect.txt
disconnect.txt

[6by9]

Looking at vc4 logs on disconnect

[   15.328467] vc4-drm gpu: [drm:drm_client_dev_hotplug [drm]] fbdev: ret=0
[  221.977832] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.5 [drm_kms_helper]] 
[  221.978067] [drm:drm_client_modeset_probe [drm]] 
[  221.978200] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:32:HDMI-A-1]
[  221.992729] [drm:drm_connector_update_edid_property [drm]] [CONNECTOR:32:HDMI-A-1] Edid was changed.
[  221.992955] [drm:drm_connector_update_edid_property [drm]] Updating change counter to 3
...
[  222.041121] [drm:drm_mode_debug_printmodeline [drm]] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6
[  222.041351] [drm:drm_client_modeset_probe [drm]] connector 32 enabled? yes
[  222.041572] [drm:drm_client_modeset_probe [drm]] connector 40 enabled? yes
[  222.041811] [drm:drm_client_modeset_probe [drm]] Not using firmware configuration
[  222.042040] [drm:drm_client_modeset_probe [drm]] looking for cmdline mode on connector 32

So it's just been disconnected, but drm_client_modeset_probe doesn't view the connector as such.

[6by9]

With the fb emulation it appears to be an issue with reporting HPD state from vc4_hdmi_connector_detect. Extra logging added in each condition therein.

[   23.736836] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.5 [drm_kms_helper]] 
[   23.737078] [drm:drm_client_modeset_probe [drm]] 
[   23.737221] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:32:HDMI-A-1]
[   23.737874] [drm:vc4_hdmi_connector_detect [vc4]] *ERROR* HDMI-A-1 drm_probe_ddc success
[   23.737971] [drm:vc4_hdmi_connector_detect [vc4]] *ERROR* vc4_hdmi_connector_detect: connector HDMI-A-1 state is 1
[   23.752024] [drm:drm_connector_update_edid_property [drm]] [CONNECTOR:32:HDMI-A-1] Edid was changed.
[   23.752261] [drm:drm_connector_update_edid_property [drm]] Updating change counter to 2
[   23.752551] [drm:drm_mode_debug_printmodeline [drm]] Modeline "3840x2160": 60 594000 3840 4016 4104 4400 2160 2168 2178 2250 0x68 0x9

So it's gone through the drm_probe_ddc path and determined it's connected.
Remove the drm_probe_ddc call and it correctly shuts down the crtc/connector, and restores on reconnect.
Didn't we want to remove that path anyway?

Doesn't work with X. X appears to leave the CRTC/connector enabled after disconnect. That may be an issue in LXDE, so it'd be worth a quick check with x86 Raspberry Pi OS, or a Bullseye image to see if it's changed there.

[mripard]

The outcome of the discussion with Daniel about this is that we shouldn't modify anything related to the display pipe or vblank in the driver in the case where it's reconnected. Indeed, it might stall the compositor that waits for the vblank.
So we need to wait until the userspace reacts to actually do something, chances are that it's on the connect that it would react, not on disconnect.

His suggestions were either to set the link status property to indicate a bad link, or to just re-enable the scrambler again. The latter seems to work in more cases, so that's what I implemented in #4412