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
