Bug 11750

Created attachment 18284 [details]
dmesg (EC & NVRAM)

dmesg with default setting, EC and NVRAM used.

hmm, need a dmi check?
re-assign to henrique. :)

This is strange, and doesn't match my T43 (which wants either 1 or 3, EC or EC+nvram).  Without nvram, it won't store the brightness across sleep/shutdown.

Attach the output of dmidecode, please.  Remove UUIDs and serial numbers.

Never mind, found the data I needed in the dmesg.  You have an Intel graphics T43, yes, that's quite different from my ATI one.

Your talk about "controlled by userspace" worries me. Let's find out WHAT should be controlling the brightness in your thinkpad for real before we go any further, shall we.

Boot in SINGLE USER MODE.  No X.org.  No HAL.  No thinkpad-acpi (just unloading it should be OK for this test on a T43).   Check the hotkeys.  Do they work?

Now load thinkpad-acpi, brightness mode 1.  Check /proc/acpi/ibm/brightness (or the sysfs backlight class).  Does it work?   Do the hotkeys still work?

Now unload thinkpad-acpi, and reload it with brightness mode 3.  Repeat the two tests above.

The expected output (based on ATI T4x) is that hotkeys ALWAYS work, and that mode 1 and 3 work equally well in single user mode.

hmm... with latest ubuntu kernel i can't reproduce this issue any more. all optionc have almost same result. 
One strange issue was 
with this file /sys/class/backlight/thinkpad_screen/brightness .
it is not updated if hotkays or proc to change was used  brightness and if it differs to real brightness you can't change it with sys class. If brightness is same this interface working too.

Well, here's how it works:

1.  Feedback loops of the brightness keys into thinkpad-acpi is NOT supported. You do it, things break.  There are races with the firmware, and these cause weird things.  You do such a feedback loop with CMOS disabled, things break LESS (the race window is much shorter) but that doesn't mean they work right.  Ubuntu used to to this.  I don't know if they still do.

You set up a feedback loop if you ever touch /proc/acpi/ibm/brightness or the sysfs backlight class for thinkpad-acpi in respose to a brightness key event from thinkpad-acpi.

2.  Thinkpads with EC backlight control don't have a "disable automated key behaviour" switch in the BIOS (the hotkey_mask bits are ignored by the ACPI DSDT, unfortunately). This means you are NOT ALLOWED to defer to userspace the backlight handling. I mean it.  The only reason I let people enable these bits in the first place is because you CAN use them for OSD as long as you don't try to actually change the brightness (the firmware will be doing it by itself).

So it really boils down to whether your T43 18xx has EC-based backlight brightness handling or not.  The T43 26xx (with ATI GPU) has EC-based backlight brightness control. If /proc/acpi/ibm/brightness works on your T43 18xx in purely EC mode (without CMOS), yours is EC-based as well.

/sys/class/backlight/thinkpad_screen/brightness is used to request brightness changes.  You need the actual_brightness (or something like that) to get the current real value.  That's normal for the backlight class.

Can I close this bug?

I think not.
I will try to explayin in other way:
$cd /sys/class/backlight/thinkpad_screen/
$cat actual_brightness
will give -> 4
$cat brightness
will give -> 7
$echo 1 > brightness
nothin will be changed, steal 4 ---> this is a bug. may be it coused this issue by some userspace apps.

now i will set brightness to 7 with hotkay or true /proc/
$cat actual_brightness
will give -> 7
$cat brightness
7
$echo 1 > brightness
now acctual brightness is 1... if you continue to use only /sys/class/backlight/thinkpad_screen/brightness every thing is ok, until you use one time hotkey.

it's working only if /sys/.../actual_brightness == /sys/.../brightness

i don't suppose that brightness works when the acpi video driver
is used instead of thinkpad-acpi?

no, acpi video do not working.

No, ACPI can't help.  The T43 has two variants:  Intel graphics, and ATI graphics.

It doesn't have *any* ACPI standard-based brightness control, it has just
direct EC control or some proprietary mess that we haven't all the quirks
reverse engineered, yet.

The ATI graphics variant, IBM ThinkPad T43/p model 26xx, has EC-based brightness control.  You adjust an EC register, that makes it select an internal table of parameters to send to a PWM channel that drives the inverter for the CCFL.  This requires pure-EC, or EC+UCMS ("CMOS") control of the backlight, performed by thinkpad-acpi.

On the Intel graphics variant, it could be either EC-based or GPU-based. Nobody offered to help me find it out yet, and the test is simple...

Other thinkpads with ATI or Intel graphics might need just the CMOS mode and do the EC programming in SMM in response to the SMI trap generated by the "CMOS mode" (which, in the T43 26xx, just updates the NVRAM as far as I can see... but we might be missing some magic that would cause it to behave like the T42).

I would really need to add intelligent state-machine-based autodetection for this, or I'd need extensive cooperation from users of many models of old ThinkPads to do it without the autodetection.  It is not simple, and it is error-prone.

For autodetection, one blacklist every Lenovo thinkpad to require ACPI or use the CMOS method (none of them seem to need EC).  Then one needs to check if CMOS and EC matches. If not, use CMOS (and inform users to notify by email if broken).  If they match, lock down all brightness control from userspace, and issue a CMOS command to increase brightness.  If about 1s later the EC register changed, use just CMOS.  Otherwise, sync EC and use CMOS+EC.  Unlock down brightness control.  Inform user of the autodetected mode, and request information if it doesn't work.

