<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Monitor not turning on after DisplayPort re-plug in Xorg"
href="https://bugs.freedesktop.org/show_bug.cgi?id=46711#c21">Comment # 21</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Monitor not turning on after DisplayPort re-plug in Xorg"
href="https://bugs.freedesktop.org/show_bug.cgi?id=46711">bug 46711</a>
from <span class="vcard"><a class="email" href="mailto:bugs@nenarb.net" title="Branen Salmon <bugs@nenarb.net>"> <span class="fn">Branen Salmon</span></a>
</span></b>
<pre>After some digging, the only differences I've been able to find between the
re-plug behavior under X (where the encoder sends no signal although the driver
thinks DPMS is ON), and the re-plug behavior under an fbdev (where the signal
returns after re-plug, as expected) are the following:
1. When the monitor is re-plugged and radeon_connector_hotplug is called,
connector->dpms is OFF in the fbdev case, but it's ON in the X case. This
means that radeon_connector_hotplug returns immediately when the monitor is
re-plugged under fbdev, and that the code in radeon_connector_hotplug is not
what's turning the encoder back on.
2. In the fbdev case, there are redundant calls to radeon_atom_encoder_dpms.
When unplugging, it's called six times with on=false, and when re-plugging,
it's called thrice, with on=false, on=true, and on=true. In the X case, it's
called only once per unplug/re-plug, with on=false and on=true, respectively.
3. In the fbdev case, drm_crtc_helper_set_config is called on re-plug, and it
calls some other functions, including radeon_encoder_set_active_device and
drm_crtc_helper_set_mode. (I realize that this may be a red herring, but
figure I should include it so that expert eyes may judge.)
drm_crtc_helper_set_config isn't called at all in the X case.
4. Forcing DPMS off with xset results in one call to
radeon_atom_encoder_dpms. Forcing DPMS on with xset results in one call to
radeon_atom_encoder_dpms and one (I think?) call to drm_crtc_helper_set_config.
(I'm not counting calls to encoders and connectors not connected to my monitor,
even though fbdev likes to traverse them all anytime something changes.)
It seems that drm_crtc_helper_set_config is doing something with the encoder
that radeon_connector_hotplug is not doing. This is my first time digging into
video code, so I have no idea what that might be. I'm going to take a break
from working on this for now, but will come back to it if no one else beats me
to it. :)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>