Bug 8902

Created attachment 12435 [details]
acpidump

This is the acpidump of the X61s.

Hmm, is there any difference if the thinkpad_acpi is loaded?

Nope.

Please confirm that
/sys/class/backlight/thinkpad_screen/brightness can work for you.

Hi,Henrique,
I notice that the thinkpad_acpi don't do any actual work but export an input event instead when it's notified for a backlight change.
Ideally, there should be some user space applications to listen to the input events(KEY_BRIGHTNESSUP/KEYBRIGHTNESSDOWN) and thus change the backlight through /sys/class/backlight/..., am I right?

Another problem is that xrandr can also change the backlight on thinkpad laptops
#echo 0 > /sys/class/backlight/thinkpad_screen/brightness
/* screen is dark */
#xrandr --ouput LVDS --set BACKLIGHT 40000
/* screen becomes light again */
#cat /sys/class/backlight/thinkpad_screen/brightness
0 /* this is not updated */

This is really buggy, isn't it?

Thanks,
Rui

1. For the thinkpad X61s, you do *not* want *anything* to mess with the brightness but ACPI video or the X11 driver when reacting to key presses.

2. The best way to test the kernel and ACPI DSDTs for brightness support is to have thinkpad-acpi unloaded, because that avoids some bogus userspace setups through HAL that cause massive problems.

