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.
--
No notification when sliding audio volume, muting volume, sliding LCD
brightness on X31, X32, T60, R50e, T42
https://bugs.launchpad.net/bugs/357673
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
