[ASUS 1005p] keys for adjusting display brightness don't work as expected

This is the same in the karmic UNR live CD

Using Ubuntu 9.10 and having this same issue. The behavior seems that brightness goes from 100%, 80%, 90%, 95%, 93%, 95%, 93%, 70% and so on just by trying to increase the brightness (FN+F6).

Not sure how this could be fixed. Iif I can be of any assistance providing further information, feel free to let me know.

Also noteworthy: The panel brightness applet will reproduce the same behavior.

I tried to do some triaging in line with what's written on https://wiki.ubuntu.com/Hotkeys/Troubleshooting

First, I can confirm incade's findings that changing the brightness with the hotkey combination did change the display brightness just the same as the Power Management applet. But, to my surprise, only the applet changed the value in /sys/class/backlight/acpi_video0/*brightness or /proc/acpi/video/VGA/LCDD/brightness. The hot key combination changed the display's brightness but did not affect /sys or /proc it seems.

On to the xev test. I had to "killall gnome-settings-daemon gnome-power-manager" and then went on to run xev from the command line with the given arguments. There never were any key events recorded (assuming the sed statement in the wiki is correct). Following the instructions in /usr/share/doc/udev/README.keymap.txt up to step 3 did not produce any keycode with /lib/udev/keymap. acpi_listen finally gave me an output: "hotkey ATKD 0000002d 0000000c" for the hotkey to lower screen brightness and "hotkey ATKD 0000002e 0000000c" for increasing it.

-> moving over to kernel bugs.

targetting to lucid, I think we want to support this popular netbook properly at release time in the latest

Upon Zhang's request in the upstream ticket I reran the hotkey troubleshooting steps from the wiki. It now turns out this may be a Gnome bug after all?

Tthe backlight changes brightness when the hotkeys are pressed, but it's changing non-linear, seemingly erratic. When I press the hotkeys, the value in /sys/class/backlight/acpi_video0/actual_brightness decreases and increases monotonically by a value of 2 per press. Maximum is 15, minimum is 0. So, you might see 10-12-14-15-13-11 or 3-1-0-2-4. The real display brightness does not seem to have anything to do with it. When I reran the test with xev and sed from https://wiki.ubuntu.com/Hotkeys/Troubleshooting and pressing the Hotkeys a few times, this is what I got

keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 64 = (keysym 0xffe9, Alt_L), state = 0x0

Keypresses appear double, IOW, I press up once and down once before closing xev
with Alt+F4.

adding acpi_osi=Linux to the kernel boot parameters seems to fix or at least work around this issue

I don't see any related entries in /apps/gnome_settings_daemon/keybindings with gnome-editor

I've had this bug with my Asus Eee PC 1005PE and UNR Karmic too. "acpi_osi=linux" fixes the problem with Fn+F5/Fn+F6, but brightness still sometimes resets to minimum by itself.

Seems like this bug is duplicate of #512567

bug 512567 does indeed have some good information

I have a ASUS 1005PE and have the same issue.
I _do not think this should be fixed_ the issue is a faulty BIOS, see:
http://groups.google.com/group/linux.kernel/browse_thread/thread/3c3cf40adea1f089
I think ASUS should be forced/encouraged to produce a BIOS that does not rely on an OSI string. There non-complient BIOS is the issue, and if this is patched, it wont make them fix the issue.

There are a lot of faulty BIOS's out there...and besides, the 1005PE
didn't work right until a BIOS upgrade anyway. It would be nice of
them to make it just work, but adding an OSI string didn't seem like a
big burden. My 1005PE works great now. Did I mention 6-8 hours of
battery life? If I could get 5 sec boot time, I'd enter 5 OSI strings
if necessary.

On 5/11/10, Dion Blundell <email address hidden> wrote:
> I have a ASUS 1005PE and have the same issue.
> I _do not think this should be fixed_ the issue is a faulty BIOS, see:
> http://groups.google.com/group/linux.kernel/browse_thread/thread/3c3cf40adea1f089
> I think ASUS should be forced/encouraged to produce a BIOS that does not
> rely on an OSI string. There non-complient BIOS is the issue, and if this is
> patched, it wont make them fix the issue.
>
> --
> hotkeys adjust display brightness non-monotonically on new Asus pinetrail
> netbooks (1001P, 1005P, 1005PE)
> https://bugs.launchpad.net/bugs/513921
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I'm always prefer solutions to ugly workarounds, but in the meanwhile "acpi_osi=linux acpi_backlight=vendor" looks better than nothing. Anyway, Ubuntu is the Linux for human beings. I don't think an average human being care of who's responsible for the bug - Asus or Linux. It just works or not (and if it just works in Windows and just don't work in Linux, in user's perspective it's Linux's fault).

Dion, thank you for your comment. I was wondering if there is an open ticket or something like it on ASUS' side. If their BIOS creates problems for Linux, I'd like to let them know that I expect a proper fix.

updating to the recently released version 1103 of the BIOS fixed the non-linearity problem. Although to be able to get maximum brightness it is still necessary to pass the boot-time parameters.

Rolf Leggewie, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

This hardware has long since bitten the dust over here.

Closing