Comment 22 for bug 355300

Here's my two cents. As a user, I like to have the volume buttons adjust the "hardware" speaker volume and nothing else. I also like to see an OSD showing the speaker volume state. I don't care that they don't change line-out volume when my laptop is plugged into a dock station.

The problem, as I see it, is that most generic volume OSD frameworks (when I say OSD frameworks, I mean the whole handling of the volume buttons. eg GNOME's gnome-settings-daemon) work like this:
1) Wait for a volume key press event.
2) Check the value of the selected ALSA mixer (eg. the one chosen in Ubuntu via System->Prefs->Sound).
3) Change the value/state of the mixer (this is what causes the "two step" volume change since a different volume was already changed in hardware)
4) Display the OSD with the state of the selected ALSA mixer (which, in this case, is not the "hardware"/speaker volume)

The problems: A key press event is needed. They interact, and worse, write to an ALSA mixer.

One solution is to redesign the OSD or make a custom one to work with the thinkpad-acpi driver. An attempt at a redesign (well, really supplementing) of the GNOME one can be read about at
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/51537, http://bugzilla.gnome.org/show_bug.cgi?id=524425, http://ubuntuforums.org/showthread.php?t=966588.
This is a very hacky solution and changes the behaviour of GNOME so that, rather than interacting with an ALSA mixer it reads the volume state from /proc/acpi/ibm/volume and doesn't write anything anywhere. It correctly displays an OSD and doesn't double step the volume. The problems are that it still depends on key presses to start things off and it doesn't fix anything outside of GNOME.

Another solution, as Henrique mentions, is to implement an ALSA mixer for the "hardware" speaker volume. I plopped a patch on the thinkpad-acpi mailing list that does this (at least on my T60). To get this to work with a generic volume OSD, we still need to have key presses to start things off and we also have to prevent the OSD framework from manipulating the volume. I have added a module option to make the ALSA mixer read-only. Once the hotkey mask is manipulated to produce the volume keys and the right mixer is selected in the system preferences, this solution works.

The Thinkpad volume model is inherently at odds with the design of generic volume OSDs. I'd guess that all generic volume OSD frameworks use keypresses and all write to an ALSA driver. So either we have to make a custom OSD for Thinkpads (like in Windows) or concede that something at least slightly hacky must be done. I think the ALSA mixer solution is a good compromise. It does require that the buttons generate keypresses (which Henrique is reasonably against) and making the speaker's ALSA mixer read-only is less than ideal (but I see the ALSA mixer as a bonus way of interacting with the hardware volume anyway). But it means we don't have to customize anything outside of the driver.