Brightness function keys reversed

[mxyzptlk]

Binary package hint: gnome-power-manager

Similar to -- but not the same as -- other bug reports about brightness issues on laptops.

Simply put, Fn+up does what Fn+down should do (makes the screen dimmer), and Fn+down does what Fn+up should do (make the screen brighter).

It also seems to skip a brightness level (only five brightness levels). There is no slider for screen brightness under System - Power Manager.

Release: Ubuntu 8.04 beta
Package version: 2.22.1-1ubuntu4
Expect to happen: Fn+up makes screen brighter, Fn+down makes screen dimmer
What actually happens: Fn+up makes screen dimmer, Fn+down makes screen brighter.
Kernel: 2.6.24-16-generic
Gfx card: Intel GM965/GL960
Machine: Lenovo Ideapad Y510

Not sure if I need to post more info.

[Pedro Villavicencio (pedro)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please attach the resulting log file of: gnome-power-bugreport.sh &> gpm.log to the report? You might also want to take a look to the Debugging instructions located at https://wiki.ubuntu.com/DebuggingGNOMEPowerManager for submit any other logs related to your problem.Thanks in advance.

[mxyzptlk (mxyzptlk)]

The gpm.log is attached.

[mxyzptlk (mxyzptlk)]

Additional info:

This was noticed just now while in a meeting and on battery with my laptop.

Same reversal with the Fn keys as above.

Power Management is set to dim the display when idle.

The display didn't automatically go to the dim setting when on battery, it automatically went to the brightest setting. Had to physically dim the display when on battery.

When my laptop went idle, it should have dimmed. However, it again went to the brightest setting instead of a lower setting.

Is this an issue with acpi? It seems all the wires are there, just crossed.

[dBera (dbera-web)]

Same issue here. Hardy + all available updates.

Why is the status of this bug incomplete ?

[Pedro Villavicencio (pedro)]

yes it looks like an acpi issue, re assigning.

[riu (stanray)]

found on ubuntuforums.org:
http://ubuntuforums.org/showthread.php?t=956675
http://ubuntuforums.org/showthread.php?t=925959

[Michal (michal-redhat-bugs)]

Created attachment 322840
lshal -l

Description of problem:
Controll of brightnes in inverted on this model of ThinkPad (according to thinkwiki, its using IdeaPad firmware). Adding more backlight with Fn+End causes the brightness go down. Fn+Home vice versa. But the logic of controlling backlight is inverted. So the gnome brightness indicator is comming down when brightness is increasing and up, when decreasing. Also, when inactive for several minutes, powersaving sets brightnes to maximum, as it may think, its minimum.

Version-Release number of selected component (if applicable):
up-to-date rawhide
hal-info-20081022-1.fc10.noarch
hal-libs-0.5.12-12.20081027git.fc10.i386
hal-0.5.12-12.20081027git.fc10.i386

How reproducible:
always with enabled X

Steps to Reproduce:
1. press Fn+Home (with arrow marking down direction)
2. brigtness go up

1. on battery, leave the terminal inactive for several minutes with enabled power saving by decreasing brightness.
2. look ad the difference on the screen brightness

Actual results:
Backlight controll is inverted

Expected results:
Backlight will work according its logic

Additional info:
# dark screen
[root@fight ~]# echo 13 > /sys/class/backlight/acpi_video1/brightness
# bright screen
[root@fight ~]# echo 0 > /sys/class/backlight/acpi_video1/brightness

[Lubomir (lubomir-redhat-bugs)]

Created attachment 323670
Patch to fix the brightness issue on ThinkPad SL300

This fixes the issue. Reassigning to kernel.

[Lubomir (lubomir-redhat-bugs)]

Works for me. Thanks for fast fix.

btw, this may also apply to all Lenovo SL series.

[Michal (michal-redhat-bugs)]

Works for me. Thanks for fast fix.

btw, this may also apply to all Lenovo SL series.

[Lubomir (lubomir-redhat-bugs)]

/me makes a note to himself to drop bugzilla login cookie when working on someone else's lappy, since the result may sound somewhat strange :}

[Bug (bug-redhat-bugs)]

This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Gary Trakhman (gary-trakhman)]

there is a fix...
performs a sort in video.c in kernel driver

https://bugzilla.redhat.com/show_bug.cgi?id=470465

https://bugzilla.redhat.com/attachment.cgi?id=323670

please implement this.

[Daniel T Chen (crimsun)]

(and/or hal-info)

[Omegamormegil (omegamormegil)]

Confirmed per comments

[riu (stanray)]

This bug seems to be fixed for Acer TM 2424 in Jaunty Jackalope, 9 march. The brightness bar does not appear and the brightness keys work properly.

[Nick Booker (nmbooker)]

Because the patch described above (from Fedora) is for the kernel, I've re-assigned to the kernel team.
The patch worked for me when I tried it.

[riu (stanray)]

This bug is again here for Acer TM 2424 in Jaunty Jackalope, 24 april. But now brightness keys are not just reversed, brightness is uncontrollable like a tug-of-war. Brightness decreases and at the same it increases and then again it decreases or increases. It can be controlld at welcome screen and while booting. However, while booting on AC power it sets itself to maximum (not sure this is a bug, but I prefer to use the value of brightness stored in bios, like Ubuntu 8.04 does). It is better to delete the brightness drivers thatconfuse everything related to brightness and leave built-in brightness controls that work without any external drivers.

[Keng-Yu Lin (lexical)]

Unfortunately it seems this bug is still an issue. Can you confirm this issue exists with the most recent Lucid Lynx 10.04 release - http://cdimage.ubuntu.com/releases/lucid/alpha-2/. If the issue remains in Lucid, please test the latest 2.6.32 upstream kernel build - https://wiki.ubuntu.com/KernelMainlineBuilds . Let us know your results.

We need additional information to further debug this issue. Please run the following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach kernel debug information to this bug report.

apport-collect -p linux <bug#>

[Keng-Yu Lin (lexical)]

Checked this patch is already upstream and fixed since jaunty-updates.