18:15colo: my wife's desktop (based on an ASRock X300 barebone with a Radeon 5600G APU) fails to initialize/activate its display if the monitor attached via DP is not yet powered during bootup. is there anything I can do on the Linux side of things to force initializing the DisplayPort output?
18:17Remco: Does replugging it work?
18:18Remco: If so, I can image a software reset working
18:21colo: Remco: hmm, I did not try that (I did turn the monitor off and on again, in best IT Crowd tradition)
18:22colo: it's come to life after the reboot and she's working with the system now, but if you tell me about the workaround, I will try the next time I get a chance ;)
18:22colo: https://paste.debian.net/plain/1357184 - amdgpu-related dmesg diff between the two bootups, if that helps
18:24agd5f: colo, when the monitor is off, the driver can't detect it so it can't light it up. If turning it on doesn't generate an HPD event, the driver has no way to know that anything has changed.
18:25colo: "DisplayPort Hot Plug Detect (HPD)"? is that something a monitor would do on its own?
18:28Venemo: agd5f: how would we verify whether such an event was generated or not? I've seen a similar issue on Navi 21 recently
18:29agd5f: driver should get an HPD interrupt of the monitor sends one
18:29agd5f: *if
18:31agd5f: there may be some DC debugging level which would print something in that case. hwentlan_ ?
18:50Venemo: basically what I saw is, if I turn off my monitors for the night, but leave the computer running, then come back in the morning and turn on the monitors, there is no output
18:50Venemo: interestingly, doing a sleep+resume fixes that
19:26agd5f: Venemo, doing a plug and unplug would probably also fix it. When you turn on/off the monitor nothing happens so the driver has no way of knowing that anything has changed so that it can light up the displays again
19:32colo: agd5f: so... the actual cable that's plugged in the GPU's DP port (and on that side of the connection?) needs to be re-plugged to trigger that kind of event?
19:32agd5f: colo, yes
19:33agd5f: when the hpd pin on the monitor connects with the hpd pin on the GPU the GPU can see that something is connected
19:33Venemo: so, how does a sleep resume cycle fix it?
19:34colo: agd5f: thanks, I will try that next time
19:34agd5f: on resume, the driver sends userspace a hotplug event in case any monitors where plugged or unplugged while it was suspended. The compositor sees the hotplug event and asks the kernel to light up the monitors
19:36Venemo: how does the driver know how to send those if it isn't aware which monitors are connected?
19:37agd5f: it always sends a hotplug event on resume
19:39agd5f: compositor can then check what displays are now present and decide what to do
19:40colo: and one cannot trigger such an event manually somehow, emulating the on-resome behavior?
19:40colo: (I do understand correctly that this event is send ant understood bi-directionally, right?)
19:40agd5f: you can ask your compositor to probe the displays again. Usually opening the monitors app will do it
19:40colo: and*
19:41agd5f: there are two multiple sets of communications. The compositor (ultimately the user) decides what to do with the monitor that are available.
19:42agd5f: When the compositor starts asks the driver what is connected and then asks then asks the driver to light up whatever displays the user wants
19:43agd5f: If you plug in a new monitor or unplug an old monitor, the driver will get an interrupt because the HPD pin will get pulled low or high. At that point it sends an event to the compositor
19:43agd5f: the compositor asks the driver what monitors are connected and then decides what it wants to light up
19:44colo: the compositor does that by means of an ioctl syscall? is there some smallish CLI tool that performs a similar/the same action that I could poke via ssh? (I don;t have any display output at all in the case I described)
19:44agd5f: yeah
19:45agd5f: if you have the monitor turned of via the button on the monitor, in most cases, the GPU will see that a monitor is attached because the HPD pin is pulled up, but, when it tries to talk to the monitor, it gets no response because the monitor is off.
19:46agd5f: so it can't light up the display.
19:46agd5f: when you turn the monitor on, you need to somehow tell the driver that it can communicate with the monitor so that it can actually light it up or at least send an event to the compositor
19:48agd5f: on some monitors when you turn them on via the button, they will pulse the HPD pin which will generate an interrupt on the GPU. some don't do anything
19:48colo: the monitor has two inputs (one USB-C with DP, one DP) and is supposed to "auto-detect" (I'd guess by means of HPD! :)) which one is supposed to be active... I will have to experiment a bit if the behavior we observe is only exercised when the USB-C port was in use right before, or something like that.
19:49colo: thanks very much for taking the time to explain what is happening in such great detail!
19:49agd5f: right. the monitor will look at the HPD pins as well to see if any of them are pulled up (i.e., connected to a GPU), The monitors use that for input detection
19:50agd5f: sometimes toggling the input on the monitor will also generate an HPD pulse
19:54Venemo: agd5f: silly question, but could the driver periodically send those events to deal with the eventuality that colo and me are describing?
19:58agd5f: Venemo, I think it would be cleaner if the compositor did that. Would also fix a number of other problematic cases
20:11soreau: mareko: tarceri: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12707
20:14agd5f: e.g., if compositor has asked the driver to put the displays into DPMS off state and then the user moves the mouse or touches the keyboard, the compositor could ask the driver what's attached before it asks the driver to take the displays out of DPMS off state