[ltp] IBM thinkpad users, please test 0.22-20090318-BETA

[Henrique de Moraes Holschuh]

On Wed, 25 Mar 2009, Jochen Schulz wrote:
> Hm. I am just trying the patched kernel and all I can say is that changing the
> display brightness using the hotkeys doesn't work anymore at all. :) I am
> running a vanilla 2.6.29 + your patch on a Debian sid system (using some parts
> of X.Org from experimental).

Well, you said the patch didn't apply cleanly, so the fact is we don't
really know for sure how well your thinkpad-acpi.c is behaving :p

I will tell you what: it looks like we have many Ubuntu users willing to
test thinkpad-acpi, so I will start providing patches that apply cleanly to
your kernels as well.

You just need to tell me exactly WHAT is the current kernel version for the
current Ubuntu (sorry, I am a Debian guy).  I will locate it in
kernel.ubuntu.com, and create a patch for that.

I won't promise I will create patches for _every_ Ubuntu kernel version,
though.  Only for the latest stable series (currently 2.6.28.y I suppose),
and latest stable release (currently 2.6.29).

> Using xbacklight or manually echoing values to
> /sys/class/backlight/thinkpad_screen/brightness works, though.

Ok.  That means the driver is doing what it should.

> Unfortunately, I have no idea what exactly made the brightness keys work
> with older versions of thinkpad-acpi (as it is in vanilla 2.6.29). As
> far as I can tell, they  aren't controlled by acpid since the relevant
> script detects the manufacturer string "LENOVO" (using dmidecode) and
> then exits immediately.

Might be the OpRegion stuff that makes the BIOS talk to the X server or
something like that.  Brightness control got _really_ complicated when it
migrated to inside the GPU, because if the BIOS does it, it hoses the
display driver.  So, they created a shared-memory command channel for the
BIOS and display driver to talk over, and as you might guess, that thing
ain't working correctly yet.

And it doesn't work at all outside of X, since the kernel framebuffers don't
do OpRegion yet :P

> Passing brightness_enable=1 does indeed give me a working
> /proc/acpi/ibm/brightness back (and removes the sysfs interface), but
> the hotkeys still don't work anymore. 

Eh? It should _not_ remove the
/sys/class/backlight/thinkpad_screen/brightness interface.  If it is,
something is seriously wacky.

In fact, you should not _have_
/sys/class/backlight/thinkpad_screen/brightness in Lenovo thinkpads, unless
you passed brightness_enable=1.

> Yay, finally someone who wants to hear my complaints! :) My volume keys
> don't work very well either. The "mute" button only mutes (never
> unmutes) and "volume up" and "volume down" only unmute but don't change
> the volume (neither in an ALSA mixer nor in /proc/acpi/ibm/volume).

The mute button only mutes by *design*.  It is done for a good reason:
you can _ALWAYS_ press it to get sound muted, no mater how.  And if it
is still doing it on firmware, it will work _always_, even if the main
CPU crashed making a loud beep :p

Pressing mute twice by mistake, or at boot because you don't recall if
it is muted or not (thinkpads store that in NVRAM and will restore the
last state on power up) will always give you muted sound.  This is
_nice_.

To unmute, press any of the vol up/down keys.  This is actually superb
design, I sure hope Lenovo doesn't break it.

To mute/unmute on the same control, you'd need a switch, not a key.
And push switches are too fragile to last for years when they're
small, slider switches are not confortable at all in a keyboard unless
you have space to spare, and rocker switches are just too big (and
also fragile).

BTW: thinkpads have been doing mute control like that for more than 10
years.  They really should add a picture guide for that in their
wordless fast-setup brochure, since AFAIK thinkpads are the _only_
ones doing it right... and people that just got their first thinkpad
get confused over it.

Now, mute/unmute is done by the firmware.  Volume up/down *IN A RECENT
LENOVO THINKPAD* is done by userspace.  It will send normal keycodes
to the kernel, which will send it to userspace.  It is up to HAL or
X.org to do something about it.   No, thinkpad-acpi doesn't even get
the volume key press events anymore on such thinkpads, the information
flow path was changed in the EC firmware.

On IBM thinkpads, there was a volume control mixer in hardware that these
buttons commanded (and not just a "mute gate"), so you would control the
headphone and speaker volume with them (not Line-out in the dock/port
replicators).  And on those thinkpads, you don't want the events
reported as key presses, because otherwise things in userspace would
try to change a volume that the firmware had changed already.

> But again, I fail do understand which program should be responsible for
> these keys to be working. All hits with your cluebat are welcome. :) And
> if you need specific information for my model, feel free to ask.

HAL, probably.

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