[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180615233628.gy2ffgupctheyqof@khazad-dum.debian.net>
Date: Fri, 15 Jun 2018 20:36:28 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Pali Rohár <pali.rohar@...il.com>
Cc: Pavel Machek <pavel@....cz>,
Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
ibm-acpi-devel@...ts.sourceforge.net,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ThinkPad T480s & LED_MUTE, LED_MICMUTE
On Fri, 15 Jun 2018, Pali Rohár wrote:
> This means that kernel should not export any led class device. Or when
> exported, then "set" operation should always fail.
"not export" is right.
> > 2. Otherwise implement it in-kernel, so that userspace cannot unmute
> > when the human has activated the "mute" switch, and the LED cannot be
> > controlled by userspace to lie (report mute when it is not mute).
>
> This looks like a good candidate to use led "trigger" interface. Create
> a mute trigger and attach it to that led device.
Maybe, as long as done in-kernel and not possible to mess with from
userspace.
> means set. What is SHDA doing, I have not figured out. It does not
Look at the HDA mixer state, SHDA is likely to be directly messing with
it.
--
Henrique Holschuh
Powered by blists - more mailing lists