Re: Splitting out controls

[Mark Brown <broonie@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1829 bytes --]

On Fri, Oct 16, 2015 at 04:24:02PM +0100, Richard Fitzgerald wrote:
> On Fri, 2015-10-16 at 09:49 -0500, Pierre-Louis Bossart wrote:

> > Bottom line we have to move to profiles, stop guessing values based on 
> > control names or avoid letting users poke random values in alsamixer. 
> > This just doesn't scale any more. thinking that the alsamixer 
> > command-line remains the default user-facing interface moving forward is 
> > just not right, it's a developer tool.

> I believe that you are misunderstanding David's point. Yes, there can be
> a large number of controls (the Wolfson WM8280 has over 400 controls,
> some Cirrus Logic codecs have nearly 900). The point was not whether the
> users should understand the meaning of all these controls but that they
> should be able to "play around and see what happens" without any risk of
> bricking their hardware. Regardless of whether what they are doing is
> meaningful or whether it's really feasible to set hundreds of controls
> correctly from the command line, they shouldn't damage the hardware. Not
> even root should have the ability to actually damage the hardware.

No, the point here is that it's unrealistically difficult to prevent
hardware damage on all systems without substantial work - even at the
simple level of constraining the maximum gain through the system we
currently lack the information to do that (never mind the capacity to do
the calculations), and getting the limits into the kernel would involve
carrying the machine specific callibration data around since it's not in
the firmwares of the relevant systems.

We can't even think about the possibility of doing this without getting
the controls into the topology and once we can do that we would need to
work out what we're trying to protect against and how.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]