[GIT PULL] platform-drivers-x86 for 3.19

[GIT PULL] platform-drivers-x86 for 3.19

[Darren Hart]

Hi Linus,

The following have all spent at least a week in next, most quite a bit more. The
one exception being the acerhdf Kconfig regression fix from Randy Dunlap.

In addition to the usual cleanups, quirks, and new IDs, some larger changes are
included:

thinkpad-acpi using software mute simplifies the driver and the user experience
significantly.

dell-laptop changes nearly doubles the size of the driver to support keyboard
backlight based on new device documentation. It saw several rounds of review
from me and Dan Carpenter caught a bug. I would have preferred a series of
smaller patches, but it didn't seem feasible upon inspection.

The rest are self-explanatory and summarized in the tag.

Thanks,

Darren Hart
Intel Open Source Technology Center

The following changes since commit fc14f9c1272f62c3e8d01300f52467c0d9af50f9:

  Linux 3.18-rc5 (2014-11-16 16:36:20 -0800)

are available in the git repository at:

  git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.19-1

for you to fetch changes up to 200db647112d9a0f1dce273604f949f916bd2426:

  platform/x86/acerhdf: Still depends on THERMAL (2014-12-15 09:29:58 -0800)

----------------------------------------------------------------
platform-drivers-x86 for 3.19

thinkpad-acpi: Switch to software mute, cleanups
acerhdf: Bang-bang thermal governor, new models, cleanups
dell-laptop: New keyboard backlight support and documentation
toshiba_acpi: Keyboard backlight updates, hotkey handling
dell-wmi: Keypress filtering, WMI event processing
eeepc-laptop: Multiple cleanups, improved error handling, documentation
hp_wireless: Inform the user if hp_wireless_input_setup()/add() fails
misc: Code cleanups, quirks, various new IDs

----------------------------------------------------------------
Andy Lutomirski (2):
      thinkpad-acpi: Try to use full software mute control
      acpi: Remove _OSI(Linux) for ThinkPads

Azael Avalos (4):
      toshiba_acpi: Fix regression caused by backlight extra check code
      toshiba_acpi: Move hotkey enabling code to its own function
      toshiba_acpi: Change notify funtion to handle more events
      toshiba_acpi: Add keyboard backlight mode change event

Chen Hanxiao (1):
      intel_ips: fix a comment typo

Darren Hart (1):
      Merge branch 'thinkpad-acpi' into for-next

Dominique Leuenberger (1):
      hp_accel: Add support for HP ZBook 15

Frans Klaver (7):
      eeepc-laptop: flatten control flow
      eeepc-laptop: don't break user visible strings
      eeepc-laptop: define rfkill notifier nodes only once
      eeepc-laptop: replace magic numbers with defines
      eeepc-laptop: document fan_pwm conversions
      eeepc-laptop: don't assume get_acpi succeeds
      eeepc-laptop: clean up control flow in eeepc_acpi_notify

Gabriele Mazzotta (3):
      dell-wmi: Don't report keypresses for radio state changes
      dell-wmi: Don't report keypresses on keybord illumination change
      Documentation: Add entry for dell-laptop sysfs interface

Giedrius Statkevicius (1):
      hp_wireless: Inform the user if hp_wireless_input_setup()/add() fails

Giedrius Statkevičius (1):
      drivers: platform: change 0x20 to I8042_STR_AUXDATA in i8042 filters

Hans de Goede (1):
      asus-nb-wmi: Add another wapf=4 quirk

Markus Elfring (2):
      platform: x86: Deletion of checks before backlight_device_unregister()
      Sony-laptop: Deletion of an unnecessary check before the function call "pci_dev_put"

Ondrej Zary (1):
      toshiba-acpi: Add missing ID (TOS6207)

Pali Rohár (3):
      dell-wmi: Update code for processing WMI events
      platform: x86: dell-laptop: Add support for keyboard backlight
      dell-smo8800: Add more ACPI ids and change description of driver

Peter Feuerer (5):
      acerhdf: Adding support for "manual mode"
      acerhdf: Adding support for new models
      acerhdf: Use bang-bang thermal governor
      acerhdf: added critical trip point
      acerhdf: minor clean up

