Mute button on Thinkpad does never unmute, the volume notification thinks otherwise

[Tim Kosse]

Binary package hint: gnome-volume-manager

I have a Thinkpad R52. It that has three buttons to control the volume: down, up and mute. The buttons are partially implemented in hardware.

Pressing the mute button multiple times never unmutes the volume. However, the state shown by the volume notification toggles between muted and unmuted. The actual volume however stays muted.

Expected behavior: Pressing the mute button multiple times should result in either
a) the notification not toggling between muted and unmuted (leaving the audible behavior like it is now) or should
b) actually unmute the volume, not just display it unmuted

I am using Jaunty, last updated a few minutes before writing this. As far as I can remember it used to work like a) just fine in previous Ubuntu versions,

[Pedro Villavicencio (pedro)]

not a gnome-volume-manager issue.

[Ilja Pavkovic (ipavkovic)]

acpi-support removed
/etc/acpi/event/thinkpad-mute
/etc/acpi/always-mute.sh

This had a hack to support thinkpad mute behaviour:

$ cat /etc/acpi/always-mute.sh
#!/bin/sh
# on ThinkPads, the volume keys always performs mute,
# regardless of the previous state; for the moment
# we fake this by "always" unmuting and then remuting.
# Kludge/behaviour copied over from 'thinkpad-keys'
# -Paul Sladen 2007-09-13
[ -f /usr/share/acpi-support/key-constants ] || exit 0
. /usr/share/acpi-support/key-constants
acpi_fakekey $KEY_VOLUMEUP
acpi_fakekey $KEY_MUTE

[Ilja Pavkovic (ipavkovic)]

/etc/acpi/events/thinkpad-mute
/etc/acpi/always-mute.sh

were dropped on acpi-support release 0.117

[Steve Langasek (vorlon)]

This is resolved now, in that the buttons are now handled only in hardware (since we have no way to disable the hardware handling), and therefore there will not be incorrect volume notification because you (unfortunately) won't get volume notification at all.

It would of course be preferable to have this happen /with/ the notification, but as long as there's no way to disable the hardware control, it's difficult to accomodate this in the existing hal handling.

[Ilja Pavkovic (ipavkovic)]

> This is resolved now, in that the buttons are now handled only in hardware (since we have no way to disable
> the hardware handling), and therefore there will not be incorrect volume notification because you (unfortunately)
> won't get volume notification at all.
For my system (thinkpad z61m with up-to-date jaunty) I still get visual feedback on pressing volume up, - down and mute - but as described pressing mute still gives wrong feedback.

> It would of course be preferable to have this happen /with/ the notification, but as long as there's no
> way to disable the hardware control, it's difficult to accomodate this in the existing hal handling.
I am not familiar with the conceptional model of hal and acpi-support right now but I wonder why we cannot keep the workaround in /etc/acpi/always-mute.sh to mimik correct mute behaviour?

and about the state of the bug: is fixed the right resolve state for this issue? At least I would inspect something like invalid (base on your comment) :)

[Steve Langasek (vorlon)]

Ilja,

Have you rebooted since hotkey-setup 0.1-23ubuntu10 was installed on your system (first made available on April 4)? Prior to that version, the init script will at boot time cause the behavior you're seeing.

Keeping the acpi-support "always-mute" behavior has other undesirable side-effects because it makes changes to the software mixer.

And I think this bug is fixed, rather than invalid, because the behavior now is basically what's described as option a) in the bug description.

[Ilja Pavkovic (ipavkovic)]

> Have you rebooted since hotkey-setup 0.1-23ubuntu10 was installed on your system
yes. cat /proc/acpi/video/VID/DOS returns
DOS setting: <7>

> Keeping the acpi-support "always-mute" behavior has other undesirable
> side-effects because it makes changes to the software mixer.
Which side-effects do you mean?

> And I think this bug is fixed, rather than invalid, because the behavior now is
> basically what's described as option a) in the bug description.
not for me :). on my kubuntu jaunty system the following happens:

