Comment 12 for bug 357673

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 as they should, I expect Ubutu to move to fix that.

I will talk to the Ubuntu kernel team to find the best way to get early code drops from thinkpad-acpi updates to them, so you should get that ALSA mixer for thinkpads quite soon after it is ready.

Again, let me reiterate: I expect Ubuntu to do its side and help to get the proper OSD functionality deployed in HAL and other userspace upstream.

2. brightness change notifications

All brightness control in the Linux kernel is done through the sysfs backlight class, regardless of whether thinkpad-acpi or ACPI video (with or without OpRegion support) is being used to control brightness. This is valid for all other laptop platform drivers too (or soon will be).

The backlight sysfs class gives instant readouts of the current brightness level, which can be used for poll-based OSD _now_. So, please do it. I expect from Ubuntu a poll-based (once a second should be enough) OSD interface for backlight brightness OSD.

One can add proper event-driven notification support to it (sysfs can do poll/select), and one can upgrade the poll-based OSD to event-based OSD when implemented by the kernel driver, so in return for Ubuntu deploying backlight-sysfs-class-based OSD, I will write the kernel patches for the sysfs backlight class, and add the event notification it will require to thinkpad-acpi (and if possible, to ACPI video).

So, now the ball is in your court.