Hi Russell, On 04-08-2016 15:31, Russell King - ARM Linux wrote: > On Thu, Aug 04, 2016 at 02:58:00PM +0100, Jose Abreu wrote: >> Hi Russell, >> >> I am not sure if this is a bug in DRM or a bad implementation of >> dw-hdmi. I've seen at least two more drivers that do the edid >> reading at the .detect() callback: nouveau and gma500. This is >> noticeable if while sending video the edid changes like in a >> compliance environment. In the environment that I tested I was >> sending video and swapped an edid that had support for AI packets >> to another one without support and I noticed that although the >> hotplug is generated the edid was not being updated. > The path should be: > > - HPD interrupt > - drm_helper_hpd_irq_event() > - generates uevent to userspace > - output_poll_changed() called > - drm_fb_helper_hotplug_event() > - drm_fb_helper_probe_connector_modes() > - connector->fill_modes() > - drm_helper_probe_single_connector_modes() > - connector_funcs->get_modes() > > Now, if we don't have fbdev emulation, then things won't get much > fruther than output_poll_changed(), and the responsibility for > reading the EDID falls onto userspace. However, as soon as userspace > or the kernel reads the new EDID, that is when any changes in it > should become visible. > > Of course, that should occur in a timely fashion. > Hmm, I am not debugging it right now but I remember that drm_fb_helper_probe_connector_modes() was not being called at the time I set the new EDID but only after I stopped sending video (I was using modetest). Best regards, Jose Miguel Abreu _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
