linux-kernel - Re: [GIT PULL] platform-drivers-x86 for 3.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAObL_7GDCn22+r+zAdH=hCt3or2vk5S=CR8oRqpu1y30r54hTA@mail.gmail.com>
Date:	Sun, 11 Jan 2015 16:36:00 -0800
From:	Andrew Lutomirski <luto@....edu>
To:	"Kirill A. Shutemov" <kirill@...temov.name>
Cc:	Darren Hart <dvhart@...radead.org>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 3.19

On Sun, Jan 11, 2015 at 2:58 PM, Kirill A. Shutemov
<kirill@...temov.name> wrote:
> On Thu, Dec 18, 2014 at 09:51:27AM -0800, Darren Hart wrote:
>> thinkpad-acpi using software mute simplifies the driver and the user experience
>> significantly.
>
> Except when it doesn't.
>
> I'm probably in minority, but I don't use fancy userspace to mess with my
> mixer and the mute button worked just fine for me before the change.
> Wasted half an hour to find out what happened is not a pure win from user
> experience point of view.
>
> Is it really necessary to have software_mute_requested == true by default?
> Can fancy userspace ask for desired behaviour instead and change kernel to
> not send hotkeys change notification until software_mute is enabled?

The problem is that fancy userspace (which isn't really very fancy,
nor does it need to be new) expects KEY_MUTE to be a normal keypress.
It turns out to be a normal keypress on every single computer in
existence AFAICT except ThinkPads.  As a result, any remotely portable
user program that handled volume hotkeys got confused on ThinkPads.

I think the real solution is to have some little daemon that handles
KEY_MUTE and changes the ALSA state if that's the behavior you want.
Having the EC change the sound output *without* changing the ALSA
state or even giving a notification (the pre-3.19 behavior) really
doesn't seem like a sensible default to me.

(It may be that on newer pre-3.19 kernels, it wasn't quite as bad as
it was on much older kernels, since the ALSA hack that tries to
control the mute LED seems to feed back into the EC control of the
hardware mute switch, so at least the light would stay in sync with
everything.)

--Andy

>
> --
>  Kirill A. Shutemov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/