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.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
