From: David Henningsson <david.henningsson@canonical.com>
To: Matthew Garrett <matthew.garrett@nebula.com>
Cc: Alex Hung <alex.hung@canonical.com>,
Tim Chen <tim.chen119@canonical.com>,
"ibm-acpi@hmh.eng.br" <ibm-acpi@hmh.eng.br>,
"ibm-acpi-devel@lists.sourceforge.net"
<ibm-acpi-devel@lists.sourceforge.net>,
"platform-driver-x86@vger.kernel.org"
<platform-driver-x86@vger.kernel.org>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
YK <yk@canonical.com>
Subject: Re: [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute
Date: Wed, 14 Aug 2013 22:36:34 +0200 [thread overview]
Message-ID: <520BEA52.5030705@canonical.com> (raw)
In-Reply-To: <1376510744.28002.6.camel@x230.lan>
On 08/14/2013 10:05 PM, Matthew Garrett wrote:
> On Wed, 2013-08-14 at 21:53 +0200, David Henningsson wrote:
>> On 08/14/2013 04:57 PM, Matthew Garrett wrote:
>>> On Wed, 2013-08-14 at 11:27 +0200, David Henningsson wrote:
>>>
>>>> The privacy issue is interesting, but I don't see a practical way of
>>>> implementing things that would protect us against compromised userspaces.
>>>
>>> That's pretty easy - just tie the LED control to the HDA device in-kernel.
>>>
>>
>> Well, my point was that the compromised userspace could still record
>> from other possibly connected microphones (such as USB or bluetooth
>> headsets).
>
> Ok, true. It'd need to be at a higher level than HDA to make this
> consistent. But in theory, this is something that could be tied to the
> full set of input sources.
In theory perhaps, but in practice, I doubt it. USB audio perhaps,
because that's at least ALSA. Bluetooth uses its own stack (it's not
even ALSA), and I'm not sure how much of that stack is in the kernel.
And then we haven't considered other oddities such as FFADO, network
connected devices and what not...but perhaps we could leave those out?
>> But I guess one compromise could be to refuse userspace turn the mic
>> mute LED on, if the internal mic is unmuted.
>> Userspace would still be able to turn the mic mute LED off, to indicate
>> that recording can happen from other sources. It will be slightly more
>> complex for userspace though.
>
> Like I said, I don't think there's any reason for this to be in
> userspace. If it's only going to represent the internal device, that's
> trivial. If it's going to represent the global state of audio devices,
> that's more complicated but doable. The only policy aspect is "What if I
> want it to track the state of the currently selected audio device",
> which just doesn't seem like a useful thing for it to do.
I say it's the *most* useful thing for it to do.
Imagine you're a non-technical user, who has never heard the words
"compromised userspace". You connect your headset where it fits (or
cordless), and then select the headset in sound settings (if it didn't
get selected for you when you plugged it in). You're on a VOIP call and
press the mic mute hotkey. Which mic did you expect to mute? The
selected one. On the mic mute hotkey button, there is also a LED. You
expect it to lit, because you muted the mic that you currently care
about, i e, the selected one.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
next prev parent reply other threads:[~2013-08-14 20:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-14 5:40 [PATCH 0/2] add sysfs for acpi interfaces of thinkpad hardware mute Alex Hung
2013-08-14 5:40 ` [PATCH 1/2] thinkpad-acpi: add sysfs for getting and setting " Alex Hung
2013-08-14 5:40 ` [PATCH 2/2] thinkpad-acpi: add sysfs for enabling and disabling " Alex Hung
[not found] ` <1376458802-11923-1-git-send-email-alex.hung-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
2013-08-14 5:42 ` [PATCH 0/2] add sysfs for acpi interfaces of thinkpad " Matthew Garrett
2013-08-14 5:53 ` Alex Hung
2013-08-14 5:54 ` Matthew Garrett
2013-08-14 6:11 ` Alex Hung
2013-08-14 6:14 ` Matthew Garrett
2013-08-14 6:41 ` Alex Hung
2013-08-14 7:00 ` Matthew Garrett
2013-08-14 7:08 ` Alex Hung
[not found] ` <CAJ=jqubWWeWH+xsGrTVaNguNuw7gm2E=CZmXY_SxO+Bxg1Hxag-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-14 23:30 ` Henrique de Moraes Holschuh
2013-08-14 7:16 ` Alex Hung
2013-08-14 7:43 ` David Henningsson
2013-08-14 7:51 ` Matthew Garrett
2013-08-14 9:27 ` David Henningsson
2013-08-14 14:57 ` Matthew Garrett
2013-08-14 19:53 ` David Henningsson
2013-08-14 20:05 ` Matthew Garrett
2013-08-14 20:36 ` David Henningsson [this message]
2013-08-14 20:38 ` Matthew Garrett
2013-08-14 20:59 ` David Henningsson
2013-08-14 21:15 ` Matthew Garrett
2013-08-15 14:55 ` David Henningsson
2013-08-15 14:24 ` [alsa-devel] " Arun Raghavan
[not found] ` <CAJ=jqub1sRSzBRv_R6soDVAydRL+5nmA9-pMC4E+sgXhP6tbPw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-14 6:15 ` Alex Hung
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520BEA52.5030705@canonical.com \
--to=david.henningsson@canonical.com \
--cc=alex.hung@canonical.com \
--cc=alsa-devel@alsa-project.org \
--cc=ibm-acpi-devel@lists.sourceforge.net \
--cc=ibm-acpi@hmh.eng.br \
--cc=matthew.garrett@nebula.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=tim.chen119@canonical.com \
--cc=yk@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.