ibm-acpi volume control unpredictable

[Thomas Augustsson]

The issue is described in this thred, http://ubuntuforums.org/showthread.php?t=150187

[yper (yper)]

I confirm this as a bug

[Thomas Augustsson (auth)]

Since hotkey-setup makes the volume buttons on thinkpads act as any other volume up/down/mute button it affects alsamixer if gnome-keybinding-properties has default values for volume up/down/mute.

[Thomas Augustsson (auth)]

My suggestion would be to either remove the bindings for volume up/down/mute in hotkey-setup on thinkpads or to remove the buttons connect to the underlying hardware? volume control device. I guess the latter would be the best solution since it would integrate into gnomes present volume control nicely.

[Martin Emrich (emme)]

Hello!

I also have a weird behaviour on my Thinkpad T41p: When I press the "volume-up" button, the _software_ volume goes down, and vice versa, while the IBM hardware mixer does it in the right direction, effectively making the two mixers work in opposite directions.

On the suggestion above: I disagree, as the internal thinkpad master volume controls (having nothing to do with the sound card's mixer here) are only accessible through the IBM hotkeys, I would leave them bound to the hardware, and remove the bindings to the soundcard's mixer (which can still be controlled via the mixer applet, just as on computers with no special keys at all).

[Paul Sladen (sladen)]

Martin: you have a different issue; which is that your keys aren't doing what you expect them? Can you post the output from running:

  lshal -m

when pressing the Up, Down and Mute volume keys and stick that in a new bug report along with information about whether you're using Kubuntu or Ubuntu. Many Thanks,

[Martin Emrich (emme)]

Hi!

output of lshal -m
:
martin@gwaihir:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
pressing down
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
pressing up
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
pressing mute
computer_logicaldev_input condition ButtonPressed = mute
pressing down
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
computer_logicaldev_input condition ButtonPressed = volumedown
pressing up
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup
computer_logicaldev_input condition ButtonPressed = volumeup

So, actually, this bug's title fits ("unpredictable"), as at one point, the down button first generated a volumeup event.

Ciao

Martin

[Martin Emrich (emme)]

Oops, I forgot: I use "both Kubuntu and Ubuntu", Dapper Drake development branch (my Desktop environment is GNOME, but I installed KDE, too, and use kontact as my pim...)

Ciao

Martin

[Paul Sladen (sladen)]

Martin: Okay, I think what you're highlighting is this:

  Mute => hardware mute-set regardless
  VolumeDown/VolumeUp => Unmute

and this is [almost] the same as 'gnome-settings-daemon', which takes the first movement (Up or Down) after a mute as also meaning Unmute; however it differs in that a Mute event while muted makes 'g-s-d' Unmute aswell.

So; if the hardware mute is already active, then the VolumeUp is sent, immediately followed by Mute in order to maintain the status-quo, keep the software-mixer matching the hardware mixer and cause the status dialogue (the volume bar) to be shown.

In the case above, it does not matter whether up or down is sent, as the first up or down after a mute causes Unmute, both in GNOME and in the hardware mixer.

[Martin Emrich (emme)]

It was not my intention to highlight this, but now as you explain it, the behaviour makes sense.

As I see it: lshal -m does not dump events generated by buttons, but rather what some layer in between makes of the button presses.

My opinion is that the behaviour of the Thinkpad buttons should not depend on gnome-settings-daemon (or kde-settings-daemon, xfce-settings-daemon or ... ), but on something desktop-environment-independent.

In bug #39098, I already mentioned my preferred behaviour of the Thinkpad volume buttons. Currently, I just swapped the key bindings, to make the volume-up button trigger both thinkpad-mixer-up and soundcard-mixer-up. Although this is acceptable, I am still not sure if this is the right behaviour to be a "default setting" right after installing from CD.

Of course, the fact that there are as well Thinkpads out there having no special "thinkpad" mixers (I assume there the buttons are controlling the soundcard's mixer via a software utility), there's no "one-fits-all" solution.

IMHO, GNOME should just intercept the button actions, read out the new thinkpad mixer value from /proc/acpi/ibm/volume, and display the nice on-screen-display window, if the hardware has a special thinkpad volume control. If it has not, GNOME can alternatively control the soundcard's master volume control.

[Paul Sladen (sladen)]

How exactly did you "make the volume-up button trigger both thinkpad-mixer-up and soundcard-mixer-up" ?

I think for edgy what I'll do is have a daemon that listens for changes to the ALSA state and syncs these back to the hardware.

So the hardware mixer (whether it exists or not) will always be the value of the main software mixer rounded to the nearest 1/14th. This will also solve the one case where it currently fails, which is:

  Mute with the hardware Mute key
  Unmute by right-clicking the software-mixer
  [Hardware Mute is left muted]

[Martin Emrich (emme)]

I did not do anything to trigger this behaviour. Out-of-the box (more-or-less, as my notebook was installed with the dapper development branch a long time ago, and is constantly updated), I already had the weird behaviour, that the Thinkpad buttons control both the thinkpad mixer and the soundcard mixer.

Just recently, the fact that the soundcard mixer assignments swapped, I noticed this behaviour.

Your proposal sounds reasonable, although I would wish for a checkbox in some [gnome|kde|xfce|whatever]-button-management-daemon-control-center to enable or disable the link between the thinkpad mixer and the soundcard mixer.

Because (now it gets even more tricky) when one of my soundcard mixers (master and PCM) get raised above ca. 70-80%, the sound quality deteriorates rapidly (analog clipping, overdriving,...). But the thinkpad hardware mixer can be set to maximum w/o sound deterioration. So I'd like to control them independently.

A friend of mine has an old Acer laptop with a real analog volume control, it's just a variable resistor w/o software control.
I would wish for my hardware thinkpad volume buttons to be the same, with the extra function of a working on-screen-display, and an _optional_ software control.