Max brightness is not max brightness

With my Thinkpad X24 (ibm not lenovo but well) i have no problem with brightness.
The max - ultra high - brightness is only set when the battery is on AC.

The problem occurs for me regardless of whether or not it is on AC power.
I have read people with apple laptops saying that (not specific to hardy) their brightness settings on the mac should go up to 125, or something like that, whereas gpm only allows it to go up to 100. I don't know whether the same thing might be possible with a thinkpad.

The value for max brightness is gotten from HAL. Reassigning there.

Thank you for this bug report. However,I think the developers need a little bit more information before they can decide what has to be done about this bug. Please attach the output of those commands and files after the bug occured:
/var/log/kern.log
lshal

Before the bug occurs, please execute this command: lshal -m
After the bug has occurred you can kill th e process. Please copy and paste the output generate by this command into a file and attach that too.

Thanks

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

I'm seeing this in Hardy 8.04 on my X60, with and without AC power. (Each mode has a different max brightness level, but neither is attainable.)

- The max brightness setting in the Power Manager Brightness Applet (gnome-power-manager) is lower than the actual max brightness.
- Pressing the Fn+Home (brightness up) key causes the screen to briefly flash full brightness but immediately return to gnome-power-manager's false max brightness.
- True max brightness can be temporarily achieved with the command "echo 4 > /proc/acpi/ibm/cmos" but any subsequent brightness control via gnome-power-manager returns it to the false max brightness.

I don't know what this means in terms of what's happening on a lower level. (I'm just an end-user who happens to be more productive when out in the sun.)

Fn+Home (brightness up) five times
Fn+End (brightness down) five times
Fn+Home (brightness up) ten times

Provided missing information.

This is probably a bug in gnome-power-manager, so I'm reassigning it to that package. Please attach the output of the commands 'gconftool --recursive-list /apps/gnome-power-manager' and 'gnome-power-bugreport.sh' in separate files.
Please execute this command in a terminal: dbus-monitor --session "type='signal',interface='org.freedesktop.PowerManagement.Backlight'"
try to adapt the brightness at the gnome-power-managent applet way, the laptop buttons and the terminal way and post the things that appeared in the terminal here, of course pasted in a file.
Thanks in advance.

Thanks. Here's the dbus-monitor output, with annotations in angle brackets.

In creating this I've also discovered that, just like the max brightness level, the minimum brightness is also not attainable via gnome-power-manager controls but can be set on the command line. Have a look at the attachment for details.

It turns out that this bug is a duplicate of another bug. Please keep an eye on that bug for more information.
Thank you for reporting. ;)

Oops.
I'm sorry. I confused this bug with another report, so I accidentally marked it as a duplicate. I'm sorry for the mail noise. I'm going to try to forward it upstream to the gnome-power-manager as soon as possible. You probably also have to the problem of bug 212733 , so maybe you want also to keep an eye on that.

I believe I'm seeing the same bug on a Lenovo Thinkpad Z61p. Specifically - If I increase the brightness with Fn+Home, it works up until nearly the maximum. but for the last step, pressing Fn+Home momentarily increases the brightness to maximum, then it reverts to a lower level (i.e. the screen flashes bright). Killing the gnome-power-manager process allows Fn+Home to increase the brightness to maximum normally.

Please let me know what additional information might be useful.

Environment: Hardy Heron, latest updates.

Some more information: It looks like the default ACPI backlight support is mis-detecting the range of levels:

root@z61p:~# cat /sys/class/backlight/acpi_video0/max_brightness
5

These fake levels 0 to 5 correspond to real levels 1 to 6, omitting the real minimum (0) and maximum(7).

If I add the backlight_enable=1 module parameter to thinkpad_acpi ("enable thinkpad-specific acpi support despite the fact there seems to be working generic acpi support"), I get a new entry in sysfs, /sys/class/backlight/thinkpad_screen/ - this one correctly reports max_brightness as 7 and allows setting the brightness to the missing levels.

So, perhaps the real bug is in whatever the default kernel acpi support uses to decide on the number of levels?

I experience similar results with my Lenovo T61p on CentOS 5.3

after sliding gnome power manager "running on AC" brightness to max:

# cat /proc/acpi/ibm/brightness
level: 7
commands: up, down
commands: level <level> (<level> is 0-15)

after using Fn + Home to increase brightness to max:
# cat /proc/acpi/ibm/brightness
level: 15
commands: up, down
commands: level <level> (<level> is 0-15)

# cat /sys/class/backlight/acpi_video0/max_brightness
cat: /sys/class/backlight/acpi_video0/max_brightness: No such file or directory

# cat /sys/class/backlight/thinkpad_screen/max_brightness
15

My temporary workaround:

1) Create a script containing the command to increase brightness (echo 4 > /proc/acpi/ibm/cmos) and make it writable only by root.
2) Give permission to my everyday user account to execute the script via sudo without password authentication.
3) Create a hotkey that executes the script via sudo.

My brightness up key is Fn+Home, so I make the above hotkey Ctrl+Alt+Home.

This looks fixed for me (on Lucid, and probably before), someone please re-open it if you disagree.