Randy Dunlap (1):
      platform/x86/acerhdf: Still depends on THERMAL

 .../ABI/testing/sysfs-platform-dell-laptop         |   60 ++
 drivers/acpi/blacklist.c                           |   54 -
 drivers/platform/x86/Kconfig                       |    7 +-
 drivers/platform/x86/acerhdf.c                     |  265 +++--
 drivers/platform/x86/asus-laptop.c                 |    3 +-
 drivers/platform/x86/asus-nb-wmi.c                 |    9 +
 drivers/platform/x86/asus-wmi.c                    |    3 +-
 drivers/platform/x86/dell-laptop.c                 | 1057 +++++++++++++++++++-
 drivers/platform/x86/dell-smo8800.c                |   10 +-
 drivers/platform/x86/dell-wmi.c                    |  176 +++-
 drivers/platform/x86/eeepc-laptop.c                |  213 ++--
 drivers/platform/x86/fujitsu-laptop.c              |    6 +-
 drivers/platform/x86/hp-wireless.c                 |    3 +
 drivers/platform/x86/hp_accel.c                    |    1 +
 drivers/platform/x86/ideapad-laptop.c              |    3 +-
 drivers/platform/x86/intel_ips.c                   |    2 +-
 drivers/platform/x86/intel_oaktrail.c              |    3 +-
 drivers/platform/x86/msi-laptop.c                  |    2 +-
 drivers/platform/x86/msi-wmi.c                     |    3 +-
 drivers/platform/x86/sony-laptop.c                 |    6 +-
 drivers/platform/x86/thinkpad_acpi.c               |  116 ++-
 drivers/platform/x86/toshiba_acpi.c                |  166 +--
 22 files changed, 1767 insertions(+), 401 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop

-- 
Darren Hart
Intel Open Source Technology Center

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

[Kirill A. Shutemov]

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

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

[Andrew Lutomirski]

On Sun, Jan 11, 2015 at 2:58 PM, Kirill A. Shutemov
<kirill@shutemov.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

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

[Darren Hart]

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?

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

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

[Andrew Lutomirski]

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?

--Andy

>
> Thanks,
>
> --
> Darren Hart
> Intel Open Source Technology Center

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

[Kirill A. Shutemov]

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

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

[Andrew Lutomirski]

On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> 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.
>

What aspect of the old behavior is better than the new default behavior?

--Andy

> --
>  Kirill A. Shutemov

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

[Borislav Petkov]

On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> What aspect of the old behavior is better than the new default behavior?

Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0
thing, the small control light in the mute button doesn't light up to
show that mute is enabled. It still mutes properly in both cases though
so it is only a feedback thing which doesn't work anymore...

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

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

[Kirill A. Shutemov]

On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > 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.
> >
> 
> What aspect of the old behavior is better than the new default behavior?

It's not necessary better. The new behavior just broke my use-case.

I don't have anything in my system what would react on KEY_MUTE and I used
the functionality platform provides until it suddenly stopped working.

I personally can live with new thinkpad_acpi. I'll probably update my
configuration to react on the software button.

But who else will get frustrated after update to v3.19?

-- 
 Kirill A. Shutemov

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

[Andrew Lutomirski]

On Mon, Jan 12, 2015 at 12:26 PM, Borislav Petkov <bp@alien8.de> wrote:
> On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
>> What aspect of the old behavior is better than the new default behavior?
>
> Btw, in my case, if I boot without the thinkpad_acpi.software_mute=0
> thing, the small control light in the mute button doesn't light up to
> show that mute is enabled. It still mutes properly in both cases though
> so it is only a feedback thing which doesn't work anymore...

This is supposed to work, and it works fine on my X220.  What Thinkpad
do you have, and what distro are you running?

Can you run alsamixer (with software_mute=1) and watch the controls to
see what changes when you press mute?  IIRC, when the master volume
goes to 0 or is muted, the magic ALSA hooks will tell thinkpad_acpi so
that thinkpad_acpi can adjust the LED.

--Andy

>
> --
> Regards/Gruss,
>     Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --

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