1. I press mute once, I get a visual feedback showing "0%" (a kde widget showing this value, don't ask me which one).
cat /proc/acpi/ibm/volume returns
  level: 14
  mute: on

2. I press mute again. I get a visual feedback showing "96 %"
cat /proc/acpi/ibm/volume returns
  level: 14
  mute: on

After 2. the hardware settings are not in sync with the audio controls of kde.

With the workaround found in /etc/acpi/always-mute.sh it worked before. I know that this is not the way how audio settings should be taken care about but at least it returned the expected behavior on a thinkpad laptop.

[Steve Langasek (vorlon)]

/proc/acpi/video/VID/DOS is not relevant to checking which version of hotkey-setup you have installed. Please post the contents of these two files:

 /sys/devices/platform/thinkpad_acpi/hotkey_mask
 /sys/devices/platform/thinkpad_acpi/hotkey_recommended_mask

Please also step through the instructions in <https://wiki.ubuntu.com/Hotkeys/Troubleshooting>, so that we can see for certain where the event comes from that the kubuntu widget is reacting to.

[Ilja Pavkovic (ipavkovic)]

Steve,

ok, I now know why my keys continued to work. After updating hotkey-setup my volume keys did not work anymore (see #355300). I thought this was kind of bug in jaunty and added a hotkey mask to /etc/modprobe.d/thinkpad_acpi.conf:

#pavkovic 2009.04.09: enable different hotkey mask to reenable volup, voldown mute
options thinkpad_acpi fan_control=1 hotkey=enable,0xffff8f bluetooth=disable

And as far as I understand I mimik the old hotkey-setup behaviour with this setup.

The changes done due to bug #355300 disable the volume keys at all. Perhaps you can rechange it again and add a configuration file so one can decide if he wants to have hotkeys with strange behaviour or if one wants disabled hotkeys?

For me the situation before was fine (at least the keys worked :)) and I know others are also complaining (see #357673).

[Steve Langasek (vorlon)]

On Fri, Apr 17, 2009 at 07:28:11AM -0000, Ilja Pavkovic wrote:
> ok, I now know why my keys continued to work. After updating hotkey-
> setup my volume keys did not work anymore (see #355300). I thought this
> was kind of bug in jaunty and added a hotkey mask to
> /etc/modprobe.d/thinkpad_acpi.conf:

> #pavkovic 2009.04.09: enable different hotkey mask to reenable volup, voldown mute
> options thinkpad_acpi fan_control=1 hotkey=enable,0xffff8f bluetooth=disable

> And as far as I understand I mimik the old hotkey-setup behaviour with
> this setup.

Yep, that would account for it!

> The changes done due to bug #355300 disable the volume keys at all.
> Perhaps you can rechange it again and add a configuration file so one
> can decide if he wants to have hotkeys with strange behaviour or if one
> wants disabled hotkeys?

Sorry, no. Exposing this behavior again would be a step backwards in our
efforts to clean up the architecture of hotkey handling; it's unfortunate
that both configurations are unsatisfactory, but I'm sure we're better off
keeping this consistent across all users' systems so that there's less
confusion as we make further fixes down the line.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

[Ilja Pavkovic (ipavkovic)]

> Sorry, no. Exposing this behavior again would be a step backwards in our
> efforts to clean up the architecture of hotkey handling; it's unfortunate
> that both configurations are unsatisfactory, but I'm sure we're better off
> keeping this consistent across all users' systems so that there's less
> confusion as we make further fixes down the line
I see your point from an architectural point of view - less choices are less error prone. From a users' point of view it is not satisfying to loose functionality as result of a code cleanup (even if this functionality is somehow broken or misbehaving).

Will the thinkpad hotkeys be reactivated in the future?

[Steve Langasek (vorlon)]

"reactivating" the hotkeys (i.e., making them available to userspace applications) would depend on being able to disable the hardware-level handling of those keys, which we currently have no way to do. At some point in the future, yes, we will hopefully be able to integrate these better.

[Ilja Pavkovic (ipavkovic)]

> "reactivating" the hotkeys (i.e., making them available to userspace applications)
> would depend on being able to disable the hardware-level handling of those keys,
> which we currently have no way to do. At some point in the future, yes, we will
> hopefully be able to integrate these better.
This part is IMHO not acceptable for thinkpad owners: You disabled functionally working
buttons. Only with a poor vision how to reactivate them in the future. I honestly have no clue why.

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

please I test mute button as hotkey and, it's given me nothing, up and down return something

[Thiago Teixeira (tvst)]

@Ilja: Agreed

@Everyone: How would one go back to the old behavior? What files should be modified?

[Pavol Klačanský (pavolzetor-deactivatedaccount)]

you can use workaround with boot kernel parameter acpi_osi="Linux"