-next queue and EDID stuff

[Adam Jackson]

On 8/29/12 3:53 PM, Ian Pilcher wrote:

> Thinking a bit more about this, I'm starting to rethink my assertion
> that the Intel driver is at fault here.  On one hand, it doesn't make
> any sense to send audio InfoFrames to a non-HDMI display.  (BTW, I'm
> assuming that a display with a DisplayPort port will show up as HDMI.)

Nope.

If you connect to the DP port on a monitor, it will claim to be DP: the 
EDID block version will be 1.4, and the digital display feature byte 
will indicate that it's DP:

http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n1145

If you connect to the HDMI port on a monitor, it will claim to be HDMI: 
the EDID block version will be 1.3 or higher, there will be a CEA 
extension block, and there will be a vendor-specific data block within 
that extension with a vendor OUI matching that of the HDMI consortium:

http://cgit.freedesktop.org/xorg/app/edid-decode/tree/edid-decode.c#n640

> On the other hand, it can be argued that the DRM layer is giving
> conflicting information to the driver -- drm_detect_hdmi_monitor is
> returning FALSE, but drm_detect_monitor_audio is returning TRUE.  AFAIK,
> this doesn't make any sense either.

This might be the actual issue.  drm_detect_monitor_audio() can return 
true for several reasons, but it does _not_ make any claim that the 
monitor is HDMI, only that it has a CEA extension block.  Which is 
certainly ugly, but that's how CEA defined their botch of an extension 
block.

So to me, that says that drivers need to ask _both_ whether the monitor 
supports audio and whether it's HDMI before sending HDMI-specific audio 
signalling.

- ajax