Matthew Garrett ([info]mjg59) wrote,
@ 2009-05-04 01:38:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:advogato, fedora

Thinkpad mixers
Older (up to the *60 series) Thinkpads have a slightly odd mixer setup. There's a mixer stage that sits between the software controllable mixer and the speakers. This is controlled by the firmware in response to the volume keys being hit and can't be prevented by the OS. This is unfortunate, since users are quite enthusiastic about seeing an on-screen display when they hit various keys and if we do the obvious thing and map the volume keys to KEY_VOLUMEUP and KEY_VOLUMEDOWN then they get the OSD but also get their software-controlled mixer changed at the same time as their firmware-controlled mixer. This causes boundless confusion.

Lorne Applebaum recently sent a patch that added an ALSA control to represent the Thinkpad mixer. This means that we can now read and control the Thinkpad-specific hardware without userspace needing any special knowledge. I've gone a little further and sent a followup patch that sends ALSA notifications on button presses. Lennart suggested that it would also be helpful to export dB values and wrote a nice app that measures them - that means that Pulseaudio will be able to set the mixer volume correctly by default.

The only missing part of the puzzle now is getting the OSD back. We still can't map the keys to KEY_VOLUMEUP and KEY_VOLUMEDOWN because that'll still result in two mixers being changed at once. We can't add new keys to indicate that it's a notification event rather than a command, since X can't deal with keycodes greater than 255 (actually 243, since it adds 8 to every kernel keycode for historical hilarity) and we've run out of space. We can't hook off the ALSA notifications because that'll result in the OSD popping up in response to someone dragging a slider in a volume control application. The easiest thing might be to add another ALSA notification that's only triggered if the notification was generated in the kernel and then have userspace listen for that.

Newer Thinkpads appear to have done away with this mixer setup entirely and just send standard volume events. This is a Good Thing.

In other news, I'm off on holiday to Australia for a couple of weeks so may be a bit slow in replying to things.


(16 comments) - (Post a new comment)


[info]navalfuzzies
2009-05-04 02:31 am UTC (link)
I'll note that I've actually been quite pleased with my Thinkpad's firmware mixer.

At least when I have to modify volume with media keys going through software mixers in GNOME, there's generally a multi-second lag between pressing the key and the volume actually changing if my system wasn't dead-still. As well, the Thinkpad's firmware's mute seems to successfully mute all sounds, rather than just making it very quiet but still barely audible, as I have got on my desktop. Instead of reporting bugs, of course, I just found existing ones :)

Well, at least things are getting better all the time!

(Reply to this) (Thread)

[info]lionsphil
2009-05-04 11:56 am UTC (link)
Also, it means that you can mute the system while still in the BIOS. Firmware volume controls are Good.

Hardware ones are Better, as a slider or wheel on the side acts as tactile control and display in one, and thus avoids the need for software. For some reason, this has gone out of fashion.

(Reply to this) (Parent)
Line-out volume?
(Anonymous)
2009-05-04 04:30 am UTC (link)
That is a a good development. I've always enjoyed having hardware volume control on the internal speakers. The way the mute button works is especially great too; it is not a toggle, no matter what state the mixer is in, hitting mute ensures silence after. However, those buttons only modify the volume of the headphone jack and internal speakers. If you have a dock/port replicator it will have an audio line-out that is not affected by the firmware volume control (and it doesn't get pc-speaker beeps either.) I hope that now that the control is exposed to software that it is not taken as the final mixer. In my usage, I mute the internal speakers and use my stereo and its volume knob when my laptop is in it's dock. It would be a strange day if fiddling with my audio app un-mutes my little speakers.

(Reply to this) (Thread)
Re: Line-out volume?
[info]mjg59
2009-05-04 04:40 am UTC (link)
Docking is actually a difficult problem to get right - as you point out, some machines have entirely separate audio routings for the docking station case. Pulseaudio can (in principle) respond to docking events by switching to a different output profile and things will just work, but it's going to take a little work to get that sorted properly.

(Reply to this) (Parent)
Software vs hardware
[info]Marius Gedminas [gedmin.as]
2009-05-04 10:20 am UTC (link)
The downside of having these buttons under complete software control is that you can't mute the login sound instantly. Either the machine is so busy doing CPU and I/O stuff that it gets to handle your key press event a bit too late, or gnome-settings-daemon hasn't grabbed the key yet, I don't know which.

