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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
