According to this blueprint [1], 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 [2].

--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

[1]
https://blueprints.launchpad.net/ubuntu/+spec/hardware-p-kernel-delta-review


[2] http://lists.freedesktop.org/archives/dri-devel/2011-June/011792.html

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Fri, Feb 10, 2012 at 08:51:22AM +0100, David Henningsson wrote:
> According to this blueprint [1], 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 [2].

According to [1] the blank screen problem was fixed by the following
patch, which has already come down to precise via stable.

commit d21e9677f82d619967c6c918038343fe12bb0f4a
Author: Rafał Miłecki <zajec5@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 [2].

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?

Seth

[1] https://bugs.freedesktop.org/show_bug.cgi?id=27731
[2] https://bugs.freedesktop.org/show_bug.cgi?id=35970

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On 02/10/2012 05:15 PM, Seth Forshee wrote:

On Fri, Feb 10, 2012 at 08:51:22AM +0100, David Henningsson wrote:

According to this blueprint [1], 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 [2].


According to [1] the blank screen problem was fixed by the following
patch, which has already come down to precise via stable.

commit d21e9677f82d619967c6c918038343fe12bb0f4a
Author: Rafał Miłecki<zajec5@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 [2].

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 don't know. Are we sure it's only the HDMI outputs that are affected
by this? In some cases you can also send audio out through DVI (which
can only be heard through a DVI->HDMI adapter).



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.


I have a Radeon card here as well that I could try with, as well as some
HDMI audio hardware.



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?


Not quite. We have 14 users marking as being affected by bug 864735, but
how many of those that would see video issues if they turned
radeon.audio, we don't know.


I think the rationale is that video output is more important than audio
output, and therefore worth sacrificing for overall video stability.



--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

On Fri, Feb 10, 2012 at 05:29:54PM +0100, David Henningsson wrote:
> >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?
>
> Not quite. We have 14 users marking as being affected by bug 864735,
> but how many of those that would see video issues if they turned
> radeon.audio, we don't know.
>
> I think the rationale is that video output is more important than
> audio output, and therefore worth sacrificing for overall video
> stability.

Yeah, I suppose there's some sense to that argument. It's easeir to
apply a workaround when your video works

I guess if we're fairly certain there are still systems whose video is
corrupted with HDMI audio enabled, the most sensible thing to do is
probably to put the workaround to enable audio in the release notes.

Seth

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team