[alsa-devel] HDMI codec, way forward?

[Mark Brown]

On Fri, Oct 16, 2015 at 02:31:43PM +0200, Lars-Peter Clausen wrote:
> On 10/16/2015 01:50 PM, Jyri Sarha wrote:

> > My conclusion from the Lars-Peter's latest mail [2] related to the
> > subject is that the wind is currently blowing slightly in favour of my
> > version of the hdmi codec [3], or at least not in favour of Arnaud's
> > version [4].

> > So how should we proceed? Are we still waiting for some feedback from
> > DRM/video side?

That too, though given that they have never commented on these serieses
at all as far as I remember and are generally not very vocal IME I'm
probably OK with just applying something.

> What needs to happen is that everybody who is working on HDMI audio support
> should get their heads together and come up with a common solution that
> works for everybody, rather than having everybody trying to push their own
> solution and put the maintainer in the spotlight of having to choose one
> (Mark has been asking for this for the past half year or so).

Longer, I think.  In this context things like the work that Russell has
done with the EDID handling is really great - making common code that
other people are able to adopt and use, and where I can see that there's
reasonably widespread buy in.  There was some debate about the
differences between your patch set and the very similar patch set that
Arnaud posted which was good to see but it felt like that petered out
rather than drew to a conclusion, I'd at least expect to see a new
version appear that the pair of you can hopefully agree on or some
active statement that you both support one or the other version that's
there now.

It's one thing if there's unresolvable differences that someone just
needs to take a call on but right now it just feels like it's more that 
there's a lack of engagement.  What I don't want to do is merge
something and then find a few months later that it needs big reworks
(as opposed to extensions) because it's missed some important things
that are a problem for large classes of hardware.  Having separate
approaches for completely different classes of hardware would be fine I
think but we need to understand what they are and ensure that as far as
possible the user experience outside the kernel is consistent.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20151016/f0469e68/attachment-0001.sig>