[alsa-devel] Splitting out controls

[Pierre-Louis Bossart]

On 10/13/15 10:56 AM, David Henningsson wrote:
>
>
> On 2015-10-13 16:55, Pierre-Louis Bossart wrote:
>> On 10/13/15 2:07 AM, David Henningsson wrote:
>>>
>>>
>>> On 2015-10-12 22:59, James Cameron wrote:
>>>> On Mon, Oct 12, 2015 at 02:49:46PM +0100, Liam Girdwood wrote:
>>>>> I've written up the minutes here below
>>>>
>>>> Thanks!
>>>>
>>>>> Splitting out controls: Takashi
>>>>> ===============================
>>>>>
>>>>>   - Restricted access.  Consensus to restrict access to some controls
>
> Note: There is NOT consensus.
>
>>>>> due
>>>>> to possibility of breaking HW at kernel level. i.e. prevent feeding
>>>>> digital Mic into HP amp to prevent speaker over heating.
>>>>
>>>> I'd like that.  rt5631.  Avoiding at the moment by removing the
>>>> controls.
>>>
>>> IIRC, the debate was over "do not expose dangerous controls to userspace
>>> at all" vs "expose dangerous controls controls only to root".
>>>
>>> I'm strongly voting for "do not expose to userspace at all".
>>>
>>> I personally believe that if the physical hardware can be set to state
>>> where it's bricked, the hardware itself is buggy.
>>>
>>> If the hardware is buggy, this should be worked around in BIOS or
>>> whatever firmware is present on the machine. Otherwise there is a bug in
>>> BIOS.
>>>
>>> If BIOS is buggy and cannot protect the machine from being physically
>>> damaged, then we need to work around that in the kernel. Otherwise there
>>> is a bug in the kernel.
>>>
>>> And if the kernel is buggy, we should fix the kernel. Period. :-)
>>
>> There are just too many variables linked to acoustic, mechanical and
>> thermal design that just can't be handled with a simple rule at the
>> kernel level or even BIOS/firmware. There were quite a few people in the
>> room who voiced their opinion that handling 'dangerous' controls was an
>> exercise for the integrator, not something that can be handled with a
>> one-size-fits-all fix.
>
> If userspace can make complex decisions to avoid damage, then so can the
> kernel. The integrator can just write that logic into the kernel instead
> of writing it into userspace.

That seems to go against everything we've done over the last few years.
And it's not even feasible to put kernel-level safeguards with the new 
topology tool, since the kcontrols are instantiated at run time based on 
a firmware description.

>> 'userspace' is also a vague definition, most
>> audio servers will use profiles that will avoid using bad
>> configurations. It's not clear to me that we have to protect against a
>> user setting random values with alsamixer.
>
> Whether the devices are phones, laptops, or everything in between,
> people are replacing their original software with other software. Surely
> those people are messing around with mixer controls, and surely they
> don't want their devices damaged.
>
> These people might replace the kernel as well, of course, but are less
> likely to do so than to replace userspace; and if they do, they are less
> likely to mess around with a particular audio driver, especially if that
> driver has a big warning sign saying "changing this value might fry your
> speaker" (which, IMO, would be appropriate).

It's a valid case but I would argue that if you install new software you 
should use profiles that have been shared or used by others. If you want 
to protect against the limited knowledge of an individual user 'messing 
around mixer controls' then this is going too far.