The Problem

Older Thinkpads have somewhat unusual support for both their volume up/down and mute, and their brightness up/down keys. These keys are directly managed in hardware, meaning that they automatically adjust the volume and brightness without interaction with software. This leads to issues where the hardware updates the volume or brightness ("control") and then the software mixers see the key events and also update the same control leading to a double step on that control, so called double-dipping. See the maintainers comments for why the hardware is like this and we can be pretty sure it will never change.

With the release of Jaunty this double-dipping has been crudely fixed by suppressing the pseudo key-presses generated for these keyboard keys. This allows hardware to update the controls in isolation, but does remove any sofware based on screen notification of the current levels of the controls. OSD is no more. See bug #357673 for the full history and discussions on this issue.

Which thinkpads are affected

This problem affects older Thinkpads. This is believed to include those up to and including the T4x series.

How things are

How is it designed to work

The handling of brightness and volume controls are pretty complex. In the more normal case there is no direct connection between the officially labeled keys on the keyboard and the controls themselves. Pressing one of these keys generates a regular key event. This event propogates from one of the kernel event channels, and is recognised by either gnome-power-manager or gnome-settings-daemon. These then take action to adjust the control as appropriate to the key, plus they send out notification requests to the notification subsystem which then displays the visual feedback. It should be noted that this request includes the current control "level".

Band-aid and Gaffer tape for Thinkpad

In the case of the Thinkpad the request actions are already being taken by the hardware. However that leaves us with no notifications. As indicated above this was previously worked-around by generating fake key events for the brightness and volume keys. These events then propogated as normal leading to visual notifications being generated, but also in attempts to update the controls. In the case of brightness this mostly works as there is a passive notification mode (see later). For volume this resulted in the hardware mixer being adjusted and the master audio mixer (by default) being adjusted leading to a double volume adjustment.

What do we really want

The purpose of the OSD notifications for these controls is to provide visual feedback on the current levels of these controls in response to the button presses. This allows the users to know that they really have pressed the button and where the button has an incremental or toggling effect to know the current state of the control (at least in a touchy feely way).

We do however only want these on some updates to the controls. Ideally it would only be in response to the button presses. We do not necessarily want them in response to slider updates to mixers in alsa-mixer for example.

Short Term

Within the current framework, the key issue is that we need a passive update mode for these controls. We want to know when they have changed so we can tell the user about it, but we do not necessarily want to update the controls directly.

For brightness support we already in theory have a passive control mode. When the HAL control 'laptop_panel.brightness_in_hardware' is set gnome-power-manager moves into a passive update mode, simply reading and displaying the current control levels on update. In theory this should be sufficient for brightness. In practice there appears to be a bug in generic backlight support which leads the display to show only the last set brightness not the current brightness leading to the display being static. This should be fixed, we could then reenable brightness feedback.

For volume control, there is currently no passive control mode for volume objects, and even if there was such a mode gnome-settings-daemon expects to be interacting with a mixer and there is no such thing for the thinkpad hardware mixer. People have gotten reasonable behaviour by selecting an unused ALSA mixer as the one to be controled and displayed, giving a facimily of the correct behaviour.

Looking at gnome-settings-daemon it _might_ be possible to implement a gnome-settings-daemon mixer object for the Thinkpad mixer, connected directly to the files in /proc/acpi/ibm. Though we would still need to handle the passiveness of the control. This is not a trivial fix.

Medium Term

It has been suggested (and we are likely to see this in the near term) that there should be an official ALSA mixer for the hardware mixer in the Thinkpad. This would simplify things as then the gnome 'controlled' mixer could be pointed at this mixer, but we would still need a passive control mode similar to brightness as this mixer is self updating.

Longer Term

It has also been suggested that part of the issue here is that the norification events are too tightly coupled with the handling of the button events. That the notifications should be a more passive display of the current control value triggered by changes in that value in isolation. The controls in question generally have generic sysfs interfaces which can be monitored, for example via poll.

This idea has a lot of merit. Amongst other things it would reduce the number of places that notification would have to be generated. However, this change would make all updates to these controls liable to produce a notification which is contrary to the users expectation. Shifting the ALSA mixer sliders does update the mixer, but does not produce a notification. We would need to decide if this change is acceptable, or look for solutions to that before we could move in this direction.