[Andrew Lutomirski]

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
>> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>> > 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.
>> >
>>
>> What aspect of the old behavior is better than the new default behavior?
>
> It's not necessary better. The new behavior just broke my use-case.
>
> I don't have anything in my system what would react on KEY_MUTE and I used
> the functionality platform provides until it suddenly stopped working.
>
> I personally can live with new thinkpad_acpi. I'll probably update my
> configuration to react on the software button.

You'd have to do that anyway if you switched to a non-ThinkPad, for
better or for worse.

>
> But who else will get frustrated after update to v3.19?

Hopefully fewer people than got frustrated by the old, broken
behavior.  (It probably wasn't obviously broken for you, because you
didn't have software that reacted to KEY_MUTE.  But, if you did, you
might have noticed all kinds of strange behavior.)

--Andy

>
> --
>  Kirill A. Shutemov

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

[Andrew Lutomirski]

On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
<kirill@shutemov.name> wrote:
> On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
>> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>> > 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.
>> >
>>
>> What aspect of the old behavior is better than the new default behavior?
>
> It's not necessary better. The new behavior just broke my use-case.
>
> I don't have anything in my system what would react on KEY_MUTE and I used
> the functionality platform provides until it suddenly stopped working.
>
> I personally can live with new thinkpad_acpi. I'll probably update my
> configuration to react on the software button.
>
> But who else will get frustrated after update to v3.19?

Can you try the equivalent of:

bindsym XF86AudioMute exec amixer -q set Master toggle

for your desktop environment?  Note that this is exactly what you'd do
if you were using any laptop that wasn't a thinkpad.

--Andy

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

[Darren Hart]

On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote:
> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
> <kirill@shutemov.name> wrote:
> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
> >> <kirill@shutemov.name> wrote:
> >> > 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.
> >> >
> >>
> >> What aspect of the old behavior is better than the new default behavior?
> >
> > It's not necessary better. The new behavior just broke my use-case.
> >
> > I don't have anything in my system what would react on KEY_MUTE and I used
> > the functionality platform provides until it suddenly stopped working.
> >
> > I personally can live with new thinkpad_acpi. I'll probably update my
> > configuration to react on the software button.
> >
> > But who else will get frustrated after update to v3.19?
> 
> Can you try the equivalent of:
> 
> bindsym XF86AudioMute exec amixer -q set Master toggle
> 
> for your desktop environment?  Note that this is exactly what you'd do
> if you were using any laptop that wasn't a thinkpad.

Unless we hear back from Kirill on why this isn't workable, I'm inclined to
leave this as is. Between the kernel module option and this keybinding,
equivalent behavior can be easily achieved, and the general use case is
significantly improved.

The current gap appears to be the mute LED in the button itself, which can be
addressed moving forward.

-- 
Darren Hart
Intel Open Source Technology Center

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

[Andrew Lutomirski]

On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart <dvhart@infradead.org> wrote:
> On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote:
>> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
>> <kirill@shutemov.name> wrote:
>> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
>> >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
>> >> <kirill@shutemov.name> wrote:
>> >> > 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.
>> >> >
>> >>
>> >> What aspect of the old behavior is better than the new default behavior?
>> >
>> > It's not necessary better. The new behavior just broke my use-case.
>> >
>> > I don't have anything in my system what would react on KEY_MUTE and I used
>> > the functionality platform provides until it suddenly stopped working.
>> >
>> > I personally can live with new thinkpad_acpi. I'll probably update my
>> > configuration to react on the software button.
>> >
>> > But who else will get frustrated after update to v3.19?
>>
>> Can you try the equivalent of:
>>
>> bindsym XF86AudioMute exec amixer -q set Master toggle
>>
>> for your desktop environment?  Note that this is exactly what you'd do
>> if you were using any laptop that wasn't a thinkpad.
>
> Unless we hear back from Kirill on why this isn't workable, I'm inclined to
> leave this as is. Between the kernel module option and this keybinding,
> equivalent behavior can be easily achieved, and the general use case is
> significantly improved.
>
> The current gap appears to be the mute LED in the button itself, which can be
> addressed moving forward.

