From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Andrew Lutomirski <luto@mit.edu>
Cc: Darren Hart <dvhart@infradead.org>,
Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] platform-drivers-x86 for 3.19
Date: Mon, 12 Jan 2015 22:03:31 +0200 [thread overview]
Message-ID: <20150112200331.GA23277@node.dhcp.inet.fi> (raw)
In-Reply-To: <CAObL_7FCiZJuTQNUfqjoxaRscB+_2fvwpnXDt3d8E+0dFm=i6A@mail.gmail.com>
On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote:
> On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Mon, Jan 12, 2015 at 12:58:02AM +0200, Kirill A. Shutemov 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?
> >>
> >> --
> >> Kirill A. Shutemov
> >>
> >
> > Thanks for the report Kirill,
> >
> > Andy, we're at RC4, so if we need to fix (or revert) this fix, we only have a
> > couple weeks to do so.
> >
> > Kirill, to define the scope of the problem, if you specify
> > software_mute_requested as false on the kernel command line, does your system
> > function as expected?
>
> If I understood Kirill's email correctly, the only issue is that he
> liked the old behavior. Kirill, is that correct?
Yes. For now I use thinkpad_acpi.software_mute=0 to get old behaviour.
--
Kirill A. Shutemov
next prev parent reply other threads:[~2015-01-12 20:04 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-18 17:51 Darren Hart
2015-01-11 22:58 ` Kirill A. Shutemov
2015-01-12 0:36 ` Andrew Lutomirski
2015-01-12 18:38 ` Darren Hart
2015-01-12 18:42 ` Andrew Lutomirski
2015-01-12 20:03 ` Kirill A. Shutemov [this message]
2015-01-12 20:05 ` Andrew Lutomirski
2015-01-12 20:26 ` Borislav Petkov
2015-01-12 20:31 ` Andrew Lutomirski
2015-01-12 20:30 ` Kirill A. Shutemov
2015-01-12 20:32 ` Andrew Lutomirski
2015-01-12 22:12 ` Andrew Lutomirski
2015-01-13 17:56 ` Darren Hart
2015-01-13 18:04 ` Andrew Lutomirski
2015-01-15 16:40 ` Kirill A. Shutemov
2015-01-15 17:00 ` Andrew Lutomirski
2015-01-15 17:07 ` Kirill A. Shutemov
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=20150112200331.GA23277@node.dhcp.inet.fi \
--to=kirill@shutemov.name \
--cc=dvhart@infradead.org \
--cc=hmh@hmh.eng.br \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@mit.edu \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome