No notification when sliding audio volume, muting volume on ThinkPad X23, X24, X31, X32, X41, X60, T22, T40, T41, T42, T43, T43p, T60, R50e, R51, R52

thank you for your bug report, do you get other notification? is notification-daemon or notify-osd running?

Seb, I am receiving other notification (networkManager, hplip, etc...).
So maybe this bug need to be moved to notify-osd.
Thanks.

does the volume actually change when you use those keys? why should the bug be moved if other notifications are working?

Yes, the volume actually changes but there is no visual feedback.

Not a notify-osd bug: it doesn't receive anything on the bus. I've also tried with a previous kernel (2.6.28-11-generic
), but the bug still occurs.

At least I can confirm the bug on my T60p.

the issue seems to be a side effect of the fix for bug #355300, those laptops have hardware volume actions and the software ones have been stopped to avoid duplication

I can confirm the same bug on my R50e...

Confirmed on my T42 as well.

No more volume and LCD brightness on-screen-display on ThinkPad X32 as well. These buttons still work as expected though.

Confirmed that the problem impacts LCD brightness as well as volume control on a T42, even though LCD brightness use function keys (Fn+Home, Fn+End) rather than hardware buttons. Same issue with the mute button too.

Note: this problem just arised 20 days ago. Before that, the notification was acing perfectly.

First, please read my post on bug #355300 to know about the hardware volume control and digital volume knob details.

Let's start with a key fact: the thinkpad-acpi driver does NOT support any sort of OSD notification events for brightness and volume right now. All that was done for OSD was done by abusing the hotkey key-press events, and it should not be a surprise to anyone involved that it finally decided to break hideously. That's the nature of half-baked hacks.

That said, let's see what can be done to fix OSD both in the short term in Ubuntu and in the long term for everyone. Do notice that I *expect* Ubuntu to actively work with me to get the proper long-term fixes deployed this time around.

My best guess is that Ubuntu (just like Debian) switched away from procfs-based ACPI events to netlink-based ACPI events. Well, thinkpad-acpi does not, and has never issued keypress events over ACPI netlink. Those events belong to the input layer, so they were not ported to the new, clean netlink ABI when it was introduced in 2.6.23 or thereabouts, and they will _not_ be. That is not only the right thing to do, it also avoids a whole bunch of problems due to duplicated keypress events on the input device and also as an ACPI event.

So, all you need to do for a quick fix is to (assuming you don't want to just re-enable ACPI PROCFS events):

1. Hook the OSD snooper to the thinkpad-acpi input device, instead of to the ACPI event stream;

2. Make sure to not regress #355300:

     2a. DO NOT attach KEY_VOLUME_UP/DOWN/MUTE to the 0x14, 0x15 and 0x16 thinkpad-acpi keymap positions. Instead, attach some other useless and unhandled keycodes, maybe mark those as passive, and use those as OSD events for volume up/down/mute. You will have to fix HAL .fdi files to make sure of this.

     2b. After you reprogram the keymap as above, read the value of hotkey_recommended_mask, set the bits for volume, and write the result to hotkey_mask. Do not just override hotkey_mask with some random crap like 0xffffff. I provide "hotkey_recommended_mask" in the driver for a good reason.

3. Do the same steps (2a, 2b) for the brightness keys. This will future-proof the hideous hack somewhat, which is a good idea should it outlast its expected lifetime.

That should give you working OSD in the short term. DO NOT send the above hackery upstream. Please work with me on the stuff described below, instead.

Now, for the long term OSD fixing.

1. Volume notifications

The proper place to get OSD information for mixer-related things is ALSA. If OSD is working there, it will work for every mixer, on every hardware, and in a generic way to boot.

So, how to do proper OSD for volume on thinkpads? An ALSA mixer for the ThinkPad built-in volume control (which doesn't exist anymore in recent Lenovo firmware) is (finally!) the next thing on my TODO list.

The Lenovo models already have an ALSA mixer since they just have the master mixer, so "ALSA mixer OSD" will cover all ThinkPads when I deploy support for the IBM hardware mixer (also present on 1st-gen T60).

ALSA mixers are supposed to be capable of doing event generation for OSD, and if they're not doing it as well...

Fabio: notification were originally working because each time you pressed a key, it was handled both through hardware and software, which meant that it was as if you had pressed the key twice. To correct that problem, software handling of those keys was removed for the ThinkPads. However, because the notifications were handled by the software handler, a side effect of this was that notifications were lost. What really needs to be done is to enable notification on hardware events.

I'll mark the bug as confirmed as the thread above shows that a number of people have reported it. In terms of resolving it, I am happy to make code changes and test patches on my Jaunty install if that can help.

Repeating comment from duplicate bug #364442:

The problem is that on ThinkPads, these buttons *also* have an effect at the hardware level; we have previously been overriding the defaults of the thinkpad-acpi module to force these button presses to be exposed to userspace, but there is no way to disable the action in hardware, so we end up with double handling.

The short-term fix for this is to /not/ override the kernel module and expose these keypresses to userspace. This has the unfortunate side-effect of leaving us without OSD for these keys, but this is effectively because hal/gnome-settings-daemon are not equipped to deal with this kind of "notification-only" mixer event, and there are currently no standard linux input key events defined for this.

In the long term, we need a good way to expose these mixer changes to userspace, but reverting to the previous behavior isn't more correct than what we're currently doing.

Thanks Steve!

Steve,

it may be true that the software stack can't handle volume being done in hardware, but the software stack can, and has, correctly handled the LCD brightness for ages correctly.

For the panel there is an hal property (correctly set on my x31 for example):

  laptop_panel.brightness_in_hardware = true

This is used by gnome-power-manager to let it know that the hardware notifications are just notifications and not action requests.

Steve, Crispin,

From what you both say and from my (very flaky) understanding of the problem, what needs to be done is:

1. add support for hardware based notifications in OSD
1.1 implement such notifications for LCD brightness
2. add support for hardware based audio controls (volume up, down, mute) in hal/gnome-settings-daemon, in collaboration with Henrique
3. add support for other hardware events if possible (e.g. the bluetooth/wifi radio switch or the internal/external display switch)

At first sight, #1 looks like it's an all Ubuntu affair while #2 looks more complicated than that. So what is the next step to resolve this? Should we file individual, more detailed bugs for each of the different areas of work? And what can we, as users who have little understanding of the internals and varied technical skills, do to help?

Actually, what is needed is proper OSD based on passive notifications _FOR_ OSD (and NOT a hideous hack based on keypress notifications like what exists right now for thinkpad brightness OSD).

Don't make a mistake of believing that there exists OSD support in the current scenario. There is none. It is just a jury-rig.

OSD support means events engineered to work as OSD notifications, without any side-effects on the rest of the system, nor on the input layer, etc. It means a layered approach, where you have OSD event sources (HAL, applications) and sinks (an applet that display the on-screen notifications). This is how the rest of the notification system (e.g. used to notify of new mail) already works, so it is not anything new.

HAL should monitor the kernel interfaces (sysfs backlight, ALSA mixers, etc) and issue OSD events through DBUS. Applets would not get terribly confused doing both active and passive work (which they, invariably, screw up): they would just do OSD (which is always passive in any sane design).

Stuff like gnome.*mixer would only generate DBUS OSD notification events, and the on-screen-display functionality would be in a separate component. This gives you a choice of which active producers of OSD events you want, and of which OSD applet you want to display the events. It is also very cross-desktop-environment-friendly.

I already offered to help kernel-side to fix and/or extend the kernel interfaces lacking event-based triggers, so that polling is not required, and the offer stands. But there is no need to wait for anything kernel-side, polling-based solutions can be deployed _now_.

I strongly suggest we start walking that path, after the short-term fixes are in.

Under polling you mean a soft that continuously checks the hardware mixer levels and sends a message to osd-notify whenever it changes? I'm not a programmer, but I think this is not a difficult thing to code. I have an IBM T42, and experienced the above-mentioned problems myself when i updated, and I'm willing to offer my help in the development (either by providing logs, or testing applications, whatever needed).
I'm not familiar with the way osd-notify receives events (although I think/hope the developers adhered some standards), but my opinion is, if we could find a reliable event source for the polling (maybe a file in /proc or /sys, or at least a memory address) this poller application could be finished within minutes and the numerous Thinkpad owners would be happier than ever with Jaunty :)

Same on T22.

No notification when sliding audio volume, muting volume, +/- brightness not working on X60s.
Curiously the the battery report key does just what it should and with the new notification system. Neither xev nor Gnomes Keyboard Shortcuts catches the mute, volume +/- keys.

Thinkpad X60 Tablet same symptoms

Same problem on my thinkpad t42

Same here on my T42. I started to mess about with notify-osd, thought it wasn't installed, but I'm glad I now know its a known bug.

Any ideas when we can expect this to be resolved? I miss my OSD. :(

Apart from that Jaunty seems brilliant.

In the meantime you can use tpb instead of hotkey-setup.
It requires its own hacks (see https://bugs.launchpad.net/ubuntu/+source/tpb/+bug/158262 ), but will give on screen feedback.

a.tom made me to think if is posible to hack tpb.deb to use ubuntu OSD istead of tpb blue OSD??? maybe someone with coding skills

Confirmed bug on ThinkPad T60 -- please note, this did *NOT* happen when I was running 9.04 Beta and Release Candidates.

I first noticed this problem in the stable release of 9.04 Jaunty Jackalope

Also, I'd like to confirm this bug on my friend's ThinkPad SL300 same problem but worst, he cannot control the volume (or mute) using the buttons at all, nor can he control the brightness using the buttons, he has to use the Brightness and Volume control applets in GNOME.

Sorry for mis-information, but it is only the volume OSD that does not work for X60.
The brightness Fn keys work fine with the new notifcation manager, as does the wireless notifications.

@ Henrique de Moraes Holschuh :
Is there any easy way / tutorial on how to get your quick fix (from https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/357673/comments/12) working?

I can confirm that all my buttons work on the T42, but no osd for volume, Fn brightness or Fn keyboard light on/off.

Wireless notifications and other ones using notify-osd (e.g. Pidgin) work fine.

here is a workaround for those who are interested:

http://packages.ubuntu.com/intrepid/i386/hotkey-setup/download
downgrade to the version of hotkey-setup in intrepid repository

it fixed my ThinkPad T60

This workaround does the trick, but is unfortunately not the prettiest. The keys on the Thinkpads are controlling the hardware mixer (as Henrique & the others explained above) and with the old hotkey-setup, your volume buttons will control the hardware mixer and the software mixer together.
The suggested approach was to find a polling based solution, which is possible (at least for the volume) using a couple files in the /proc filesystem, that store the hardware mixer levels. I'll try hacking up a script for watching these values and sending a notification whenever they change (this way you don't have to control both mixers, and can have the functionality without the bloody hacks).

I've created a small script to handle hardware mixer and brightness changes on Thinkpads. If you start it (perhaps fork it to the background) and change hardware mixer or brightness levels, you should see a notification pop up with the appropriate value within 1 sec (yes, i know it's not immediate, it's on the todo list :)
I take no responsibility for the script, so please read it through before executing (it does not need root privileges btw), and please share comments and suggestions. Thanks

Zoltan

@Zoltan,

Nice little script: it works great on my T42, thanks! Just a small comment on it: it would be easier to read if you indented what's inside the 'while' loop.

instead of the sleep 1 loop (which may drain battery a bit from all the polling), maybe use:

while read file event
do
  case "$file" in
   */volume)
     # take volume actions here
     ;;
    */brightness)
     # take brightness actions here
     ;;
  esac
done < inotifywait -qm -e modify /proc/acpi/ibm/volume /proc/acpi/ibm/brightness

it'll need inotify-tools installed...

Sorry, last line should read:
done < <(inotifywait -qm -e modify /proc/acpi/ibm/volume /proc/acpi/ibm/brightness)

I altered Zoltan's script so that it could handle muting and unmuting, and also change the speaker icon depending on what the volume was set at. Ubuntu is displaying notifications for brightness changes on my T60 (don't ask me why), so I can't comment on how the brightness notifications in this script work with my changes (though I didn't touch that part at all, so they really should work just fine).

Thank you Zoltan for posting your script.

Thanks everybody for the contributions, it really was a morning surprise :) I'll try to combine Kees' cycle with dmandell's level checking in the evening, as i don't have my T42 with me currently. I've been also thinking how this could be developed to look like an official fix, do you have any ideas regarding that? I could create a .deb file that installs the script in /etc/init.d and starts it during boot, but before going that far we should see if the script works on other Thinkpads, shouldn't we? Also, what are your opinions about a shell script doing this job (that's the only "programming" language i have experience with)? Would an application written in Python or C work better?

Zlotan, I just tried Kees's suggestion but it looks like the files in /proc don't generate any event that can be captured with inotifywait. It works on standard files but not on the ones we're interested in. I suspect it's because /proc is pseudo-filesystem rather than a real one.

In the meantime, you'll find attached a small update on dmandell's script that shows different brightness icons depending on the brightness level.

In case someone might wonder... you need to have 'libnotify-bin' installed in order to get the script running.

sudo aptitude install libnotify-bin

Bruno, I just noticed something, is there a reason why you use
notification-keyboard-brightness-*
instead of
notification-display-brightness-*
as icon. It might confuse the user if he also has adjustable keyboard brightness. :)

Dietmar, no reason whatsoever, that's a mistake. I thought the icon looked weird but didn't investigate. I know why now :-) Here's a corrected script attached.

On Thu, 30 Apr 2009, Bruno Girin wrote:
> Zlotan, I just tried Kees's suggestion but it looks like the files in
> /proc don't generate any event that can be captured with inotifywait. It
> works on standard files but not on the ones we're interested in. I

Only a few sysfs attributes have poll/select support, and I don't know if
that's enough for inotify or if you also need some sort of special inotify
support in sysfs (something I don't know if is even possible but I could
check). The attributes with poll/select support are documented in the
thinkpad-acpi driver documentation on the kernel sources, at
Documentation/laptops/thinkpad-acpi.txt. If inotify is indeed impossible,
you will need perl, python or C to deal with poll/select, shell can't do it
AFAIK.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Henrique, thanks for the hint. If someone wants to have a go at reproducing this script in perl, python or C with poll/select support, go ahead. Otherwise, I'll have a go when I come back from holidays in 2 weeks (and no, I'm not taking the laptop with me).

In the meantime, Zlotan's script is a great proof of concept and I can confirm that adding it to my Startup Applications works a treat: I now have brightness, volume and mute notifications back, albeit with a slight delay.

the same for kubuntu, but still not very satisfying but at least I get some visual feedback

have you tried tpb? it works very nice too :)

'just another confirmation for the volume/brightness hotkey OSD regression, this time on an X32.

How does GNOME intercept the suspend button's key-press event? Could that same method be used to intercept hardware volume and brightness events?

Just want to confirm that the volume notification doesn't work on my T60, the notification for brightness DOES however work!

Hi!
I've written a small C program which pops up notifications about changes in the sound. It has two major advantages over the script here:
1) much less CPU intensive as it doesn't require executing external applications and so on.
2) it detaches itself automatically from the controlling terminal so you can close it. daemon(3)

You can find it here: http://bwalexh.wordpress.com/2009/05/02/ubuntu-thinkpad-sound-notification/

If you have any problem with it, please leave a comment on that same page!

I forgot to say that I've only tried this script on my own ThinkPad, which is a T60. For some reason brightness control works fine for me, so my C program will only take care of the sound notification.

I just upgraded a Lenovo X301. After upgrade only the volume up/down generate X events and and OSD. The mute button no longer generates an X event (nor OSD).

The reason why the brightness notifications work on T60 and newer is that they have a better ACPI implementation. I'm not really a programmer, but using bwalex's script as a guide i guess i'll be able to add brightness to the notification watchlist, so we can have a more lightweight solution for the older notebooks also (at least i'll give it a try tomorrow).
I'd also appreciate if somebody could shed some light about how this should move on to become an official, real solution for the problem? An application written in C and needing a bunch of -dev packages (nor the shell script i've written) is not something the average user can do/will do in order to get the OSD fixed. Any ideas are greatly welcome.

Zoltan;