I should have clarified this better.  The command:

amixer -q set Master toggle

should toggle the mute LED in sync with the master mixer on all
ThinkPad models with a mute LED.  This works on my X220, and Borislav
confirmed off-list that it works on his X230.  If there's a ThinkPad
with a mute LED on which this doesn't work, then IMO it's a bug and
should be fixed.

--Andy

>
> --
> Darren Hart
> Intel Open Source Technology Center

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

[Kirill A. Shutemov]

On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote:
> On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart <dvhart@infradead.org> wrote:
> > On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote:
> >> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
> >> <kirill@shutemov.name> wrote:
> >> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> >> >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
> >> >> <kirill@shutemov.name> wrote:
> >> >> > 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.
> >> >> >
> >> >>
> >> >> What aspect of the old behavior is better than the new default behavior?
> >> >
> >> > It's not necessary better. The new behavior just broke my use-case.
> >> >
> >> > I don't have anything in my system what would react on KEY_MUTE and I used
> >> > the functionality platform provides until it suddenly stopped working.
> >> >
> >> > I personally can live with new thinkpad_acpi. I'll probably update my
> >> > configuration to react on the software button.
> >> >
> >> > But who else will get frustrated after update to v3.19?
> >>
> >> Can you try the equivalent of:
> >>
> >> bindsym XF86AudioMute exec amixer -q set Master toggle
> >>
> >> for your desktop environment?  Note that this is exactly what you'd do
> >> if you were using any laptop that wasn't a thinkpad.
> >
> > Unless we hear back from Kirill on why this isn't workable, I'm inclined to
> > leave this as is. Between the kernel module option and this keybinding,
> > equivalent behavior can be easily achieved, and the general use case is
> > significantly improved.
> >
> > The current gap appears to be the mute LED in the button itself, which can be
> > addressed moving forward.
> 
> I should have clarified this better.  The command:
> 
> amixer -q set Master toggle
> 
> should toggle the mute LED in sync with the master mixer on all
> ThinkPad models with a mute LED.  This works on my X220, and Borislav
> confirmed off-list that it works on his X230.  If there's a ThinkPad
> with a mute LED on which this doesn't work, then IMO it's a bug and
> should be fixed.

Okay. Mute and mute led works. Any idea how to get mic mute led work?
What happend to your patch on the topic?

http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/1962

-- 
 Kirill A. Shutemov

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

[Andrew Lutomirski]

On Jan 15, 2015 8:43 AM, "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
>
> On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote:
> > On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart <dvhart@infradead.org> wrote:
> > > On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote:
> > >> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
> > >> <kirill@shutemov.name> wrote:
> > >> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> > >> >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
> > >> >> <kirill@shutemov.name> wrote:
> > >> >> > 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.
> > >> >> >
> > >> >>
> > >> >> What aspect of the old behavior is better than the new default behavior?
> > >> >
> > >> > It's not necessary better. The new behavior just broke my use-case.
> > >> >
> > >> > I don't have anything in my system what would react on KEY_MUTE and I used
> > >> > the functionality platform provides until it suddenly stopped working.
> > >> >
> > >> > I personally can live with new thinkpad_acpi. I'll probably update my
> > >> > configuration to react on the software button.
> > >> >
> > >> > But who else will get frustrated after update to v3.19?
> > >>
> > >> Can you try the equivalent of:
> > >>
> > >> bindsym XF86AudioMute exec amixer -q set Master toggle
> > >>
> > >> for your desktop environment?  Note that this is exactly what you'd do
> > >> if you were using any laptop that wasn't a thinkpad.
> > >
> > > Unless we hear back from Kirill on why this isn't workable, I'm inclined to
> > > leave this as is. Between the kernel module option and this keybinding,
> > > equivalent behavior can be easily achieved, and the general use case is
> > > significantly improved.
> > >
> > > The current gap appears to be the mute LED in the button itself, which can be
> > > addressed moving forward.
> >
> > I should have clarified this better.  The command:
> >
> > amixer -q set Master toggle
> >
> > should toggle the mute LED in sync with the master mixer on all
> > ThinkPad models with a mute LED.  This works on my X220, and Borislav
> > confirmed off-list that it works on his X230.  If there's a ThinkPad
> > with a mute LED on which this doesn't work, then IMO it's a bug and
> > should be fixed.
>
> Okay. Mute and mute led works. Any idea how to get mic mute led work?
> What happend to your patch on the topic?
>
> http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/1962

