[diwic] hdmi audio disabled in the radeon driver by default? investigate why?
seth.forshee at canonical.com
Fri Feb 10 16:15:42 UTC 2012
On Fri, Feb 10, 2012 at 08:51:22AM +0100, David Henningsson wrote:
> According to this blueprint , I'm supposed to figure out why hdmi
> audio was disabled in the Radeon driver.
> This is more of a video driver issue; so I suggest you reassign it
> to a video driver person for more in-depth information. But in
> short, enabling hdmi audio broke video output somehow for some
> people. What I do not know is if this video breakage was actually a
> regression, showing up as a result of changes in the video driver,
> or if it was this way ever since HDMI audio was added to the driver.
> Meta-bug is 864735. Dri-devel announcement here .
According to  the blank screen problem was fixed by the following
patch, which has already come down to precise via stable.
Author: Rafał Miłecki <zajec5 at gmail.com>
Date: Fri Dec 23 20:32:18 2011 +0100
drm/radeon/kms: workaround invalid AVI infoframe checksum issue
But in other cases it does not, see .
It is difficult to tell whether this is a regression, as none of the
bugs point to a "good" kernel version for comparison.
David, do you know whether this depends on the type of device attached
to the HDMI? I'm using a Mac Mini with what appears to be an affected
Radeon GPU. I have a monitor connected to the HDMI via an HDMI to DVI
adapter, so obviously no audio, but I can try flipping the radeon.audio
flag to see if I start seeing issues.
But overall it seems that we have two options, each of which breaks
things for some people but also has a workaround. Right now we have HDMI
audio disabled, and the workaround to enable it is to set
radeon.audio=1. On the other side we could make radeon.audio=1 the
default, and those who see problems can flip it to 0. People who want
HDMI audio but get corrupted video when it's enabled are out of luck
either way until the bug is fixed.
Seems to me the logical thing to do is to select the default that works
for the largest number of users, and instruct the rest to use the
appropriate workaround (probably it should be included in the release
notes). Do we have enough information to determine which default breaks
the least number of systems?
More information about the kernel-team