From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Splitting out controls Date: Fri, 16 Oct 2015 17:28:46 +0200 Message-ID: References: <1444657786.2528.78.camel@loki> <20151012205908.GA25971@us.netrek.org> <561CADA8.3040903@canonical.com> <561D1B7D.9080307@linux.intel.com> <561D2997.1090401@canonical.com> <561D2C88.5050505@linux.intel.com> <56209C2A.1010602@canonical.com> <56210E75.70501@linux.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 5DEE02606F4 for ; Fri, 16 Oct 2015 17:28:48 +0200 (CEST) In-Reply-To: <56210E75.70501@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Pierre-Louis Bossart Cc: alsa-devel@alsa-project.org, James Cameron , David Henningsson List-Id: alsa-devel@alsa-project.org On Fri, 16 Oct 2015 16:49:25 +0200, Pierre-Louis Bossart wrote: > > > We actively enable and advocate that people with limited knowledge can > > 'mess around mixer controls'. That's why we have an alsamixer > > application in the first place, and teach people how to use it. > > What you are describing is the traditional approach where the number of > controls is limited, a couple of switches here and a set of volume > controls there. > With new devices having mixers all over the place, be it in codecs or > DSPs, it's not uncommon to have several hundred controls. There is no > way users will be able to find out on their own what values they should > use and it would be misleading to think developers are able to identify > all lethal combinations of settings. We've also moved all these control > settings from kernel to userspace to avoid hardcoding values that are > platform specific. Right, and this is the problem. The system integration information isn't the thing a typical user would need to handle. OK, we can leave them in user space. It's more flexible, yes. But it's a bad design if a *normal* user is allowed and needs to handle all these. A normal user needs (and is allowed) only limited presets; your car won't allow you accessing hundreds of knobs, e.g. a child on a rear seat suddenly triggers the turbo-jump button in combination with a back-fire while driving on a highway :) > 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. Well, it doesn't matter whether it's alsamixer or whatever program. The point is that *any* user program might screw up things easily, even if it's not intentional. For Android, it wasn't a big issue, so far, just because only few people touch the audio setup manually. But now the former embedded things get more migrated to the desktop scenes, and it's pretty normal that a user just runs normal PA and ALSA apps with it nowadays like PC. It'll get more and more in the next years. So, yes, we have profiles to manage the setups in user-space. This is very good, scalable, per se. The problem is, however, rather how to harden this management. I still think that the driver can give the first-level filter or permission isolation. It should be doable also in topology f/w, in theory. Then, we can think of more hardening in user-space side on top of it. For example, running sound (or UCM) daemon with a privileged user, and let it alone managing the sensitive sound setup while a normal user is allowed to adjust only limited presets given by the profile. Just my $0.02, currently floating on my fuzzy head in bed. Takashi