*** This bug is a duplicate of bug 39098 *** 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. -- ibm-acpi volume control unpredictable https://launchpad.net/bugs/42886 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
