Need some kernel help...

Seth Forshee seth.forshee at
Fri Jul 8 20:24:21 UTC 2011

On Fri, Jul 08, 2011 at 03:29:21PM -0400, Scott Bambrough wrote:
> On Thu, 2011-07-07 at 08:39 -0500, Seth Forshee wrote:
> > On Wed, Jul 06, 2011 at 01:54:16PM -0600, Tim Gardner wrote:
> > > On 07/06/2011 01:45 PM, Scott Bambrough wrote:
> > > >Hi guys,
> > > >
> > > >I did an upgrade from Maverick to Natty on the weekend and ran into a
> > > >glitch with HDMI video display.  I filed the following bug if you are
> > > >interested:
> > > >
> > > >
> > > >
> > > >I think it is a kernel issue, related to bad EDID data being returned to
> > > >the DRM subsystem.  In particular I think the problem is caused by HDMI
> > > >audio being enabled.
> > 
> > Can you explain what is leading you to conclude that this is due to a
> > bad EDID and/or HDMI audio? I'm not all that knowledgable in this area,
> > but at a glance I don't see anything on the bug that indicates an
> > invalid EDID -- the kernel isn't screaming about bad checksums, and the
> > monitor data in Xorg.log looks sane.
> This post leads me to believe the problem is HDMI audio is enabled.
> See the picture in the bug.

I see. The HDMI audio problem referred to in that thread seems to have
been fixed for some time (commit 2e3d6006 merged in 2.6.37-rc1). Later
the force_audio property was added to allow the user to enable audio
regardless of what's in the EDID. So unless you somehow have this
property enabled, whether or not HDMI audio is turned on should depend
on the EDID from you monitor.

Note that force_audio is a property of the connector in the DRM
subsystem, not a command line prameter. It looks like they are set and
queried via ioctl, but I'm not sure whether there's any easy way to
check the value from userspace. You can see whether the
SDVO_AUDIO_ENABLE bit is set running intel_audio_dump (from the
intel-gpu-tools package). SDVO_AUDIO_ENABLE is bit 6 of SDVO[BC].


More information about the kernel-team mailing list