From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Jackson Subject: Re: -next queue and EDID stuff Date: Wed, 29 Aug 2012 17:38:42 -0400 Message-ID: <503E8BE2.4010606@redhat.com> References: <503BD762.6070204@redhat.com> <503D553C.9000503@gmail.com> <503D5EB9.2040405@redhat.com> <503D9810.60104@gmail.com> <20120829075616.GA5278@phenom.ffwll.local> <503E731F.2020303@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by gabe.freedesktop.org (Postfix) with ESMTP id 2DEE59F64E for ; Wed, 29 Aug 2012 14:38:48 -0700 (PDT) In-Reply-To: <503E731F.2020303@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Ian Pilcher Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org 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