thinkpad-acpi itself does NOT support 16-level brightness screens yet, like the X61s. This should not cause any problem (you'd just leave sys/class/backlight/thinkpad_screen/brightness well enough alone), but some distros have decided to try to mess with that when keys are pressed.

So, while trying to fix the problem with brightness up/down in any thinkpad, you should always have thinkpad-acpi and/or ibm-acpi *unloaded*.

Also, you likely need to check if the ACPI video and DSDTs are set to respond to brightness keys, or to just report them, etc.

Just to make it clear: you have at *least* two issues.

1. Known issue: thinkpad-acpi doesn't deal well with your thinkpad, don't use its brightness support for now.

2. Unknown issue, and the worst one: the ACPI BIOS + Kernel are *not* agreeing on how to work out the brightness events, this has nothing to do with thinkpad-acpi.

And this bug is about (2), unless all magically starts working when you have 2.6.23-rc3-git1 or better ACPI video loaded, with thinkpad-acpi *unloaded*.

Please attach the acpidump of your laptop.

Please see comment #1 for the acpidump.

I did some tests on a T61.
The ACPI video can receive the notification of brightness up/down if thinkpad_acpi is not loaded. And /sys/class/brightness/acpi_video1/ can be
used for brightness control.
So IMO, this is not a kernel/acpi bug.

can you try the same tests please?
1. unload thinkpad_acpi driver
1. echo 50/100 > /sys/class/backlight/acpi_video1/brightness to see if the brightness level is actually changed.
2. kill acpid, do "cat /proc/acpi/event", press the brightness buttons and attach the result. 

does the problem still exist in the latest kernel release?
can you confirm the test result I attached in comment #9 please?

I will try this weekend. (had no internet access for 2 months).

I think you are right; when thinkpad-acpi is not loaded, it actually works.
Here's the results of the test you wanted me to do:

# cat /proc/acpi/event
video LCD0 00000086 00000000
video LCD0 00000087 00000000

Try it with thinkpad-acpi from ibm-acpi.sf.net or with the patches in Len's
acpi-test tree.  Both should notice they should not try to load the backlight
interface in your box.

And if you force it to load, it should also work just fine, since I added
*60/*61 backlight control support to it :-)

Note that the full fix for video.c and your laptop requires it to publish just ONE backlight interface (the other one is for an inactive device).  I am not sure the patches for it have been accepted yet.

I am currently running a newer version of thinkpad_acpi already (0.18-20071013_v2.6.23.1). Brightness support is great, but loading both modules (thinkpad_acpi and video) makes that neither works; or at least: I can not change brightness. So when loading I guess one or the other should detect the other one and not load this feature.

Well, since it appears the video.c part is fixed for, I will assume the bug to find out why thinkpad_acpi is making a difference.

HJH, please attach the dmidecode output for your thinkpad. Remove the UUID and serial numbers before you upload, though.

Also, please attach the output of thinkpad-acpi 0.18 when loaded with the "debug=0xffff" parameter.

Created attachment 13535 [details]
dmidecode

Created attachment 13536 [details]
modprobe with debug=0xffff of thinkpad_acpi

1. You have an outdated BIOS, and for the *61 series this is often a bad idea. Please consider updating, many issues with Linux and new ACPI stuff (like standard brightness control) are often solved by updating to the latest BIOS on the Lenovo series ThinkPads.

Refer to http://thinkwiki.org/wiki/BIOS_Upgrade for help.

2. Something is indeed wrong with ThinkPad-ACPI:

thinkpad_acpi: ibm_init: probing for brightness
thinkpad_acpi: brightness_init: selected brightness_mode=2
thinkpad_acpi: detected a 16-level brightness capable ThinkPad
thinkpad_acpi: ibm_init: brightness installed

Are you setting the brightness_enable module parameter?  If one doesn't set it, thinkpad-acpi is supposed to do the right thing...

If you are not setting brightness_enable, please check if the newest version of thinkpad-acpi (I just released one and didn't send any emails about it yet) at ibm-acpi.sf.net hasn't solved the issue already.

Meanwhile, I will look at the acpidump and see if I can figure out what failed.

In the mean time I've updated to the latest BIOS (1.10).
Now using the video module still does nothing (I do see the key press in kmilo, but no brightness change).
Also using "modprobe thinkpad_acpi brightness_enable=1" does not work. I still see no change in brightness when pressing the brightness keys.
I added the following to the acpid events as a work around:
thinkpad-brightness-up.sh ->

#!/bin/bash
manufacturer=`dmidecode --string system-manufacturer`
case "$manufacturer" in
    LENOVO*)
        echo 4 > /proc/acpi/ibm/cmos
    ;;
    *)
        . /usr/share/acpi-support/key-constants
        acpi_fakekey $KEY_BRIGHTNESSUP
    ;;
esac

thinkpad-brightness-down.sh ->
#!/bin/bash
manufacturer=`dmidecode --string system-manufacturer`
case "$manufacturer" in
    LENOVO*)
        echo 5 > /proc/acpi/ibm/cmos
   ;;
    *)
        . /usr/share/acpi-support/key-constants
        acpi_fakekey $KEY_BRIGHTNESSDOWN
    ;;
esac

Eh, I better make it more clear:

1. You do *not* want to use thinkpad-acpi brightness control in a X61.  You should not give it any "brightness_enable" parameters, and it should NOT load a brightness interface in the X61.

Also, I have fixed issues in the latest thinkpad-acpi, so please do the tests with thinkpad-acpi 0.18-20071203 (from ibm-acpi.sf.net).

Can you confirm that, if you give thinkpad-acpi 0.18 *no* brightness_enable parameters, it does *not* provide a brightness interface in your X61?

2. You need to have ACPI video.c loaded, the one from 2.6.23 is good enough.
You can test that video.c is working with X.org *NOT LOADED*.  Does it work?

3. X.org can, and does try to disable ACPI video control of backlight level.  If the backlight control works in console mode, but not when X.org, then it means you must configure X.org correctly.  Please search the linux-thinkpad mailing list archives, or ask there.  I have seen posts there about it.

4. Kmilo is most likely useless for your thinkpad.  Don't rely on it for anything.

1) Noted. however... I also tried the video module, and with that I can not achieve actual change in brightness. I am currently running 0.18-20071203 on kernel 2.6.23.11
Indeed if I do *not* use "brightness_enable", it does not provide a brightness interface.

2) I have tested with the video module. I switched to init 1, loaded the module (unloaded thinkpad_acpi just to be sure) and tried the brightness buttons. They do seem to give a signal registered by the acpi interface (used acpi_listen for that) and that signal is also correcly coupled in acpid events, but no actual brightness change happens.

3) See above.

4) I noticed that Kmilo is not very useful. I just use it to connect the thinkpad button to a program of my liking.

HJH, please clarify if loading just the ACPI video driver
(ie. no thinkpad drivers)
in 2.6.23 or later makes brightness work.  (i thought this
was working back around comment #12, but maybe i misunderstood).
If it doesn't work, did it ever work?

Rui, is this a santa rosa box that needs the new opregion support?

Len,

Loading the video module (not thinkpad_acpi), makes changing the brightness setting work:

echo 50/100 > /sys/class/backlight/acpi_video1/brightness makes that the brightness actually changes.

I've tested this withh kernel 2.6.24-rc6
The thin that is NOT working, is acpi support for this item: Pressing the brightness buttons does yield the correct response (i.e. the correct and supported acpi event), but no actual brightness change occurs.
I guess this an acpid issue?

There are three things that come to mind which would stop ACPI video.c to change brightness by itself:

1. ACPI video.c bugs

2. X.org has been loaded and told either ACPI or the BIOS itself to not do it (I don't know if it must be *active*, btw. Maybe it doesn't undo it on exit or display switch) as it can program the Radeon BIOS scratch registers in a way that the BIOS looks at it and decides not to touch the hardware

3. ThinkPad firmware bugs.  Do test how it reacts when you tell the ACPI firmware to let a query for an OSI of "Linux" work or not, and report that back, because we now have a way to ask Lenovo to change that if needed.  I forget which kernel command line option does this :(

I'll check if it's an acpi video driver bug.
BTW: It's true that X.org want to stop all the acpi video driver actions upon brightness up/down and display switch hotkey press, which means acpi video driver will only export the input events to userspace in the notify handler.
IMO, it's reasonable and we can do that right now as
1. userspace can get the notification upon hotkey press
2. ACPI video driver offers the I/F for userspace to react on the hotkey press.
   (/sys/class/backlight/ and /sys/class/video_output/). so users can handle
   it if X doesn't.
henrique and len, what's your opinion? :)

Just a small addition: I tested without X, and a shut down hal and dbus daemon.

A proper fix to this bug means the Intel GPU opregion patches plus the thinkpad-acpi patches to coordinate with ACPI video (already in mainline for a while), and whatever X.org needs to not hork with ACPI video.

I.e. it is the same old story for all ThinkPad VISTA BIOSes with brightness control done on the GPU (and not by the EC): you *need* a fully working ACPI video + opregion + X.org userspace for it to have a hint of a chance of working right.

I am marking it as closed for the thinkpad-acpi side.  ACPI video and opregion stuff are, AFAIK, tracked separately.