[GIT PULL] platform-drivers-x86 for 3.19-2
Hi Linus, The support for the dell-laptop keyboard backlight was flawed and the fix: https://lkml.org/lkml/2015/1/14/539 was more invasive that I felt comfortable sending at RC5. This series reverts the support for the dell-laptop keyboard backlight as well as the documentation for the newly created sysfs attributes. We'll get this implemented correctly for 3.20. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit ec6f34e5b552fb0a52e6aae1a5afbbb1605cc6cc: Linux 3.19-rc5 (2015-01-18 18:02:20 +1200) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.19-2 for you to fetch changes up to b78695a71de994cdbd58f4b3be9085a60bd2203d: Revert "platform: x86: dell-laptop: Add support for keyboard backlight" (2015-01-23 11:10:32 -0800) platform-drivers-x86 for 3.19-2 dell-laptop: Revert keyboard backlight sysfs support and documentation Darren Hart (2): Revert "Documentation: Add entry for dell-laptop sysfs interface" Revert "platform: x86: dell-laptop: Add support for keyboard backlight" .../ABI/testing/sysfs-platform-dell-laptop | 60 -- drivers/platform/x86/dell-laptop.c | 1055 +--- 2 files changed, 6 insertions(+), 1109 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-platform-dell-laptop -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Thu, Jan 15, 2015 at 09:00:44AM -0800, Andrew Lutomirski wrote: > On Jan 15, 2015 8:43 AM, "Kirill A. Shutemov" 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 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 > > > >> 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 > > > >> >> 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 > > > >> >> >> 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 thi
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Jan 15, 2015 8:43 AM, "Kirill A. Shutemov" 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 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 > > >> 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 > > >> >> 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 > > >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please rea
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Tue, Jan 13, 2015 at 10:04:55AM -0800, Andrew Lutomirski wrote: > On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart 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 > >> 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 > >> >> 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 > >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart 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 >> 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 >> >> 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 >> >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
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 > 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 > >> 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 > >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov 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 >> 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 >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov 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 >> 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 >> >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:26 PM, Borislav Petkov 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. > -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
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 > 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
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. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov 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 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: > On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Sun, Jan 11, 2015 at 2:58 PM, 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? 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] platform-drivers-x86 for 3.19
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] platform-drivers-x86 for 3.19
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
