Comment # 21
on bug 46711
from Branen Salmon
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. :)
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