if I get the information on the exact output of a cat on that /proc/ node I can change my program to also take into account brightness changes (on a non T60 thinkpad).
But as I said, for me to do that, I need some real info on how that info looks, or is it the same as on T60?

well, /proc/acpi/ibm/brightness definitely does NOT exist on a T60, so if someone please can show me a FULL cat /proc/acpi/ibm/brightness I can change my program.

Even on new laptops (I'm using an X301) there is no /proc/acpi/ibm/brightness

The brightness is outside of the ibm-specific ACPI stuff and under each monitor, e.g. /proc/acpi/video/VID/LCD0/brightness

There is a folder in 'VID' for each possible monitor output, including the built in LCD. Normally only the built-in LCD has adjustable brightness, but you could imagine that more that one monitor may have adjustable brightness in the future.

cat /proc/acpi/video/VID/LCD0/brightness
levels: 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 100
current: 75

cat /proc/acpi/video/VID/CRT0/brightness
<not supported>

The '/proc/acpi/video/VID/LCD0/brightness' value changes when using the brightness hot keys. It actually jumps two values until it runs out of values and then it change to the last value, e.g. moving up and down you can get to all 16 values but in a two-sweep sequence.

  100 -> 85 -> 75- > 65 -> 55 -> 45 -> 35 -> 25 -> 20 -> 30 -> 40 -> 50 -> 60 -> 70 -> 80 -> 90 -> 100

Hi,
Now I've changed the program to be able to use /proc/acpi/ibm/brightness. If it doesn't exist, it just won't notify of brightness changes.
This will obviously not take take of brightness on the X301 or similar laptops but I'll probably add the relevant code for the X301 and others that have it under /proc/acpi/video/* soon.

For now this is the new code which gives notifications for the sound and for brightness on those laptops that have /proc/acpi/ibm/brightness. In the post there are now also more detailed step by step instructions.
I obviously couldn't test this so please leave your feedback on how the brightness stuff works for you.

This is the link: http://bwalexh.wordpress.com/2009/05/03/new-ubuntu-thinkpad-notification-program/

Looking forward to some feedback,

Alex

I think brightness events should be handled by gnome-power-manager.
Maybe it is just a bug in there!??

My T42 handles brightness and sound in hardware.

Gnome-power-manager should accept the event, show a notification, and remember the current state of brightness.

I am not sure which app normally handles volume events, but I would think its a bug in there!

Maybe a combination with hal not forwarding event, because it knows this stuff is handled by hardware ?

I think a script is not the right way. Finding the real bug should be done!

I suspect there are quite a few different types of hardware which have
the problem of buttons that are hardwired to generate the result. If
this code can be the basis of a general solution, we should aim to get
it packaged and included in Karmic.

Matt - this is about a solution for laptop keys (volume, brightness)
which don't currently work because they are handled at the hardware
level and we exclude them from the software processing to avoid
double-dipping; which team would be best to ask to look at this in
Karmic? Foundations? Desktop?

Mark

Try enabling hotkey event in the thinkpad-acpi module!

This way hal gets the events, or you could control the events from the acpi interface in /etc/acpi.

echo 0x00ffffff > /proc/acpi/ibm/hotkey

I've updated the program to be able to deal with the new kind of brightness /proc node in acpi/video/VID...

You can find it under http://bwalexh.wordpress.com/2009/05/03/new-ubuntu-thinkpad-notification-program/

If for some reason you don't have /proc/acpi/video/VID but rather /proc/acpi/video/VID1 and don't have brightness notifications, change this line:
#define BRIGHTNESS_NEW_NODE "/proc/acpi/video/VID/LCD0/brightness"
to whatever applies to you.

Johannes, I don't doubt that this a bug somewhere; I don't care. Linux and linux distro developers are lazy and pretty much don't know what they are doing, this is after all how this bug appeared in first place.
I am not going to wait for someone to fix a bug or even find it myself when I can produce a workaround for it in just under 30 minutes. You are free to use it or not, it's your choice, but considering that the bug priority is 'low' I wouldn't expect a fix anytime soon.

Cheers,
Alex

Enabling hotkey event in the thinkpad-acpi module (as suggested by Johannes) has fixed htis issue on my Thinkpad X31. I have back my notification for audio sliders!

Fabio,

the solution of adding the hotkey event has the exact problem Ubuntu was trying to avoid: controlling the sound or brightness twice per click: one in hardware and one in software. You'll notice that the sound control will jump twice as much. At half the slider you'll have no sound whatsoever.
Anyways, feel free to use whatever solution (or not solution) you want.

I dont know how to fix for the sound volume.

But for brightness, the I think the right solution is to enable the hotkeys, and let g-p-m handle it.
g-p-m only does notification and no actions. Unfortunately the notification does not reflect the real brightness level on my box.

Brightness should be fixed in g-p-m.
http://svn.gnome.org/viewvc/gnome-power-manager/trunk/src/

bwalex:
As your a C programmer, I am sure you could easyli patch g-p-m to fix the brightness issue !?

For sound button events:
Maybe it is posible to disable hal's handling of the these keys, and let the apci scripts in /etc/acpi handle it. This way polling is avoided!

As I have said before on this bug, g-p-m does handle brightness correctly assuming that hal is setup to know that your panel handles things in hardware. you need the following property on the panel:

  laptop_panel.brightness_in_hardware = true

g-p-m has handled this properly for around 3 years. Please revert the brightness change and get the correct flags in hal.

Johannes,

yes, I'm a C programmer but the reason why I wrote the workaround was to avoid having to spend a whole afternoon fixing GNU/Linux bugs. Plus, I'm a *BSD developer and hence don't know my way round linux' weird ways of doing things (e.g. hal).
I might take a look at it, but in my opinion this requires changes to a few things (pulse audio volume applet or whatever it's called for one) and is Canonical's job to fix and coordinate with the individual package developers.
As for polling, this is the least of your issues. It won't have ANY effect at all on CPU load or battery life time the way I did it. It sleeps for more than 99% of the time and only wakes up 4 times a minute.

Cheers,
Alex

Crispin:
Hmm... actually I get a notification, but it does not reflect the real level of brightness.
Yes hal correctly set laptop_panel.brightness_in_hardware = true on my hardware (T42).

It seems g-p-m does not read the actual brightness level before notifying!?
The notification always shows brughtness level = 6, even if actualle lower or higher.

Futher I think g-p-m should remember my last brightness level, I think it does not!?

@bwalex: you are right. I removed the workaround

No... I was trying to remove it. Forgot the previous mask! Anyone knows?

fabio:
cat /sys/devices/platform/thinkpad_acpi/hotkey_recommended_mask

for the brightness:
sysfs has to files in /sys/devices/virtual/backlight/thinkpad_screen. brightness and actual_brightness.
brightness always says '6', actual_brightness correctly gives the actual level.

Hmm, Johannes, you seem correct, g-p-m does seem broken, it gets the notification and then queries hal to find the current brightness, which just seems to call back to g-p-m which just returns the last level. I'll see what upstream says.

hotkey mask:
To enable brightness events use: 0x8dffff
To enable volume control user: 0xfc7fff
To enable both use: 0xfdffff

Anyone know how to disable HAL handling/mapping these keys ?

I did a simple setup which is working for me.

All collected in attached tar.gz

Basicly:
* enable thinkpad_acpi hotkeys
* disable volume up, down, mute in HAL - I just deleted the lines
* Add event to /etc/acpi/events
* Simplyfied Zoltans script to use with acpi.
* Letting g-p-m handle brightness events.

Found a better way to disable hal's handling of the events

Instead of editing /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi

Simply add attached hal file to /etc/hal/fdi/information.

The file overrides the keymapping of thinkpad extra button.
I have deleted the sound volume events.
But you could easyli delete the brightness handling to.

This way the acpi daemon can handle the events, and launch the notification script!

Unpack tar to your /etc

This setup notifications using acpi for both brightness and sound.

Still brightness should be handled by g-p-m, as soon as it is fixed.

Your scripts work very well on my T42.
The buttons for volume and mute make no problems.
Thanks Karl

bwalex's script (https://bugs.launchpad.net/ubuntu/+source/hotkey-setup/+bug/357673/comments/63) works well on my ThinkPad X31. Both volume and brightness notifications appear.

Thank you very much!

However, when running from the terminal, I get an endless stream of "brightness new crap occured".

The problem appears to be that my ThinkPad uses the old brightness node (/proc/acpi/ibm/brightness)

However, the new brightness node still exists:

phil@phil-laptop:~$ cat /proc/acpi/video/VID/LCD0/brightness
<not supported>

So I have modified it to check for this (again, this is a quick and dirty fix)

I've packaged bwalex's solution (along with my patch) here (hope he doesn't mind).

No deb package available for this? The compilation requires me to install 34MB of -dev packages on the laptop.

bwalex's little notify program works fine on my R50e. Plus, it's simpler than merging all those acpi scripts (which didn't work on my R50e anyways).

Only one problem. The volume gauge seems to go over the limit, near the edge of the popup window. Also, the brightness gauge stops a hair before being full, which doesn't give that nice glowing sun animation you get when you've maxed out the brightness. I'm not sure how to fix these things.

For the volume you can change the line that reads volume<<3 to volume*7.
notify_notification_set_hint_int32(not, "value", volume<<3);
 I normally use shifts wherever possible, but obviously LSL by 3 multiplies by 8, and given a maximum raw volume of 14, that goes a bit above the maximum. Nonetheless multiplying by 7 stays a bit under the minimum. If you happen to have a maximum of 15, choose whatever value you think is suited :P

Same thing for the brightness; find the following line:
show_notify_brightness(brightness*14);
And change it to whatever you want, but remember that we are dealing with integers and not float/double. This applies to both.

Crispin:
the brightness bug with g-p-m notifications, IS actually a hald bug. bug #372874

the 'get_backlight' function should read 'actual_brightness' not 'brightness':
http://cgit.freedesktop.org/hal/tree/hald/linux/addons/addon-generic-backlight.c

'brightness' is only used to set backlight!

bwalex's code along with PhilippeDePass's patch works great over here. Is there any chance that someone can package this so that more people can benefit from the fix?

Will the 'hal' bug #372874 see any love?

Fixing bug #372874 and enabling thinkpad_acpi hotkeys for brightness-keys DOES fix the brightness issue.
Brightness-notification will then be handled correctly by g-p-m!
Modprobe option to enable brightness hotkeys:
    options thinkpad_acpi hotkey=enable,0x8dffff

The sound-notification is another story, and should be investigated further. HAL should be made aware whether sound-volume-buttons are hardwired or not.
Have a look at gnome-keybinding-properties, as the sound-volume acpi-events ends up here.

bwalex:
I do acknowledge your solution, but I still think Canonical should go for the long-term solution.

I can confirm the bug for a R51

I can confirm this on a Thinkpad T43.

I can confirm this bug on a ThinkPad SL400

I can confirm this bug on a ThinkPad X60S 1702-4EM a lot of good work has been done to try to find a way to rectify this bug thanks to all of you who have contributed

I also confirm this bug on a ThinkPad T60 with Jaunty X86 fully updated.

I can confirm this on my ThinkPad T43

Confirmed on X41.

After trying to resolve my notification feedback problem (volume and brightness) with Johannes Hessellund solution and roundly failed in my attempt, I decided to give it a try with bwalex's solution (C program), which worked out pretty well.

After checking out the source code I noticed the program constantly read's from the processes filesystems /proc/acpi/ibm/volume, /proc/acpi/ibm/brightness and /proc/acpi/video/VID/LCD0/brightness so it can accordingly call the function that will display the pop-up notification. I tried to imagine a better way to make the calls to the functions without the constant need to read from the procfs files, this led me to an inode-based filesystem notification technology called inotify. With this tool I managed to make the calls to the functions that will display de pop-up notifications only when the procfs presented an event (File was read from, File was written to, File was opened, etc.). In this way I assume the CPU has less activity and earns processing time, either way you can correct me.

A special thanks to bwalex from which whom's code I reused to create this new version.

P.S. Hoping this program can help other people just like it did to me.

I realize my acpid-solution only works when restarting acpid from within the xsession. This is because of the dbus signal system. acpid must have the users dbus-session-bus-address to send the notification. Sorry about that.

Anyway the right way of solving the brightness is still fixing the 'hal' bug, and let g-p-m do the work. g-p-m was designed to to this, and it works. I did compile hal with the fix and enabling the hotkeys in thinkpad-acpi.

The workaround is great. But its always better to fix the cause.

Please some dev look into bug #372874 for a review, patch for hal is included!

Wenzhuo, Bruno, Russ, sten, Johannes: this was originally a bug report about volume hotkey handling, which is the only issue affecting the vast majority of the models listed in the bug title. Only the T42 and X32 appear to also have an issue with the brightness keys, the solution for which is going to be largely orthogonal to the volume key fix.

Please file a new bug report about the brightness hotkey handling, and provide a link to the bug here. As Johannes mentions, that bug should actually be quite a bit /easier/ to fix than the volume hotkey bug, so we should disentangle these two issues.

Thinkpad Z60m affected too. Both volume and brightness keys.

Same problem with T40p

with T41

@Steve Langasek and others

I updated the subject of bug #372874 to reflect the brightness-notification issue. It contains (at least on my T42) a permanent solution to the issue. Please try it out and report any problems with patch.

Confirmed on a T43p in 9.04

Confirmed on my Thinkpad X60s. The hotkeys work but there is not visual indication.

Same issues on IBM T41. There were no issues with Intrepid, but appeared the issues w/ Jaunty.
As I am not a software guru, but a user only, I wish to have a system upgrade that could solve the problems...

Confirming:

No notification when sliding audio volume, muting volume or changing brightness on ThinkPad Model T43p

The brightness notofication bug is resolved upstream now. Also see bug #372874.

http://cgit.freedesktop.org/~dkukawka/hal/commit/?id=d792a792846f9632edfdea3651a74fcd24b2ead7

Please update Jaunty version of HAL with this patch.
Brightness notifications on Thinkpads will to solved.

To enable brightness buttons they should be enabled in the thinkpad_acpi module:

options thinkpad_acpi hotkey=enable,0xfdffff

On Sun, 26 Jul 2009, Johannes Hessellund wrote:
> The brightness notofication bug is resolved upstream now. Also see bug
> #372874.
>
> http://cgit.freedesktop.org/~dkukawka/hal/commit/?id=d792a792846f9632edfdea3651a74fcd24b2ead7

It was about time. Good news.

> Brightness notifications on Thinkpads will to solved.

No, they won't. The real fix was submitted by Fedora, as generic brightness
change *event* support. I will contribute with sysfs poll() support for
actual_brightness on top of that patch soon.

It will be in the 2.6.32 kernels, and Ubuntu should backport THOSE as well
if they want proper brightness handling, and fix HAL to use select()/poll()
or uevents to get the notifications. Patches available in the linux-acpi
mailing list.

> To enable brightness buttons they should be enabled in the thinkpad_acpi
> module:
>
> options thinkpad_acpi hotkey=enable,0xfdffff

This will, of course, destroy any chances you have of working brightness
keys on any Lenovo laptop if the user has to tell ACPI video to switch to
"vendor" mode (typically done when brightness change refuses to work with
nvidia cards or Xorg OpRegion+KMS).

Patches for thinkpad-acpi to auto-enable brightness keys when vendor mode is
active on the thinkpads that need it are ready and available in the
thinkpad-acpi devel git tree. I will be sending them out soon to the
linux-acpi mailinglist. Patches to use the brightness event support are
being worked on, should be ready in two weeks.

Obviously, any gross hack that enables brightness key events and THEN goes
on to *abuse* it as simple notifications will make it completely impossible
for thinkpads that actually need they to be processed as keys, to work.
This is what is currently employed by Ubuntu+HAL, as far as I know.

PS: if you ever need to proplery *reset* thinkpad-acpi's hotkey_mask to the
one that the driver wants to be used, do this:

cat /sys/bus/platform/devices/thinkpad_acpi/hotkey_recommended_mask
    > /sys/bus/platform/devices/thinkpad_acpi/hotkey_mask

Might be needed when all the proper event support lands.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I can confirm the muting issue on my T500 running Ubuntu 9.04. Volume up/down and brightness up/down work as expected, though.

On Mon, 10 Aug 2009, Aristid Breitkreuz wrote:
> I can confirm the muting issue on my T500 running Ubuntu 9.04. Volume
> up/down and brightness up/down work as expected, though.

The T500 is an entirely different beast, and whatever afflict it has no
bearing with this bug which is related to ACPI-based events.

The T500 reports MUTE over the regular keyboard (or doesn't report it at
all, apparently).

Please remove the T500 from this bug.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I have to agree with Henrique...
Aristid, your T500 issue is probably linked with this separate bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/368989

Thanks
 - Nicolas

I'm surprised to see this is not nominated for Karmic.
Is anybody actually working on it?
This bug is particularly annoying in the light of Bug #434789

Sorry, I meant "is nominated". There doesn't seem to be a lot of attention to the issue anymore.

On Sat, 10 Oct 2009, Nick Bauermeister wrote:
> Sorry, I meant "is nominated". There doesn't seem to be a lot of
> attention to the issue anymore.

Quite the opposite! Backlight has been fixed properly and will be in
2.6.32. The code to support the backlight events is also usable to report
volume and mute state changes, so implementing that is next in my list.

In fact, I am working on that support *right now*. It will take the form of
an alsa mixer. If you want OSD for audio, you hook to the mixer using a
proper ALSA-aware program, and it will be notified when the volume changes.

Alsa mixer support will be on the kernel upstream for 2.6.33. Ubuntu likes
to backport this kind of stuff, so you should see it well before 2.6.33 is
out.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Status on my ThinkPad R500 (Karmic beta): volume hotkeys work, but mute button doesn't, however it worked in alpha 5.

On my TP T42 brightness and volume with mute now works fine! (but only if i set hotkey=0xffffff).

Henrique,

thank you for your work.
Just to confirm on my X31 I don't have notifications for audio and backlight (Karmic 2.6.31-14)

On Mon, 26 Oct 2009, Fabio Marzocca wrote:
> thank you for your work.
> Just to confirm on my X31 I don't have notifications for audio and backlight (Karmic 2.6.31-14)

Audio (alsa mixer) is not ready yet. Backlight is in 2.6.32, you can ask
the Ubuntu kernel team to backport it, but it *does* require userspace
applications to be updated to use the backlight class properly for OSD, so
just backporting the kernel support is not enough.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I just tested with three TPs.

T42p -- mute, vol up, vol down all work.
T61p -- mute, vol up, vol down all work.
T500 -- vol up, vol down work. mute has no display and only mutes -- it does not un-mute as the second press does on the other two models.

I would like to figure out why there is a difference... but not sure what data should be gathered.

The behavior on the T500 = press vol up or vol down and OSD displays the message properly, press mute and the sound is muted with no OSD message displayed, if mute is pressed while the sound is muted it does not restore sound.

The behavior on the T42p and T61p is that mute, vol up, vol down display a message using OSD and the second press on the mute button restores sound.

Here are the XEV results.

T61p:

keycode 121 = (keysym 0x1008ff12, XF86AudioMute), state = 0x0
keycode 121 = (keysym 0x1008ff12, XF86AudioMute), state = 0x0
keycode 122 = (keysym 0x1008ff11, XF86AudioLowerVolume), state = 0x0
keycode 122 = (keysym 0x1008ff11, XF86AudioLowerVolume), state = 0x0
keycode 123 = (keysym 0x1008ff13, XF86AudioRaiseVolume), state = 0x0
keycode 123 = (keysym 0x1008ff13, XF86AudioRaiseVolume), state = 0x0

121 = mute, 122 = vol down, 123 = vol up

----

T500

keycode 36 = (keysym 0xff0d, Return), state = 0x10
keycode 122 = (keysym 0x1008ff11, XF86AudioLowerVolume), state = 0x10
keycode 122 = (keysym 0x1008ff11, XF86AudioLowerVolume), state = 0x10
keycode 123 = (keysym 0x1008ff13, XF86AudioRaiseVolume), state = 0x10
keycode 123 = (keysym 0x1008ff13, XF86AudioRaiseVolume), state = 0x10

36 = mute, 122 = vol down, 123 = vol up

Correction to above... the T500 mute is not

keycode 36 = (keysym 0xff0d, Return), state = 0x10

I accidentally hit the return key with my elbow apparently. Sorry for any confusion. The mute button does not register in XEV

> The behavior on the T42p and T61p is that mute, vol up, vol down
> display a message using OSD

I'm a bit surprised the OSD works for you, assuming you're running a recent stable release, and are using the out-of-the-box configuration (might help to specify which release/kernel you're running, and whether you did anything to get it work) ... to contrast, I've got a T40, which I assume is pretty similar to the T42p, and in neither 9.04 nor in 9.10 do I get any OSD for volume up, volume down, or mute (although they do seem to work). Neither do I get any OSD notification for screen brightness changes in 9.10. OSD for both used to work in previous releases (if memory serves, it worked in 8.10, and had a regression thereafter). I'm assuming that this is because the kernel in 9.10 is 2.6.31-14, whilst the comments above talk about fixes being in 2.6.32 and 2.6.33? I.e. sounds like there's a chance it might "just work" in 10.04.

> The behavior on the T500

The T500 was removed from the list of machines as per comments 107 to 109. Having said that though, the list of affected machines in the title mistakenly excludes the T43, which 4 people have independently confirmed as affected, and the T41 which two people mentioned. Since the T40, T41 and T43 seem affected, it seemed probable that your T42 would be too - hence my surprise.

Also happens on my ancient X23. In Jaunty the hotkeys were working though.

Charles Profitt wrote:
> The behavior on the T42p and T61p is that mute, vol up, vol down display
> a message using OSD and the second press on the mute button restores
> sound.
>
I can not confirm this for my T42p, OOTB configuration.

With Karmic, on my IBM X31 no notification is working for volume or brightness

Contrary to Charles and in agreement with Nick, none of volume up/down/mute or brightness up/down provide any OSD notification on my T42 with a fresh Karmic install. This is consistent with Henrique's comment indicating that brightness should be in the 2.6.32 kernel and audio in 2.6.33.

On Wed, 04 Nov 2009, Charles Profitt wrote:
> T42p -- mute, vol up, vol down all work.
> T61p -- mute, vol up, vol down all work.
> T500 -- vol up, vol down work. mute has no display and only mutes -- it does not un-mute as the second press does on the other two models.

Because no ThinkPad should unmute by a second press. The T500 behaviour is
correct, while the T42p/T61p behaviours are syntethic, and done in
userspace.

The weird thing is that someone reported to me the T500 did it the weird way
(second press unmutes) because it had a direct way for the user to see if it
is mute/unmute (a LED). It may depend on OSI(Linux) -- check kernel ACPI
documentation to know what I am talking about -- and it is likely a somewhat
bad idea to mess with OSI just because of the Volume keys... enable
OSI(Linux), and you have to test _everything_ for regressions, even
processor power management control, power draw while sleeping and after
shutdown(!), etc.

> The behavior on the T500 = press vol up or vol down and OSD displays the
> message properly, press mute and the sound is muted with no OSD message
> displayed, if mute is pressed while the sound is muted it does not
> restore sound.

Which is good. It means you have a button that _always_ kills sound, and
two buttons that always help sound output (vol up/down). You are always
sure of what will happen when you press the buttons, regardless of the
current state of the audio mixer or presence of OSD.

This means you can hastly press mute as many times as you want to make sure
the ThinkPad won't utter a peep in an embarassing situation. This is valid
for the T42, that has no visual clue of the mute state, and I believe the
T61p doesn't have mute LEDs either. Models with a mute LED could operate
in either way, it depends wheter you are going to ignore the blind, and
whether a blind person would ever want to mute sound. Since they usually
don't mute sound, I did not raise a major stink when people started messing
with the way mute works.

> The behavior on the T42p and T61p is that mute, vol up, vol down display
> a message using OSD and the second press on the mute button restores
> sound.

This is caused by userspace. The firmware doesn't like it much, btw.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

On Wed, 04 Nov 2009, Nick Jenkins wrote:
> thereafter). I'm assuming that this is because the kernel in 9.10 is
> 2.6.31-14, whilst the comments above talk about fixes being in 2.6.32
> and 2.6.33? I.e. sounds like there's a chance it might "just work" in
> 10.04.

No, it shouldn't just work, at least not because of the kernel, unless
Ubuntu changed the driver defaults.

> 109. Having said that though, the list of affected machines in the title
> mistakenly excludes the T43, which 4 people have independently confirmed

All boxes with volume up/down control in firmware are affected. No boxes
without volume up/down control in firmware are affected.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

On Wed, 04 Nov 2009, Bruno Girin wrote:
> Contrary to Charles and in agreement with Nick, none of volume
> up/down/mute or brightness up/down provide any OSD notification on my
> T42 with a fresh Karmic install. This is consistent with Henrique's
> comment indicating that brightness should be in the 2.6.32 kernel and
> audio in 2.6.33.

Hrnf, the brightness code merge was delayed for some reason, and will go in
in 2.6.33 (not 2.6.32). Ubuntu can backport it easily if they want, it is
available in the releases at ibm-acpi.sf.net, and also in my thinkpad-acpi
git trees. Previous Ubuntu kernels had thinkpad-acpi backports, so it is
not unlikely they will do that backport.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

> Hrnf, the brightness code merge was delayed for some reason, and will go in
> in 2.6.33 (not 2.6.32). Ubuntu can backport it easily if they want, it is
> available in the releases at ibm-acpi.sf.net, and also in my thinkpad-acpi
> git trees. Previous Ubuntu kernels had thinkpad-acpi backports, so it is
> not unlikely they will do that backport.

Thanks; let's request this backport from the kernel team right now.

On Thu, 05 Nov 2009, Steve Langasek wrote:
> > Hrnf, the brightness code merge was delayed for some reason, and will go in
> > in 2.6.33 (not 2.6.32). Ubuntu can backport it easily if they want, it is
> > available in the releases at ibm-acpi.sf.net, and also in my thinkpad-acpi
> > git trees. Previous Ubuntu kernels had thinkpad-acpi backports, so it is
> > not unlikely they will do that backport.
>
> Thanks; let's request this backport from the kernel team right now.

Ok. The current out-of-tree releases of thinkpad-acpi are stable, and are
suitable for production work. What's there is in its way to 2.6.33, either
already submitted or will be submitted soon.

Get one of the release/* branches, don't touch the "devel" branch for any
production work.

I suggest using the git tree at
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Latest known stable releases are tagged *20091010, as of 2009-11-05.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Kubuntu 10.04 - ThinkPad R500:
- volume up, down works
- mute, unmute - kmix doesn't indicate the change
- brightness up, down doesn't work

This bug is still affecting me in Karmic on the model T43p.

I will get no notification when sliding audio volume, muting volume and changing brightness.

Just an idea here:
http://ubuntuforums.org/showthread.php?t=1328016

 Thinkpad T60 volume buttons in 9.04 and 9.10
Hi all.
I've a thinkpad T60 and 9.10 installed. I did some search on the forums and found the workaround with tpb package to fix thinkpad volume buttons issue.
My problems with that fix are:
-tbp package depens on xosd (or whatever like that, NOT Notify-OSD) so the result is not the best...
-tpb package is not neccessary at all, because thinkpad_acpi module can take care about volume buttons as well, you just have to enable the hotkey mask! http://www.thinkwiki.org/wiki/Thinkpad-acpi

So my workaround on T60 (in terminal):
9.04 jaunty:
Code:

sudo echo enable,0x00ffffff > /proc/acpi/ibm/hotkey

9.10 karmic: (using sysfs):
Code:

sudo cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask

Please confirm if the solution works on other thikpad models.

PS.: Just noticed, that after a few suspend/resume cycles or reboot, you have to update the keymask again. (somehow something overwrites it, couldn't figure it out yet.)

I can confirm that the fix in #133 works a treat on the Thinkpad R60.
Currently running Karmic and as soon as the fix was implemented the notification worked perfectly.

Here's hoping for a permanent fix!!

Thanks

I can confirm this working on a Thinkpad R50e. Can this work around also be used to show OSD for brightness? g

I can confirm, changing the content of
/sys/devices/platform/thinkpad_acpi/hotkey_mask to 0x00ffffff

Sorry, must've hit a wrong button there...

I can confirm, changing the content of

/sys/devices/platform/thinkpad_acpi/hotkey_mask

to

0x00ffffff

fixes the problem on a T42p for volume as well as brightness on karmic.
Wow, what a simple fix. Thanks for sharing!

As per comment #74, a value of 0x00fdffff also works on a ThinkPad T42. But as explained by Henrique in comment #106, this is a workaround that makes notification go through software key handling rather than hardware events. Following on this, the proper fix will be in kernel 2.6.33 as per Henrique's comments #112, #125 and following.

What this means is that if you update the hotkey_mask as per comments #106 or #133, you will need to revert it to the value in hotkey_recommended_mask once the proper fix is in (either in Lucid or backported from Lucid to Karmic).

I can confirm, changing the content of /sys/devices/platform/thinkpad_acpi/hotkey_mask to 0x00ffffff does enable some kind of notification for volume and brightness levels on TP43p. But it is surely not consistent with the overall volume settings.

Here is a test case on how to experience the awkwardness of volume setting with karmic on a TP43p (with or without workaround):

1. Set the volume to 0 with volume down HW button (not the mute button),
2. then adjust volume to maximum through gnome volume applet (up right).
-> You will not hear anything. At least I did not.

The other way round has same effect:
1. Set volume to 0 using gnome applet.
2. adjust volume with HW buttons
-> You will not hear anything. At least I did not

Looks like gnome applet and HW buttons are able to set the maximum volume to 0 without being able to change the volume back to normal vice versa. I guess this is due to the issues Henrique mentioned. HW buttons will set the HW volume to 0, gnome applet will set the software volume to 0.

Juhász József's suggestion (#133) enables notifications on my t43p with 9.04. I can also confirm the problem seakayone (#139) brought up.

I can confirm this for my Z61m.
Brightness control works tough.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0d922e3b84dc4923fc67901580a3c166006fba7a

Will this release contain some remedies for this bug? (Or perhaps I misunderstood slightly...)

For Kubuntu 9.10 on R52 I can confirm that "echo enable,0x00ffffff | sudo tee /proc/acpi/ibm/hotkey" (and mask 0x00fdffff too) works for volume control but NOT for brightness. Brightness buttons works but, but no OSD and slider in PowerDevil does not.

Pinging the kernel team - is this thinkpad driver backport going to happen for 10.04?

On 17/03/10 22:22, Steve Langasek wrote:
> Pinging the kernel team - is this thinkpad driver backport going to
> happen for 10.04?
>
> ** Changed in: linux (Ubuntu Lucid)
> Milestone: ubuntu-10.04-beta-1 => ubuntu-10.04-beta-2
>

 importance high

I don't believe a backport of the newest thinkpad driver will, alone, solve the volume notification problem. The new driver will create an ALSA mixer for the speakers, but a daemon is needed to listen for the mixer events and create notifications.

On Thu, Mar 18, 2010 at 08:12:54AM +0000, Mark Shuttleworth wrote:
> On 17/03/10 22:22, Steve Langasek wrote:
> > Pinging the kernel team - is this thinkpad driver backport going to
> > happen for 10.04?
> >
> > ** Changed in: linux (Ubuntu Lucid)
> > Milestone: ubuntu-10.04-beta-1 => ubuntu-10.04-beta-2
> >
>
> importance high
>

Hi Mark,

After getting with apw & slangasek the patch thats needed just came
out in the .10 stable update series. apw is building a test kernel for
slanasek and they will report back in the bug if that patch does
indeed fix the issue.

Thanks

~pete

--
Pete Graner <email address hidden>
Manager +1.828.358.0068 Office
Ubuntu Kernel Team +1.828.582.9466 Mobile
Canonical Ltd. http://www.canonical.com/

According the upstream commentary the notifications should be available in 2.6.32 which Lucid is based on. I do note that there is some patches for this driver not enabling notification by default for some systems in the 2.6.32.10 stable update. I will get a kernel with these patches applied out for testing. We can then confirm that the events are being emitted as expected on the relevant input event queues. We may yet need further work above the kernel in the stack, if so new tasks will be created based on the testing.

On Thu, 18 Mar 2010, Pete Graner wrote:
> On Thu, Mar 18, 2010 at 08:12:54AM +0000, Mark Shuttleworth wrote:
> > On 17/03/10 22:22, Steve Langasek wrote:
> > > Pinging the kernel team - is this thinkpad driver backport going to
> > > happen for 10.04?
> > >
> > > ** Changed in: linux (Ubuntu Lucid)
> > > Milestone: ubuntu-10.04-beta-1 => ubuntu-10.04-beta-2
> > >
> >
> > importance high
> >
>
> After getting with apw & slangasek the patch thats needed just came
> out in the .10 stable update series. apw is building a test kernel for

(I'm the thinkpad-acpi upstream)

2.6.32.10 (and 2.6.33.1) has a lot of thinkpad-acpi fixes, but they are for
real bugs in the driver, not extra functionality. I will try to submit the
extra event functionality for backlight (not sound, which is what this bug
is about) to 2.6.32.y very soon now that the bugfix queue is empty.

2.6.32.y still doesn't have ALSA mixer support, and it will take a while for
it to be submitted to 2.6.32.y.

The ALSA stuff is not working well in mute-only thinkpads yet, the firmware
on the newer mute-only thinkpads changes behaviour depending on OSI(Linux),
and not always in the same (or sane ;-) ) way. This results in weird
behaviour and the mixer may not report properly the mute state. Using the
ALSA mixer to CHANGE mute state is not working well, either.

NOTE: I specifically do NOT recommend that the ALSA mixer be enabled in
write mode by any distro. The driver defaults to read-only mode which can
be used to get events, but the user is to use the volume hotkeys to change
volume or mute/unmute. You would do well to heed that warning.

If you guys backport this stuff from 2.6.33.1 (or current mainline), I
recommend you change the driver to disable the ALSA mixer on mute-only
thinkpads for now.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I'm happy to report that a test kernel package provided to me by Stefan Bader now gives the following in /dev/sndstat:

Card config:
HDA Intel at 0xee240000 irq 17
ThinkPad Console Audio Control at EC reg 0x30, fw 79HT50WW-1.07

[...]

Mixers:
0: Analog Devices AD1981
29: ThinkPad EC 79HT50WW-1.07

The mixer is accessible using 'alsamixer -c 29', in read-only mode as expected.

Next will be to figure out how to get the desktop to pay attention to the status of this mixer.

On Sat, 27 Mar 2010, Steve Langasek wrote:
> I'm happy to report that a test kernel package provided to me by Stefan
> Bader now gives the following in /dev/sndstat:
>
> Card config:
> HDA Intel at 0xee240000 irq 17
> ThinkPad Console Audio Control at EC reg 0x30, fw 79HT50WW-1.07
>
> [...]
>
> Mixers:
> 0: Analog Devices AD1981
> 29: ThinkPad EC 79HT50WW-1.07
>
> The mixer is accessible using 'alsamixer -c 29', in read-only mode as
> expected.
>
> Next will be to figure out how to get the desktop to pay attention to
> the status of this mixer.

Thanks. Please keep me posted.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Does the test kernel also provide the "ThinkPad Console Audio Control" for devices that use snd_intel8x0?

On Sun, Mar 28, 2010 at 12:18:41AM -0000, sten wrote:
> Does the test kernel also provide the "ThinkPad Console Audio Control"
> for devices that use snd_intel8x0?

snd_intel8x0 shouldn't be relevant. What's being exposed here is the state
of the ThinkPad-specific ACPI mixer.

ahh, I see. So the "ThinkPad Console Audio Control" is a mixer in the ThinkPad firmware, and that's why it works on older ACPI Thinkpads?

On Sun, 28 Mar 2010, sten wrote:
> ahh, I see. So the "ThinkPad Console Audio Control" is a mixer in the
> ThinkPad firmware, and that's why it works on older ACPI Thinkpads?

Yes. And right now, it only works right on the older thinkpads. It is
*not* limited to ACPI thinkpads, it can work on much older boxes like the
T20 and even older in NVRAM polling mode.

There are a few fixes pending for the NVRAM polling mode, though (minor
stuff).

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

This bug was fixed in the package linux - 2.6.32-19.28

---------------
linux (2.6.32-19.28) lucid; urgency=low

  [ Andy Whitcroft ]

  * [Config] enable various multitouch devices
    - LP: #541453

  [ Chase Douglas ]

  * (pre-stable): input: ALPS - Add signature for HP Pavilion dm3 laptops
    - LP: #545307
  * SAUCE: Disable function tracing after hitting __schedule_bug
  * SAUCE: Reduce ACPI resource conflict message to KERN_INFO, printf
    cleanup
    - LP: #440470

  [ Jesse Barnes ]

  * SAUCE: drm/i915: don't change DRM configuration when releasing load
    detect pipe
    - LP: #488328

  [ John Johansen ]

  * SAUCE: AppArmor: Remove null_profile's use of PFLAG_NO_LIST_REF
    - LP: #539437
  * SAUCE: AppArmor: Stop page allocation warnings that can occur on policy
    load
    - LP: #458299
  * SAUCE: AppArmor: Return string len rather than the allocation size
    - LP: #551844
  * SAUCE: AppArmor: Fix oops in profile verification if profile unpack
    fails.

  [ Luke Yelavich ]

  * [Config] Enable Nouveau DRM module on powerpc

  [ Stefan Bader ]

  * SAUCE: Pull in thinkpad-acpi from v2.6.34-rc1
    - LP: #357673
  * [Config] Enable thinkpad-acpi ALSA volume control
    - LP: #357673

  [ Steve Conklin ]

  * SAUCE: drm/i915: Disable FBC on 915GM and 945GM
    - LP: #492392, #539609

  [ Upstream Kernel Changes ]

  * Revert "(pre-stable) drm/i915: blacklist lid status: Sony VGN-BX196VP,
    Dell Inspiron 700m"
    - LP: #515246
  * (pre-stable) softlockup: Stop spurious softlockup messages due to
    overflow
    - LP: #551068
  * backlight: mbp_nvidia_bl - add five more MacBook variants
    - LP: #511965
  * drm/nv04-nv40: Fix up the programmed horizontal sync pulse delay.
    - LP: #529130
  * drm/nouveau: Fix fbcon corruption with font width not divisible by 8
    - LP: #544739
  * (pre-stable) USB: fix usbfs regression
  * drm/radeon/bo: add some fallback placements for VRAM only objects.
    - LP: #507148
  * drm/radeon/kms: don't print error on -ERESTARTSYS.
    - LP: #507148
  * Input: add the ABS_MT_PRESSURE event
    - LP: #541453
  * HID: Support for 3M multitouch panel
    - LP: #541453
  * HID: make 3M PCT touchscreen driver standalone config option
    - LP: #541453
  * HID: add support for Stantum multitouch panel
    - LP: #541453
  * HID: make Stantum driver standalone config option
    - LP: #541453
  * HID: add support for Acer T230H multitouch
    - LP: #541453
  * HID: add support for Pixart Imaging Optical Touch Screen
    - LP: #541453
  * HID: fixed bug in single-touch emulation on the stantum panel
    - LP: #541453
  * HID: add pressure support for the Stantum multitouch panel
    - LP: #541453
  * HID: Support for MosArt multitouch panel
    - LP: #541453
  * HID: hid-ntrig add multi input quirk and clean up
    - LP: #541453
  * HID: n-trig: remove unnecessary tool switching
    - LP: #541453
  * HID: hid-ntrig: multitouch cleanup and fix
    - LP: #541453
  * HID: hid-ntrig: Single touch mode tap
    - LP: #541453
  * hid: ntrig touch events
    - LP: #541453
  * (pre-stable) x86-32, resume: do a global tlb flush in S4 resume
    - LP: #531309
  * drm/i915: Part of: Add initial bits for VGA mode...

IMO this is not "Fix Released" -- as in, there is still no notification when one presses those buttons. So far ALSA is told about those buttons, but the information is not passed on to the desktop.

Martin -

I made a wild guess regarding the package, but wanted to get this on your radar. Please reassign, retarget, etc... as needed.

I'm not sure what component is responsible for this, but I know it's not acpid. ;)

The kernel is now exporting a special read-only alsa mixer for the in-firmware mixer. Whatever processes input events and translates them to mixer changes and OSD notifications needs to do the same thing here by *reading* changes on this mixer and generating the OSD notifications. Maybe this is g-s-d?

Unfortunately the patched kernel doesn't seem to make volume notification work.

Further more as brightness was mentioned in the initial bug message, I have to add that adjusting this stopped working since the kernel upgrade from 2.6.32-18 (from Beta 1) to the latest update with the patched 2.6.32-19. Booting into -18 and brightness control (via the powerdevil in kubuntu) works fine, booting back on -19 and it's not working.

This looks pretty bad to me, as profiles can't adjust the brightness, which means that battery would last substantially shorter.

I assume this new mixer already appears in pulseaudio? Do you see it in the volume properties? I guess it can't hurt to attach the output of "pactl" on such a system.

Right now, g-s-d only listens for keypress events, it will need completely new code to connect to pulse and listen to mixer events. This is not something we can or should force into lucid two weeks before final freeze, so I'm closing the lucid task.

When I tested the new thinkpad driver, it didn't appear in pulseaudio. As far I as could tell, PulseAudio didn't like loading a alsa module for a card with no pcm input/output.

On Tue, Apr 06, 2010 at 01:09:37PM -0000, Martin Pitt wrote:
> I assume this new mixer already appears in pulseaudio? Do you see it in
> the volume properties? I guess it can't hurt to attach the output of
> "pactl" on such a system.

> Right now, g-s-d only listens for keypress events, it will need
> completely new code to connect to pulse and listen to mixer events. This
> is not something we can or should force into lucid two weeks before
> final freeze, so I'm closing the lucid task.

No, it doesn't show up in pulseaudio. It's a mixer device with no
associated input/output, so I don't think it should go through PA here - the
mixer device exists *only* to provide notifications of volume changes.

--
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>

On a T60, I now see "ThinkPad Console Audio Control", which responds to the volume buttons. As expected, no OSD notification though.

This issue is still active on Maverick, fully up-to-date, kernel 2.6.35-2, on a Thinkpad R50e.

Problem still exists in 10.10 alpha3 on an IBM X31.

I have Kubuntu Lucid with all updates. The problem still exists on my T40.

The status of this bug is fix-released in the kernel. So either the kernel fix does not work or there is another Kubuntu-specific component involved, which is not yet listed under affected compontents.

Just to clarify after such a lengthy discussion:

> The problem still exists on my T40.

The problem means: No notification when changing the volume or muting/unmuting using hardware keys. But the volume changes like expected.

This has worked in Ubuntu Intrepid at least.

@Uwe: as mentioned by Henrique in comment #112, the fix is in version 2.6.33 of the kernel hence why the bug is fix-released in the kernel. However, Ubuntu Lucid runs on version 2.6.32 of the kernel and therefore the fix is not in Lucid. It should make it into Maverick though, as Maverick should run on kernel 2.6.35 IIRC.

@Bruno (and Uwe)

I do NOT agree with you, as volume control DO NOT cooperate with the KDE/Gnome volume control applet (and neither with the OSD indicator) on Lucid with a 2.6.33 kernel (found in ubuntu mainline kernels) - BTW same for .34 and .35.
NEITHER does it work in Maverick beta 1+2+3, even if the keyboard bottoms is able to adjust the volume here too (like Uwe describes). I've done extensive tests on more of the reported boxes (from the bug-headline), and every test on new installations - apart from the kernel of course.

The only thing that makes this (and on some boxes the also the broken brightness control and OSD) work, is adding:
cp /sys/devices/platform/thinkpad_acpi/hotkey_all_mask /sys/devices/platform/thinkpad_acpi/hotkey_mask
to /etc/rc.local
And even though a big WARNING has been given by someone (was it Henrique), this just works every time and even in Karmic.

From what I understand from comment #112, only an alsa mixer was put in place in .33 kernel, which does not mean that KDE/Gnome uses this mixer - at least it seem that no buntu release does yet.

So of course it would be pretty great if it could be fixed before Maverick is released.

Regarding comment #170 I'm not sure if it's clear, that the brightness bug only applies to the default ubuntu kernels in Karmic and Lucid, not any of the mainline kernels used, nor is it present in the .35 kernel in Maverick beta jet (that is, mainline kernels don't need the workaround for brightness to work only for volume control and OSD).

Problem still exists in 10.10 beta on an IBM X31.

I can confirm the problem exists in 10.10 beta. I'm using a T60 and the volume up, down, and mute buttons do not produce any type of OSD. The brightness OSD works, but the bar it draws on screen doesn't always go to 0%, nor does it always go to 100%. It seems to get stuck around 20% and 80%.

Bug is affecting my T41 since Interpid. Currently running Lucid.

Christiansen workound works fine with 10.04 and 10.10 on my T60. Thanks!

But what does not work is the function of the mute-button itself. I can mute and when I press the mute-button again it wont unmute. I then have to press one of the lower- or higher-volume-buttons to get sound working again.

is there any fix for that?

@Simon Pfeifer

There is no fix for that and there never will be because that is intended and is hardware coded (as in; not in the software/driver). Imagine if you are playing music very loud and you quickly need to mute? What are you going to do? Push the Mute button once? Probably not... Most people would push it repeatedly. No? :)

@Julius Thor

Unmuting via the mute button does work on my T61

@Forlong

Also normal. The T61 is different. :)

On Thu, 17 Feb 2011, Forlong wrote:
> Unmuting via the mute button does work on my T61

Yes, it was dumbed down.

--
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

I dunno but I'm getting bit of a snotty vibe from you guys.
I agree it makes more sense that the mute button does just that: mute, not unmute. But there's obviously a demand for the way the T61 behaves.
There's no one and only way to go as you make it sound (which was the original reason I responded even though the T61 is not affected by this bug). IMHO it's all about choice (but sadly, that seems not be an option here anyway).

@Forlong

We're not being snotty and it's the functionality of the T60 is not up to the Ubuntu developers. It's Lenovo that made the T60 function as it does (Mute button only mutes) and that's done in the hardware mixer. However in the T61's case it's done in software and that's what Henrique meant with the "Yes, it was dumbed down." comment.

Can someone please confirm if this is still an issue on natty?

> Can someone please confirm if this is still an issue on natty?

Yes (T30). I can see the read-only mixer ("ThinkPad Console Audio Control") in alsamixer, but the volume applet uses the software mixer only, and shows no notifications when volume / mute buttons are pressed.

Confirmed on natty on a T60p.

confirmed - natty - X60s

Confirmed on Ubuntu 11.04 on a G40.

confirmed, ubuntu 11.04 on a thinkpad T30.
the hack in comment #170 works for both audio and brightness.

I see this problem in 11.10 on Thinkpad X60.

When i open alsamixer and switch to "Thinkpad Console Audio Control" sound card it can see that the buttons work.

using a Thinkpad T400 and 11.10 i have this issue. all was fine until one of the last updates (installed locally in the last 6 days (contained a kernel update as well)). can not say more as i only know it worked 6 days ago and now no longer works.

no OSD on volume events (up, down, un/mute) on Thinkpad X61S. otherwise volume buttons function as expected.

eh, sorry... the system is pretty basic lubuntu x86 11.04.

Happens on Thinkpad t42 with Ubuntu 12.04.03.

With alsamixer -> 'F6' -> "29 ThinkPad Console Audio Control" I can see current level of hardware mixer and that hotkeys are working (I can also hear they really affcets volume level). But there are no on-screen-notification.

Same with brightness.

Still an issue in 13.10. Nothing happened when I hit the volume/mute buttons on my T60p. Christiansen's workaround in comment #170 worked great though.

Still an issue in 14.04.
Tried this on a X60 with Ubuntu 14.04 and Linux Mint 17.

Complementing #194:
Still an issue in 14.04
Tried this on a T60 with Linux Mint 17 (Rebeca) and elementaryOS Freya (based on Ubuntu 14.04)

Workaround mentioned on #170 still working