Bug 308264

I can confirm the problem with a X61 Tablet (AJ has a X61). What happens?:

1) no brightness changes in hardware on Fn-Home/-End
2) * watch -n 0.1 'cat /sys/class/backlight/thinkpad_screen/actual_brightness' 
   * if you press Fn-End you get this sequence: 7,6,5,4,3,2,1,0,7,...,0
3) if the backlight is on maximum (actual_brightness == 7) and you echo e.g. 6 to the sysfs attribute (brightness) the brightness get set down, but if you echo 7 again back you don't get the old maximum brightness back. 
If you unload the module, reload thinkpad_acpi and echo 7 to sysfs attribute you get the maximum brightness set, but the keys don't work.

Okay, it seems that #304886 and #300340 fixed the brightness issue for all T60 and T60p, but brakes it for the X61 series.

Danny: if those laptops don't change the brightness level in hardware, would that mean our fdi patch in hal could cause this behaviour?

Helmut, Seife, Frank: Can you please test if old IBM machines (>T60) and the T61 is also affected?

Of course I meant old IBM machines (<T60).

Works fine on T43.

on a X60 here it works, but on a T61 i have the strange effect that brighntess is only controllable via software (thinkpad_acpi-interfaces/kpowersave etc.), but not via the brightness keys.

Maybe we should try to reproduce this with an old kernel (which doesn't include thomas patch).

Frank, do you use the fbdev driver on your T61? If yes, please look also at #304979.

no, i'm using the new intel driver. 

(In reply to comment #2 from Christopher Stender)
> Danny: if those laptops don't change the brightness level in hardware, would
> that mean our fdi patch in hal could cause this behaviour?

No, because use the keys lead to change the actual_brightness sysfs attribute also if HAL/KPowersave/Powersave are not running. Looks as if the kernel try to set the brightness, but it didn't work.

(In reply to comment #6 from Christopher Stender)
> Maybe we should try to reproduce this with an old kernel (which doesn't include
> thomas patch).

It worked with the Beta2 kernel which I used before on the X61t

ok, then the problem on the T61 seems to something else as there it also doesn't work with the beta2 kernel.

*** Bug 297155 has been marked as a duplicate of this bug. ***

Some notes from Bug 297155. On a R61 (internally almost the same as T61), the Fn-brighter/darker work with beta 1, 2 and 3. There seem to be 16 brightness steps, but /sys/class/backlight/thinkpad_screen/actual_brightness shows 0,1,2,...,7,0,1,...,7; setting the brightness between 0 to 7 works, but one remains in the upper or lower half.

specific to some limited hardware, not critical for 10.3

This is a huge mess.
Let me describe the problem:
The ThinkPad Module specific solution does not work anymore for T60/T61 and similar (R6X/Z6X/...), the solution for T60 family (which we added) is a very ugly workaround that should not exist. The Hardware is poked directly instead making use of the specified functions and the amount of brightness levels is hardcoded to 7 (but there are e.g. 15 levels for T61), this all is a mess.
There is a Modul (video driver) which supports all this as defined by spec. T60/T61 also supports this (one has reported the video Modul working, it did not for Andreas, maybe it does if thinkpad module has not written on the HW directly). But we cannot make use of this as the brightness control between both driver would interfere and we need the ThinkPad Modul for docking and the bay.
If this is not critical, I like to close this won't fix at the moment. People will start on fixing up video Modul pretty soon I expect as this seem to be used in Vista, but it's definitely too late for 10.3.

-> Closing for now.

Wrong resolution..., now it's won'tfix

I reopen the bug. We need to fix this problem, it's no option to have broken brightness support on ThinkPads.

Created attachment 172830 [details]
blacklist 61 models to use 15 brightness levels

Possibly I forgot a refresh on above patch and it might not build you find kernel rpms here:
stravinsky-trenn-5 (i386)
stravinsky-trenn-6 (x86_64)

You should see a message that a [XTZ]61 ThinkPad model got detected.

Thomas, should this kernel work with the 60 and 61 series?

Okay, please test the kernel below on some machines.

/mounts/work_mbuild/stravinsky-trenn-12 (x86_64)
/mounts/work_mbuild/stravinsky-trenn-13 (i386)

Thomas: I got the information that the Z61m only supports 7 brightness levels. What about matching on X61*|T61*|R61*?

Does not help on my machine (x61s) at all.  Feel free to come to my office and check.

Yes we cannot match against [TXRZ]61, we need to detect the amount of brightness levels.
Alexej had a nice idea: Trying increase brightness level until it does not change anymore, but then you write an undefined value... Maybe we find a EC register or simply a string buffer that supports the amount of brightness levels or similar.
I will come up later or tomorrow, let's try a bit together on several models then...

Alexander Schneider verified the patch above working, so this really seems to only be a 8 vs 16 brightness levels problem.

On my T60 (model 2007-fug) brightness control also ceased to work after upgrade to beta3 and still didn't work in rc1.
Two issues
1. tpctl, tpctl-kmp and tpb were missing; after install and reboot brightness control works now.

2a. When pressing Fn-Pos1 (brightness up), /var/log/messages shows
Sep 23 13:57:54 linux powersaved[3610]: WARNING (continueEvent:248) Could not execute program /usr/lib/powersave/scripts for event other: No such file or directory
Sep 23 13:57:54 linux logger: thinkpad_acpi_events Custom event script for ThinkPad thinkpad_acpi driver
Sep 23 13:57:54 linux logger: thinkpad_acpi_events Fn+Home hotkey: keycode 128 serial 4112. action: brighter display

2b. When pressing Fn-End (brightness down), /var/log/messages shows
Sep 23 13:59:11 linux powersaved[3610]: WARNING (continueEvent:248) Could not execute program /usr/lib/powersave/scripts for event other: No such file or directory
Sep 23 13:59:11 linux logger: thinkpad_acpi_events Custom event script for ThinkPad thinkpad_acpi driver
Sep 23 13:59:11 linux logger: thinkpad_acpi_events Unidentified hotkey: keycode 128 serial 4113. action: log event

(In reply to comment #24 from Klaus Kaempf)
> On my T60 (model 2007-fug) brightness control also ceased to work after upgrade
> to beta3 and still didn't work in rc1.
> Two issues
> 1. tpctl, tpctl-kmp and tpb were missing; after install and reboot brightness
> control works now.

This mustn't be needed. I even wonder why we still ship those tools. I remember Seife somewhen talked about some very old models where this is needed. Maybe he knows more...


> 2a. When pressing Fn-Pos1 (brightness up), /var/log/messages shows
> Sep 23 13:57:54 linux powersaved[3610]: WARNING (continueEvent:248) Could not
> execute program /usr/lib/powersave/scripts for event other: No such file or
> directory

This error message is somehow misleading and smells like a update issue. I suspect a value in /etc/powersave/events:EVENT_OTHER that became superfluous with 10.3. It's already filed as bug 304976. Nevertheless, can you please post the value of that configuration variable?

> Sep 23 13:57:54 linux logger: thinkpad_acpi_events Custom event script for
> ThinkPad thinkpad_acpi driver
> Sep 23 13:57:54 linux logger: thinkpad_acpi_events Fn+Home hotkey: keycode 128
> serial 4112. action: brighter display

That's just the log. thinkpad_acpi_events script shouldn't do anything with brightness.

EVENT_OTHER="hotkey_handler"


Btw, brightness control only works on fresh reboot, after wakeup from suspend-to-disk it no longer works.

Do you use the fbdev driver? If yes, this is a known issue (304979).

Yes, I have to use the fbdev driver for now. Thanks for the information!

So you can confirm that brightness (without tpctl, tpctl-kmp and tpb) is working on your T60 after a fresh reboot?

I can confirm that brightness control with fbdev is working after fresh reboot. I have not tested without tpctl though.

Okay, then we need a fix for X61*, T61*, R61*.

Lenovo T60 is _not_ affected.

Yep. But we shouldn't overreact now.
For 10.3 GM it is too late. This does not affect major machine functionality, the user is still able to use the machine smoothly.

I try to come up with a Lenovo ThinkPad only solution making use of the video extension ACPI spec functions. Not sure yet whether everything will work out as expected, but as they update their BIOSes because Vista is using those, this is the only sane way to provide a stable brightness support also for future.

I come back as soon as I have something. As much Lenovo ThinkPads as possible should be tested then. Fortunately the patch will only get active on Lenovo ThinkPads, therefore I think the risk of breaking a machine is low enough with some testing of different ThinkPads.
-> Fingers crossing is appreciated :)

-> Still assigned to Alexey -> will take over. Would be great if you could give this a review as soon as I have something.

Add the X41 Tablet to the list (technically the first Lenovo Thinkpad).  For me, Fn+Home/End always works for changing the brightness, but thinkpad_acpi, and consequently kpowersave, etc have problems with it.  After installation kpowersave claimed controlling brightness was not supported for my hardware, and indeed the /proc/acpi/ibm/brightness and /sys/class/backlight/thinkpad_screen interfaces were missing.  grep thinkpad_acpi /var/log/boot.msg produced:
<6>thinkpad_acpi: ThinkPad ACPI Extras v0.14
<6>thinkpad_acpi: http://ibm-acpi.sf.net/
<6>thinkpad_acpi: ThinkPad BIOS 75ET35WW (1.06 ), EC 75HT18WW-1.00
<6>thinkpad_acpi: IBM ThinkPad X41 Tablet
<3>thinkpad_acpi: CMOS NVRAM (5) and EC (0) do not agree on display brightness level

It seems that Fn+Home/End use the NVRAM interface, and this works even in the BIOS before the OS is loaded.  If you make a note of the EC setting, reboot, and before  the OS loads, use Fn+Home/End to make the NVRAM setting match the EC setting, then the thinkpad_acpi module will load without errors.  You can also use Fn+Home/End to change the brightness to the same level as the EC on a running system, and then reinsert the thinkpad_acpi module.  After this the /sys and /proc interfaces will be there, and everything works fine until you use Fn+Home/End to change the brightness.  As soon as you do, cat /proc/acpi/ibm/brightness returns:
level:          unreadable
cat /sys/class/backlight/thinkpad_screen/actual_brightness returns:
-5
If you use Fn+Home/End to change it the brightness back, then you can use the /proc and /sys interfaces again, and everything works normally.  Using the /proc and /sys interfaces to control the brightness properly updates both the NVRAM and EC, but Fn+Home/End only update the NVRAM.  Hopefully this info is helpful.  ~Loki

The Fn-Home/Fn-End keys does not work on T42 laptops in GNOME with openSUSE 10.3 If I am switching to a VT with CTRL-ALT-F1 than I can change the brightness. Switching back to the GNOME desktop with ALT-F7 I have the correct brightness. If I am trying to change with the keys from the GNOME desktop the brightness then is a total mess: it seems that I have only level 0 and 1. However on the terminal I have 0..6. Changing the brightness with the GNOME Brightness Applets it also works.

I have the same bug than #34 on my t60p but if I don't start gnome-power-manager when I login I have no more problem.

Confirmed #35: killing gnome-power-manager the brightness works perfectly in GNOME. This must be a gnome-power-manager bug.

I have the same problem on a thinkpad x61 with openSUSE 10.3 (final + updates)
using gnome, running kernel 2.6.22.16-0.2-default on x86_64.

But: killing gnome-power-manager does *not* help in my case.

I notice there are (at least) 3 indicators of brightness:

/sys/class/backlight/thinkpad_screen/brightness
/sys/class/backlight/thinkpad_screen/actual_brightness
/proc/acpi/ibm/brightness

The second and third are cycled through 0 to 7 twice when pressing <Fn>+<Home>/<End> (and the OSD also cyles), 

but only when the brightness applet is used, the first changes (along with the other two) and only then the actual brightness changes.

Cheers, Michael

more precisely, it is a Thinkpad X61s (not x61).

I really don't want to spend any more time on this for 10.3.
Lenovo changed the mechansim twice on latest XY60 and XY61 models.
From 7 to 15 brightness levels and from Lenovo specific to ACPI specified brightness behaviour. This is not only model, but also BIOS dependent.

It would be great if you install latest 11.0 release into a small, free partition...
There it's worth to provide Henrique (thinkpad driver maintainer) with as much info as possible and pre-debug this with a novell bugzilla entry.
Henrique is doing backports of his latest code to several older kernel versions.
I could integrate his backports..., but IMO too much work has been done here and there is risk to break other (especially older machines).

For now I backported the latest thinkpad_acpi driver version to our 2.6.22 kernel and you can fetch a kernel from here (i386/x86_64)
ftp.suse.com/pub/people/trenn/latest_thinkpad_driver_10_3_kernel

Please try it out (as much people as possible).
If reports are possitive, I will attach the patch here. I will still add some people for review and discussion whether it makes sense to add such a huge thing to the 10.3 kernel then.

As said, please also give 11.0 a test in time. In Beta phase it is still easy to add fixes, as soon as the product is released, it's not.

Pleas also update to the latest BIOS revision of you thinkpad model. Lenovo has done some Linux fixups in their latest BIOS releases!

Thomas, I tested your kernel with the following setup:

openSUSE 10.3 (all updates installed)
Thinkpad T60 (2007-VCE)
ATI Mobility X1400 (using the fglrx driver)
BIOS Revision: 2.32

Changing the brightness with Fn keys works perfectly but the interface in /sys/class/backlight disappeared and kpowersave isn't able to change the brightness level.

Please try with module param:
brightness_enable=1
e.g. add in /etc/modprobe.conf:
options thinkpad_acpi brightness_enable=1

Hmm, this could be set default in 10.3, as we do not use the video module there and interference cannot happen...

If this still does not work try with module param:
debug=0xffff
and attach dmesg output.

Yes, with the option line in modprobe.conf.local everything works great. Nevertheless it works for me also with 10.3 GM so we need some more reports from users with a newer or older model.

Created attachment 197471 [details]
Patch of latest thinkpad-acpi backports from Henirque adjusted for 10.3

The patches from Henrique (maintains thinkpad driver and backports changes) are of good quality in general and he has a broad community checking patches for him.
I do not like the size of his backports. He is backporting every variable name change and therefore the patches are huge in size.
They would probably be an improvement, but could trigger a regression...

*ping*

(On my system (R61) with Factory it works now also in kpowersave; before the Fn keys worked, but kpowersave only accessed 7 instead of 16 brightness levels. Others had bigger problems and I don't know whether it now works for them.)

So, is this still valid? If it's working for 11.0 and per comment #40 it seems we don't want it for 10.3, does this really need anything in gnome-power-manager?

This is still broken in 11.0 (factory/x86_64) for me:

I have just commented a new bug for 11.0 with an updated description: 
See Bug #386541.

Cheers - Michael

*** Bug 386541 has been marked as a duplicate of this bug. ***

*** Bug 381549 has been marked as a duplicate of this bug. ***

Hmm, since I have a somewhat different behaviour with 11.0 (factory)
on my x61s as described in bug #386541, which is now marked as a
duplicate of this one, I am copying the desription posted there:

-------------------------------------------------------------------
I am using gnome from factory repos with the x64_64 architecture on an x61s.

Problem description: 

The brightness keys (Fn+Home/End) do not work properly.
An OSD pops up but behaves strangely:
As the progress bar proceeds, the brightness of the display
stays the same, but once the max is reached, pressing Fn+Home
repeatedly starts an oscillating behaviour: The OSD bar jumps
between 50% and 100% and so does the brightness. Similar
phenomenon for Fn+End - bar oscillating between 0% and 50%.

The gnome brightness panel applet is working correctly though!

Previously, in 10.3, this oscillating behaviour did not happen.
But the bar ran from 0% to 100% twice - starting over at 0% once
100% was reached the first time. 

This seems to be related to the fact that the thinkpad acpi seems
to have 15 brightness steps instead of 7. (Previously, in 10.3,
the brightness applet only provided 7 steps, now this seems to have
been fixed: the brightness applet provides all 15 steps.)

nirvana:~ # cat /sys/class/backlight/acpi_video1/brightness
15
nirvana:~

here is something strange:

nirvana:~ # cat /proc/acpi/video/VID1/LCD0/brightness 
levels:  100 100 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 100
current: 100
nirvana:~ # 

the brightness apple walks all steps from 20 (0) to 100 (15).
the Fn-Keys oscillate between 20(0) and 55(7) at the low end
and between 55(0) and 100(15) at the high end. In the middle
they stick at 55(7).
----------------------------------------------------------------------

Cheers - Michael

I'm not sure this bug has the right severity? IMHO critical and opensuse 11.0 should be better.

(In reply to comment #53 from Tom Meyer)
> I'm not sure this bug has the right severity? IMHO critical and opensuse 11.0
> should be better.
> 

Thanks for the comment.
I also think that bug #386541 shouldn't have been closed as duplicate
since it is not exactly the same phenomenon.
And it is 11.0.

Cheers - Michael

moving to 11.0

ping...

Any progress on this issue?

ping...

so there has been some progress:

The situation has become worse.
The progress bare is now oscillating wildly.

I'm running a T60 with OS 11.0.

I've "upgraded" from SLED 10 to OS11.0 and have lost my display control using Fn+Home/Fn+End. Display adjustment worked fine in SLED 10. The level indicator appears, but the screen does not change.

A related symptom in case it helps... The screen brightness does not change when I switch between power/battery mode. But even stranger... the intensity of my display honors the settings of shutdown. So whatever mode the last SHUTDOWN was in is what is displayed on boot up. (Regardless of what mode i am actually in during boot up)

I will find another bug to report my additional info under... but in case this behaviour is helpful while addressing this bug... there it is.

This will and is fixed for 11.1.
It would be great if you could give it a test.
It will not get fixed for 11.0 as the changes are too intrusive.

Thanks ! I will test once the e1000e bug is fixed ...

(Adapting bug status ;-))

i know this is labeled fixed, just wanted to let you know... I installed the latest ATI drivers and my backlight behaves properly. Powersave mode works, and the function key works for brightness.

Perhaps it's the generic drivers? anyway, I'm good now.