anyone can help on this issue? Thanks.

any update on this issue?

Please add drm.debug=14 module parameter, reboot and reproduce the problem, attach dmesg all the way from boot to the problem.

Created attachment 116357 [details]
dmesg

Hi Jani,

Please see the attachment.

Thanks,
Libin

(In reply to Jani Nikula from comment #3)
> Please add drm.debug=14 module parameter, reboot and reproduce the problem,
> attach dmesg all the way from boot to the problem.

All the way from early boot please. Add log_buf_len=4M or similar as needed.

Created attachment 116387 [details]
full dmesg

Hi Jani,

It this one dmesg.xinit.2 OK?

Thanks,
Libin

any update on it?

Test on the latest kernel, but the same result as before.

I'm told to test the attached patch. But I failed applying the patch manually. Seems some functions are missed. Anyone can help on the patch rebasing?

Created attachment 116839 [details] [review]
test patch

Please be noted that this issue only happens after run xinit. In text mode, it is OK.

The log is slightly cut short. Do you do a modeset after the hotplug? I can only see the hotplug, nothing more. You can't do audio over the DP/HDMI before you have done the modeset and have the link set up. Currently we don't notify the audio driver before you have done the modeset and you can actually enable audio.

(In reply to Jani Nikula from comment #13)
> The log is slightly cut short. Do you do a modeset after the hotplug? I can
> only see the hotplug, nothing more. You can't do audio over the DP/HDMI
> before you have done the modeset and have the link set up. Currently we
> don't notify the audio driver before you have done the modeset and you can
> actually enable audio.

HiJani,

Is it X that should trigger the modeset?

And should x always trigger the modeset after a hot-plug in even if the monitor EDID and resolution don't change?
I guess i915 or DRM driver keeps the orignal EDID and resolution.


Thanks!

(In reply to Mengdong Lin from comment #14)
> Is it X that should trigger the modeset?

Yes. The kernel sends a hotplug uevent the userspace listens to. Please verify that you get the uevent by running 'udevadm monitor' and plugging/unplugging.

> And should x always trigger the modeset after a hot-plug in even if the
> monitor EDID and resolution don't change?

Yes. We don't cache that information, so they are lost on unplug. We don't know if the display is the same or not.

> I guess i915 or DRM driver keeps the orignal EDID and resolution.

No, we don't.

The issue you're probably seeing is that hotplug/hotunplug itself does not set/invalidate the ELD, and therefore does not notify the audio driver. The notification to audio driver happens as part of the modeset sequence, triggered by userspace.

If your userspace does get the hotplug uevent, but does not trigger the modeset, the problem is in your userspace.

If your userspace does not get the uevent, or the subsequent modeset sequence triggered by userspace does not notify the audio driver, the problem is in the kernel display driver.

Hi Jani,

I have run 'udevadm monitor' and do the unplugging/plugging, it shows:
KERNEL[63094.561103] change    /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [63094.563084] change    /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
KERNEL[63104.350107] change    /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
UDEV  [63104.351986] change    /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)

So it means the userspace got the event. This is the userspace issue, right?

What the right action flow after the hotplug?

You need a display manager that responds to hotplug notifications.

Hi Jani,

(In reply to Jani Nikula from comment #17)
> You need a display manager that responds to hotplug notifications.

Do you mean such as gdm?

So this means it is a userspace issue, the gfx driver team will not debug this issue, right?

Could you give some info about what the right action flow after the hotplug?
Such as when hotplug, it will call what function in kernel to notify the userspace, how userspace trigger the modeset.

Thanks,
Libin

The stance we have taken is that userspace is in charge of handling notifications to topology changes - for a couple of reasons, this moves the policy from the kernel to the user, and the other is that it should allow for fast reconnection (often also desirable, but impossible if the kernel acts).

You actually need to run "udevadm monitor --property --tag-match=HOTPLUG" to see if the hotplug event is indeed the uevent being sent. Equally a small X client listening to RR notifications to confirm that they are being received and propagated (X needs to be built with udev support for example). And finally, but not last of all you need a client to respond to the RR notifications and issue a new modeset (and that depends upon your window/desktop/session manager).

As a last resort, an xrandr --auto, should issue the modeset required to confirm that ELD notifications are being sent following a modeset following a hotplug.

Hi Chris,

Thanks for the details.

My test result is:

root@younglee-001:~# udevadm monitor --property --tag-match=HOTPLUG
monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent

KERNEL[70.693213] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=2984
SUBSYSTEM=drm

KERNEL[83.786766] change   /devices/pci0000:00/0000:00:02.0/drm/card0 (drm)
ACTION=change
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:02.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
MAJOR=226
MINOR=0
SEQNUM=2985
SUBSYSTEM=drm

And after I run the xrandr --auto, the audio driver can detect the hotplug and the eld info is updated.

So this is userspace issue and the kernel is OK, right? Thanks for your help.

Regards,
Libin