Look *very* closedly at what HAL is doing on that X31. If it seems to do
the "right thing" while reporting keys to userspace over the input layer, it
is because HAL is abusing the input layer and using input events in "passive
mode", just to report brightness and volume changes through OSD or somesuch.
Either that, or you have such an old userpace there, that it doesn't react
to input events at all...
I am not exactly against the notion of passive input events (i.e. stuff you
are *not* to act upon other than to give user feedback), but you cannot
deliver them as EV_KEY (you cannot tell those apart from proper "please do
change the brightness/volume/whatever" EV_KEY), and the input subsystem is
not to be used like that according to its maintainer.
So, I want no such behaviour in thinkpad-acpi, please. There are other ways
to adress the needs of userspace, and they are being implemented (although
slowly, I am sorry about this, but my bandwidth is limited).
It is on IBM thinkpads, were you *really* have a second hardware mixer, that
operates completely independent of the OS and controls the output signal
level for the speakers and headphone (and does NOT control the output signal
level on the audio output on docks and port replicators, etc).
The volume and mute buttons act directly on that mixer (through the
firmware), and thinkpad-acpi can control that mixer fully. A mixer is a
mixer, and the proper interface to talk to a mixer is an ALSA mixer
interface.
The fact that an IBM thinkpad also lets you know exactly which mixer control
was pressed *on some models* (T4x and newer, X31 and newer, as long as the
latest BIOS is used) does not mean you are to use that to poke on the AC97
mixer controls. Heavy hint: Windows does NOT touch the AC97 mixer.
Another heavy hint: you need to track the mixer state and filter the events
to reproduce the mixer behaviour, where mute always mutes (not mute/unmute)
and you unmute with a press of one of the volume up/down buttons (which
won't change volume level when unmuting).
And on Lenovo thinkpads, the same level of control is available. The
difference is that I am not sure if the firmware is always acting on the
mixer automatically on all models and BIOS revisions. I will ask Lenovo
about it. This still asks for a mixer interface to control the internal
speaker/headphone mixer, but it *might* ask for input events for volume
up/down/mute in *some* Lenovo models. Again, this is not something the
patch in question does correctly.
Any thinkpad user that looks at that keyboard and thinks that pressing its
keys is to do anything else than control the volume of the built-in speakers
and headphone output, is already confused. Blame IBM, if you must... but
that's how things are. Lenovo may change it... or not. If they do, I will
adapt the driver to do the right thing: that's why the driver *can* report
volume input events. So that I can enable it by default should it become
the right thing to do on a given thinkpad model.
And really, you will *not* have me agree that pressing a volume key should
act on both mixers at once, ever. This reduces by half the dynamic range of
the volume control on a part of the curve (the AC97 mixer has more levels
than the internal mixer).
OSDs for volume should be tied to the ALSA mixers. One will be provided by
thinkpad-acpi soon. Heck, I can get it ready for 2.6.24 if you convince
Linus and Len to take it in after -rc1. Otherwise, it is scheduled for
2.6.25.
They are reported through ACPI events and not by thinkpad-acpi. Remove the
drivers and watch the ACPI messages.
Empirically testing things without really taking into account the path the
information will travel will not get you the right answers for this problem.
I hope I explained why that happens clearly enough in this mail...
--
"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
-