As you see, it is sort of fragile and not "transparent" to the user (it WILL need to try to mess with the backlight level).  It is in my TODO list, but at a low priority.

henrique,
do we have a patch to fix it?

Not yet.  The current solution is for the user to override the automatically detected config using module parameters.

I will have to do some "user pool" to find out which config works best as a default.  It is easy enough for me to whitelist the 26xx T43 to mixed mode, and the 18xx T43 to just UCMS.  But I lack data for ever other IBM thinkpad (!).

what's the status of the 'user pool'? Can we just push the list you know first and add others later? Sure this must not break systems immediately.

hmmm, ping Henrique. :)

Writing the code today... will switch all models to UCMS, except for the TP-1Y BIOS (some T43, R52).

This might cause regressions, so it is best tested in the thinkpad-acpi out-of-tree early-adopters version before I send it towards mainline.

Ok, code is ready to set all models to mode 2 (UCMS), but keep the ATI-based T43 at mode 3 (UCMS + EC).

But reading this bug report, I can't seem to understand if mode 2 (UCMS) works fine on Alexey's Intel-based T43.

Alexey, can you tell me how it behaves when you start thinkpad-acpi with the "brightness_mode=2" parameter?

Does it let you control brightness properly through the /proc interface?
   Please test it both in single-user, text mode, and also normally in X.org

Do the brightness keys work?
   Please test it both in single-user, text mode, and also normally in X.org

Does it lose sync with the current brightness when you use the keys?  If it loses sync when in X.org, does it also happens when in single-user, text mode?

I will attach the patch to change defaults to this bug report, but it is not needed in any way to perform the above tests.

Created attachment 20511 [details]
Change defaults for IBM thinkpads to brightness_mode=2

With latest git. brightness_mode=2 is out of sync for me. The kays working in all modes, but userspace working only in brightness_mode=1. In mode 2  i can monitore changes in /proc/acpi/ibm/brightness but i can't change the real brightness. In mode 1 it's working perfektly. In mode 3, there is some glitches. 

That patch is no good then.

Well, I have (probably) fixed it in a very different way.

I removed mode 3, wrote a new mode 3 that does only ec control (like mode 1, which we know to work well from your reports) but stores the end result in NVRAM on shutdown.   I have switched every thinkpad that knows what the EC backlight brightness register is to the new mode 3 by default, and all others to mode 2 (UCMS/CMOS).

That should fix it, as it simply removes any races with the firmware in mode 3 (they might clobber each other, but they won't race).  UCMS is probably race-free, since it is atomic (uses SMM).

It is a big patch, it doesn't make sense to add it to this bug report and it requires a few other patches not in mainline yet.  Instead, I will release soon a new BETA version of thinkpad-acpi through ibm-acpi.sf.net, and request testers and reports in the linux-thinkpad ML.

After it gets some field testing, I will send it to mainline (probably for 2.6.31, since I doubt I will have enough reports to have it ready for the 2.6.30 merge window).

Please test the latest thinkpad-acpi beta version, available at:

http://sourceforge.net/project/showfiles.php?group_id=117042&package_id=230205

And tell me if it fixes your brightness problems.

Comment on attachment 20511 [details]
Change defaults for IBM thinkpads to brightness_mode=2

This old patch won't help at all.

This patch working fine for me.

Thank you.

Closing bug as CODE_FIX.

Note that, however, I don't know how much time it will take until I can send the patches to mainline as nobody in the linux-thinkpad ML seems to be in the mood to cooperate and report if it didn't break their non-T43 thinkpads...

A bug report is only "CLOSED" when the patch makes it upstream.

So RESOLVING" as "CODE_FIX" is what you mean.
This means that there is a patch available to test.

That said, exactly where is the exact patch to test?

In the thinkpad-acpi devel git tree, which I will eventually send to you for acpi-test.

I didn't get enough reports back to feel safe enough to send it to you so far.  It looks like it might well have to wait for the next merge window.  It doesn't help that rfkill is being rewritten, and I have to pay attention to that first, otherwise I will block a lot of stuff.

Anyway, it is _not_ a simple small patch, I rewrote 70% of the offending code, and it depends on other (non-critical) patches from my queue.  I could send it all for you by Sunday, HOWEVER, I am not sure it will not regress just about every IBM ThinkPad other than the T43.

Direct link to the patch (for reference, only):
http://repo.or.cz/w/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git?a=commit;h=b6ead2d2ce5c19f9281de1ecee93b2117aab7f62

(the above tree is based on 2.6.28.9 + rkill backport, you don't want to pull from that).

PS: the patches in that three are not the final form of what I am considering to submit.  It looks like I didn't push my latest tree, and I am away from my devel boxes right now.

shipped in 2.6.30 merge window (2.6.29-git14)

closed.

commit 0e501834f8c2ba7de2a56e332d346dcf4ac0b593
Author: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
Date:   Sat Apr 4 04:25:53 2009 +0000

    thinkpad-acpi: rework brightness support

    Refactor and redesign the brightness control backend...

    In order to fix bugzilla #11750...