It was addressed differently -- the mic mute works like the mute
button as a result of:

b317b032d2dc ALSA: hda - Split Thinkpad ACPI-related code
b67ae3f1c97e ALSA: hda - Enable Thinkpad mute/micmute LEDs for Realtek
08cf680ccafd ALSA: hda - add connection to thinkpad_acpi to control
mute/micmute LEDs

On my X220, "amixer set Capture toggle" toggles the mute LED.

--Andy

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

[Kirill A. Shutemov]

On Thu, Jan 15, 2015 at 09:00:44AM -0800, Andrew Lutomirski wrote:
> On Jan 15, 2015 8:43 AM, "Kirill A. Shutemov" <kirill@shutemov.name> wrote:
> >
> > On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote:
> > > On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart <dvhart@infradead.org> wrote:
> > > > On Mon, Jan 12, 2015 at 02:12:44PM -0800, Andrew Lutomirski wrote:
> > > >> On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov
> > > >> <kirill@shutemov.name> wrote:
> > > >> > On Mon, Jan 12, 2015 at 12:05:45PM -0800, Andrew Lutomirski wrote:
> > > >> >> On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov
> > > >> >> <kirill@shutemov.name> wrote:
> > > >> >> > 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.
> > > >> >> >
> > > >> >>
> > > >> >> What aspect of the old behavior is better than the new default behavior?
> > > >> >
> > > >> > It's not necessary better. The new behavior just broke my use-case.
> > > >> >
> > > >> > I don't have anything in my system what would react on KEY_MUTE and I used
> > > >> > the functionality platform provides until it suddenly stopped working.
> > > >> >
> > > >> > I personally can live with new thinkpad_acpi. I'll probably update my
> > > >> > configuration to react on the software button.
> > > >> >
> > > >> > But who else will get frustrated after update to v3.19?
> > > >>
> > > >> Can you try the equivalent of:
> > > >>
> > > >> bindsym XF86AudioMute exec amixer -q set Master toggle
> > > >>
> > > >> for your desktop environment?  Note that this is exactly what you'd do
> > > >> if you were using any laptop that wasn't a thinkpad.
> > > >
> > > > Unless we hear back from Kirill on why this isn't workable, I'm inclined to
> > > > leave this as is. Between the kernel module option and this keybinding,
> > > > equivalent behavior can be easily achieved, and the general use case is
> > > > significantly improved.
> > > >
> > > > The current gap appears to be the mute LED in the button itself, which can be
> > > > addressed moving forward.
> > >
> > > I should have clarified this better.  The command:
> > >
> > > amixer -q set Master toggle
> > >
> > > should toggle the mute LED in sync with the master mixer on all
> > > ThinkPad models with a mute LED.  This works on my X220, and Borislav
> > > confirmed off-list that it works on his X230.  If there's a ThinkPad
> > > with a mute LED on which this doesn't work, then IMO it's a bug and
> > > should be fixed.
> >
> > Okay. Mute and mute led works. Any idea how to get mic mute led work?
> > What happend to your patch on the topic?
> >
> > http://permalink.gmane.org/gmane.linux.drivers.platform.x86.devel/1962
> 
> It was addressed differently -- the mic mute works like the mute
> button as a result of:
> 
> b317b032d2dc ALSA: hda - Split Thinkpad ACPI-related code
> b67ae3f1c97e ALSA: hda - Enable Thinkpad mute/micmute LEDs for Realtek
> 08cf680ccafd ALSA: hda - add connection to thinkpad_acpi to control
> mute/micmute LEDs
> 
> On my X220, "amixer set Capture toggle" toggles the mute LED.

Oh. Thanks. I've tried with "Mic", not "Capture".

-- 
 Kirill A. Shutemov