The same applies to the post-resume beep, where the situation is even more difficult (usually you're switched to text vc at the time).

(Reply to this) (Thread)
Re: Software vs hardware
[info]mjg59
2009-05-07 03:38 am UTC (link)
Mute still seems to be under hardware control, even with the most recent Thinkpads. This patch doesn't do anything to change that.

(Reply to this) (Parent)(Thread)
Re: Software vs hardware
(Anonymous)
2009-05-13 11:15 pm UTC (link)
I expect the OSD to stop working as per the explanation in your post.
I expect it now to be vastly more fragile as my volume now depends on a bunch of libraries including ALSA and all this gnome stuff and the functionality has a greater level of complexity. I expect to have deal with breakages and upgrade issues. I expect it to cost me time, frustration and annoyance to keep the level of functionality. I expect things will be less functional before I find time to deal with this stuff I don't even want to think about.
So you're telling me that this has no functional change.
So again I ask, why are you patching and messing with stuff that works really well? What do you hope to achieve? What problem are you trying to solve that's worth the breakage and fragility?
None at all? (This is implied with "no functional change" isn't it?
Seriously man. You're not a corporate drone productising upgrades with a tick list for the marketing brochure. Have good reasons that people actually want to see happen or leave stuff that works really well alone and let continue to work really well.
Is this really a controversial viewpoint?
Either I'm missing something really subtle or you're missing something blindingly obvious. I wonder if we can work out which it is.

(Reply to this) (Parent)(Thread)
Re: Software vs hardware
[info]mjg59
2009-05-14 10:44 am UTC (link)
What OSD? The Thinkpad firmware hasn't generated one since the pre-ACPI machines. Any OSD software you currently have installed (like the tpb package) will carry on working exactly as it did before. Depending on your desktop software and its integration with the rest of the software stack, you may instead get a themed OSD that matches the rest of your desktop. This is preferable since it doesn't require the desktop user to have read access to the nvram contents. However, unless configured to do this, nothing else will happen. The new code simply provides extra functionality to software that chooses to use it. It doesn't alter any functionality that existing software may currently require.

(Reply to this) (Parent)(Thread)
Re: Software vs hardware
(Anonymous)
2009-05-15 11:54 am UTC (link)
So you're actually /guaranteeing/ that these changes won't break stuff? What would you stake on it?
If that really is the case your post is a spectacularly bad and misleading explanation of the changes. Seems all of the comments have the same idea of what you have communicated as me, albeit drawing different conclusions.
Can I ask a third time what the actual purpose of these patches are? What are they actually going to enable? Theme my volume on screen display?
User space requiring or not access to nvram doesn't seem too interesting given there's a whole f**king forth interpreter in the kernel running in protected mode, no? (Or are there two? You'd know.) You could even have a kernel driver do the nvram writes specifically limited to those that deal with the OSD and have userspace request these in the usual fashion with principle of least privilege. Or have you suddenly gone all "let's get drivers out of the kernel" on us? I have recollections of you wanting video drivers out of X and in the kernel. "If X has taught us anything..." are the words I recall, do say something if I was hungover that day.
You've made no case for these changes. Themed OSD. Wow! It could be Red on fedora, green on suse and scarlett on deb and fittingly brown on ubu. tpb might be able to do that already...
Will the buttons continue to bypass alsa, esd, pulseaudio etc. and just work buy putting the volume up down or off directly without 100,000 lines of code getting in the way, or not?
If not, why do you want this? What is the case where this would be useful?

(Reply to this) (Parent)(Thread)
Re: Software vs hardware
[info]mjg59
2009-05-18 09:55 am UTC (link)
If you have an on-screen display for volume at the moment, then it works by polling /dev/nvram. This is bad for two reasons - firstly it involves polling, which increases power consumption and has a noticiable impact on system load in multi-core systems (nvram access is expensive when you have to do locking). Secondly, it means that the desktop user has to have read access to nvram. This allows the user (but not supervisor) bios password to be read, which is a security issue.

The new code changes none of that. Any existing software will carry on working as before. The reason I can say this confidently is that the nvram information is updated by the system firmware. No code in the Linux kernel can have any impact on that.

So, yes, we could have a Thinkpad-specific driver that limited nvram access to the bytes needed to read the mixer information. But if we're writing a driver specificially for this, then the correct interface to use is an alsa mixer - that way any existing mixer software can also take advantage of the mixer setup, rather than having to rewrite tpb to use the new interface.

The buttons will continue to "just work". That's done by the firmware. There's nothing at the operating system level that can get in the way.

(Reply to this) (Parent)
Mabe....
(Anonymous)
2009-05-04 12:57 pm UTC (link)
you could pretend to have a "second keyboard" just with these three keys...

(Reply to this)

W500
(Anonymous)
2009-05-04 05:52 pm UTC (link)
I have a W500 and vol+ and vol- keys work properly (in gnome), but Mute doesn't.

(Reply to this)

F**king What?!?
(Anonymous)
2009-05-05 02:06 pm UTC (link)
For the love of all that is holy back the f**k off.
The way the sound buttons work on thinkpads, note the correct use of vocabulary, WORK, is the way stuff should work. That is it actually does work! It does exactly what you expect, it does it right, it does it fast, it does it first time, it doesn't require any thought to use, ever, anyone who glances down and sees those buttons will know what to do with them and when. There is no other case where by doing something different with respect sounds with those buttons anyone would be happier. There is fabulous visual feedback when you press them so you know if something else is wrong when you're tuning up the volume and still hearing nothing.
WHAT PROBLEM IS THERE TO *FIX*?
FFS who kidnapped Matt and replaced him with someone who belongs in a suit and has a clipboard with boxes they need ticked at any price?
Or maybe you just hate and detest all thinkpad users and want to cause them pain and are happy to spend your acpi halos to garner sadistic pleasure?
Man alive.
Seriously.
With all the f**king things completely f**king broken on laptops why pick the one thing that actually isn't broken and f**k it up?
Stop this. Reject ALL PATCHES messing with thinkpad buttons or risk waking up with a crocodile in your bed while holidaying.
Can't express the anger strongly enough about this.
The "Obvious" thing is not to f**k with something that works better than anything you can conceivably replace it with. There's a reason everyone is happy with their goddammed thinkpad buttons.
Or maybe you can find a bunch of bug reports that say "When I pressed the volume up button on my thinkpad the volume went up rather than what I wanted which was to make matthew's brain melt." So you can finally close those bugs.
Getting the volume control away from arrogantly stupid kernel hackers might have been the secret of the stinkpad's volume control success. After all hardware volume controls have worked great for years, it took software to screw the pooch on that one.

(Reply to this) (Thread)
Re: F**king What?!?
[info]mjg59
2009-05-07 03:56 am UTC (link)
There's no functional change in this patch. What do you expect to happen?

(Reply to this) (Parent)
Response to patch fears
(Anonymous)
2009-05-05 08:33 pm UTC (link)
There seems to be a bit of confusion in here. At the risk of making things worse, I thought I'd chime in.

Some comments above have the worry that the patch hands over control to software. This is not the intention of the patch. Rather, the idea is to expose the hardware volume level to software. The volume buttons still change the volume via the firmware. They will still be instantaneous and will work as they always worked. In fact, there's no way to stop the firmware from acting with the buttons.

The problem right now is the exposure of this volume level to the user. If you're using gnome's OSD, for example, you're likely seeing a software mixer's volume level shown rather than the hardware's. Further, the buttons are probably changing both the firmware level and some software mixer. This can lead to all sorts of confusing situations.

There is the risk that, by exposing the volume level to software via an ALSA mixer, some software will mess with it. It is possible to make the new ALSA mixer read-only to prevent this. I made this a kernel option in my original patch. Matthew, with your new patch you've suggested that maybe we don't need this. I think a read-only option would prevent some the things people have raised concerns about here.

-Lorne

(Reply to this) (Thread)
Re: Response to patch fears
(Anonymous)
2009-05-06 06:21 pm UTC (link)
You don't need to give a crap about gnome's OSD if you have a think pad with a much better one, right? This is not a problem. It does not need solving.

(Reply to this) (Parent)

(16 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…