linux-kernel - Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to .detect() callback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Aug 2016 15:57:21 +0100
From:	Jose Abreu <Jose.Abreu@...opsys.com>
To:	Russell King - ARM Linux <linux@...linux.org.uk>,
	Jose Abreu <Jose.Abreu@...opsys.com>
CC:	<dri-devel@...ts.freedesktop.org>,
	Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
	Archit Taneja <architt@...eaurora.org>,
	David Airlie <airlied@...ux.ie>,
	Fabio Estevam <fabio.estevam@...escale.com>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Takashi Iwai <tiwai@...e.de>,
	Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
	Thierry Reding <treding@...dia.com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3 v3] drm: bridge/dw-hdmi: Move edid reading to
 .detect() callback

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