Hi Russell,
On 04-08-2016 16:04, Russell King - ARM Linux wrote:
> On Thu, Aug 04, 2016 at 03:57:21PM +0100, Jose Abreu wrote:
>> 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).
> Please investigate - I'd prefer that your patch does not get applied
> until we really know what's going on here.
>
> Hmm, if you're using modetest, then userspace is setting a mode, and
> userspace is in control of the DRM device - that's probably the reason
> why you're not seeing anything happening - modetest probably doesn't
> know anything about hotplug events, and so doesn't read the modes.
>
> Have you tried with the framebuffer console and DRM fbdev emulation
> enabled, without using modetest?
>
So, I didn't use framebuffer console but used X instead and it is
working as it should. I think we can drop this patch. I am now
making interoperability with DVI and I am facing the following
scenario:
- I start the driver
- An EDID is sent which tells the driver that HDMI is NOT
supported;
- The driver configures itself to a DVI mode;
Until this point everything is working as it should. But:
- Now I send an EDID which tells the driver that HDMI is
supported;
- As the EDID has the same preferred mode the user will not
reconfigure the mode and there will be no change to HDMI mode.
The missing change to HDMI mode will cause the test to fail. The
workaround that I am using is to reconfigure to another video
mode and then configure to the preferred one but I think this
could be fixed in the driver, right?
Best regards,
Jose Miguel Abreu
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
