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
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
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 Jan 15, 2015 8:43 AM, Kirill A. Shutemov kir...@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 dvh...@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 kir...@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 kir...@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 dvh...@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 -- 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 kir...@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 dvh...@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 kir...@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 kir...@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 dvh...@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 -- 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 10:04:55AM -0800, Andrew Lutomirski wrote: On Tue, Jan 13, 2015 at 9:56 AM, Darren Hart dvh...@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 kir...@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 kir...@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 dvh...@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 -- 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 02:12:44PM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 12:30 PM, Kirill A. Shutemov kir...@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 kir...@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 dvh...@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 -- 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 dvh...@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 kir...@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 kir...@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 dvh...@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 -- 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 Mon, Jan 12, 2015 at 10:42:11AM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 10:38 AM, Darren Hart dvh...@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 -- 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 kir...@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 dvh...@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 -- 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:05:45PM -0800, Andrew Lutomirski wrote: On Mon, Jan 12, 2015 at 12:03 PM, Kirill A. Shutemov kir...@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 dvh...@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 -- 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 kir...@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 kir...@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 dvh...@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 -- 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 b...@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. -- -- 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 kir...@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 kir...@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 dvh...@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 -- 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 Mon, Jan 12, 2015 at 10:38 AM, Darren Hart dvh...@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 -- 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/
Re: [GIT PULL] platform-drivers-x86 for 3.19
On Sun, Jan 11, 2015 at 2:58 PM, Kirill A. Shutemov kir...@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 -- 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/
