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.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
