brightness changes twice when using hotkeys

I receive the exact same issue on a Dell Inspiron 1521.

hald verbose output when pressing "brightness down" hotkey:

[8173]: 02:26:17.688 [D] addon-acpi.c:195: event is 'video LCD 00000087 00000000
'
[8173]: 02:26:17.746 [D] addon-acpi.c:195: event is 'video LCD 00000087 00000000
'

Killing gnome-power-manager or stopping hal has no effect in this bug.

It's probably related to this bug upstream: http://bugzilla.kernel.org/show_bug.cgi?id=9614

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

The issue remains.

snifer@snifer-laptop:~$ dpkg -l | grep linux-image-2.6.27-
ii linux-image-2.6.27-1-generic 2.6.27-1.2 Linux kernel image for version 2.6.27 on x86

I confirm that I have this problem on Ubuntu Hardy with a DELL XPS M1330 (shipped with Ubuntu).

I only have 3 brightness levels... I blacklisted video as suggested in this thread (http://ge.ubuntuforums.com/showpost.php?s=d308ad71f7d328052c8f6e0b31dd1f6c&p=5569887&postcount=2) and it now works as expected (I have 8 brightness levels).

I can confirm this on fully updated 8.10 Beta with lenovo Thinkpad X60s

My situation with Brightness Up:

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
14:27:36.724: computer_logicaldev_input_5 condition ButtonPressed = brightness-up
^C
$ acpi_listen
ibm/hotkey HKEY 00000080 00001010
video LCD0 00000086 00000000

$ xev
KeyPress event, serial 70, synthetic NO, window 0x3e00001,
    root 0x7d, subw 0x0, time 1609093, (753,714), root:(761,762),
    state 0x0, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Is there anything I can do?
KeyRelease event, serial 70, synthetic NO, window 0x3e00001,
    root 0x7d, subw 0x0, time 1609093, (753,714), root:(761,762),
    state 0x0, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

X11 keyboard is set to xev

root@x60:~# showkey
kb mode was RAW
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
keycode 225 press
keycode 225 release
^Ccaught signal 2, cleaning up...
root@x60:~# showkey -s
kb mode was RAW
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
0xe0 0x54 0xe0 0xd4

I can confirm it on Hardy, running kernel 2.6.24-19-generic on Inspiron 1520.

I found that the problem is kernel related:
When pressing Fn+Up/Down once, `cat /proc/apci/event' gives every event twice. (Catting /proc/apci/event is possible only after killing acpid.)

Monitoring key presses with xev or showkey is of no use. I inspected acpid source code and it works like this:
- acpi event is generated by kernel
- acpid reads /proc/acpi/event and for every event read it runs a script (e.g. /etc/acpi/video_brightnessup.sh)
- this scripts runs acpi_fakekey with some argument that passes a synthetic key press to the X server
- X, KDE or Gnome (whatever takes the responsibility) runs an action bound to the key press

So, if the event is generated twice by kernel for one Fn+Up/Down key press, KDE's or Gnome's action is run twice.

What more information can I provide?

A workaround http://ge.ubuntuforums.com/showpost.php?s=d308ad71f7d328052c8f6e0b31dd1f6c&p=5569887&postcount=2 works for me also. What are the side effects?

Hi Juan,

A patch recently went into the Intrepid kernel as post release update:

commit 8948ecffc8c56009c4580e684d6e385b2bad96df
Author: Matthew Garrett <email address hidden>
Date: Fri Aug 15 13:54:51 2008 -0400

    Input: atkbd - expand Latitude's force release quirk to other Dells

    Bug: #284066

    Dell laptops fail to send key up events for several of their special
    keys. There's an existing quirk in the kernel to handle this, but it's
    limited to the Latitude range. This patch extends it to cover all
    portable Dells.

I'm curious if it might also resolve this issue you have. The kernel with this patch is still making it's way into the intrepid-proposed repository. However, it would be great though if you could test -proposed once it's there - https://wiki.ubuntu.com/Testing/EnableProposed .

I have a couple of problems with my Lenovo X60 special keys - which is an up-to-date intrepid, but was upgraded thru various alphas. I freshly installed 8.10 on a spare lenovo T61 - all works great there. So I'm going to reinstall my X60 as soon as possible and will report here then.

I'm sorry, my laptop has been stolen so I can't test this anymore.

This looks to have been finally fixed in the upstream commits rooted at as below, which is part of the v2.6.28-rc5 rollup:

    22c13f9d8179f4c9caecfcb60a95214562b9addc

so for Jaunty this should be fixed in the alpha2 snapshot which should contain this kernel.

For intrepid these patches do appear to apply cleanly to our kernel. So we may be able to backport them to that release. In order to do that we would need to get the functionality tested. To that end I have compiled them up and uploaded some test kernels. Could anyone who has hardware affected by the double increase/decrease in brightness retest with kernels from the URL below. Please ensure any testing is without any of the workarounds.

    http://people.ubuntu.com/~apw/lp257827/

Following the latest -proposed release of 2.6.27-10.20 I have rebuilt these test kernels based on that snapshot. Replacement .deb's are available at the URL above. Look for the 2.6.27-10.20lp257827apw1 images.

SRU Justification:

Impact: Bad brightness handling on a wide range of laptops, plus boot crashes on a number of Samsung laptop.

Fix Description: direct backport of a group of ACPI changes which sort out backlight handling plus prevent non-existant display devices being detected as real.

Patch:
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=6620210fc1da8a39db88281290a0271d46e57283
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=ff8ad74bf82886a50cdc6b5ca0671dbe63e7f435
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=7279cb0e60d00b9fe0ca4292aacd6372f83c495e
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=2871e0ac9a33e81e9b4c68dd7e10c01ec452360f
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=971f09bdfb75a9923c61d99af3db1e006a8bc354
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=78da909520bf8169b7aa57729f5daade4daf76ef
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=56b51fa2eaf86599058dc905139d810fd847ea58
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=e525a3ca3b31b63144f177470dcf823bca381327
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=926f8037764bb44f52005f7ab7f946a62b005c91
    http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=4d7a929d3df4589ccb3c23f5ffb2774112c80a82

Risks: testing by a number of affected users has demonstrated successful boot and improvements in brightness handling.

TEST CASE: see bug report.

Based on testing on other bugs this fix has been pushed into the Intrepid tree.

We believe that the fixes indicated on this bug are already applied in Jaunty.

Works now correctly for intrepid-proposed with Lenovo X60s. Thanks a lot!

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I believe this update broke LCD brightness controls on a number of ThinkPad models (R61i, T61, X300).

See: http://ubuntuforums.org/showthread.php?p=6426872

Since the update I have another problem, see: bug 311716

@Jon Oberheide -- there is also a gnome brightness appplet update in -proposed which was supposed to fix brighness control on a number of machines. Was your testing there with just the -11 kernel or all of proposed.

@Andy Whitcroft, the -11 kernel broke brightness settings on my t61 as well, I reported it in bug 314119. I am running all of proposed but don't use the gnome-applet; setting it through gnome-power-manager did not work but does work with the -10.20 kernel. Manually echoing values into /proc/acpi/video/VID/LCD0/brightness also doesn't work, which didn't work in -10.20 either, but echoing values in /proc/acpi/video/VID1/LCD0/brightness (note VID1 vs VID) did work in -10.20 to change the screen's brightness, but the /proc/acpi/video/VID1/ path does not exist when the -11.22 kernel is rebooted,

@apw: per our discussion, I tried both separately blacklisting the video module and adding the brightness_enable=1 option to the thinkpad_acpi module.

Blacklisting the video module had no effect; adjusting brightness was broken entirely and even worse, the brightness was set at the lowest setting. g-p-m locked up entirely when trying to adjust the screen brightness.

Adding the brightness_enable=1 option to the thinkpad_acpi module options caused brightness settings to start working; g-p-m was able to adjust the brightness settings. Also, with that option, the directory /sys/devices/virtual/backlight/thinkpad_screen/ showed up, and writing values to the brightness file in that directory changed the display brightness.

Writing values to /sys/devices/virtual/backlight/acpi_video0/brightness had no effect in any of the kernels I booted (with the video module blacklisted, that path did not exist). When the -10.20 kernel is booted, there's also a /sys/devices/virtual/backlight/acpi_video1/ directory; writing values to the brightness file in that directory also adjusted the screen's brightness.

It was fixed for awhile after installing proposed updates, but yesterday I installed proposed, I think 2.6.27.11-14, and the double changing is back, which is funny since the changelog specifically mentioned FIXING backlight quirks. Is there an easy way to go back?

I can confirm what Michael Rooney said.
Proposed update solved it, but latest proposed update made the problem reappear. :(

@Michael Rooney, Guglielmo Cola -- what machines do you have specifically?

We are trying to sort out how this can be fixed properly for Jaunty. As a first step in that I have pulled down the latest modifications to the ACPI brightness support and applied them to the latest Jaunty kernel. If anyone who has had issues, whether they are fixed or not in the Intrepid -proposed kernels, could test these kernels and report back here that would help us evaluate these upstream fixes. Kernels can be found at the URL below:

    http://people.ubuntu.com/~apw/lp257827-jaunty/

Dell Inspiron 1520
running Intrepid Ibex with last proposed updates installed

On Mon, Jan 19, 2009 at 11:32 AM, Andy Whitcroft wrote:

> @Michael Rooney, Guglielmo Cola -- what machines do you have
> specifically?
>

I am on a Dell XPS M1330 with the Nvidia 8400.

The regression (bug 311716) has been fixed in the current -proposed upload (-11.24):

linux (2.6.27-11.24) intrepid-proposed; urgency=low

  [ Stefan Bader ]

  * Revert "SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control"
    - LP: #311716
  * SAUCE: acpi: Hack to enable video and vendor backlight implementations
    - LP: #311716
  * SAUCE: Force vendor backlight control on ThinkPad T61
    - LP: #311716

  [ Upstream Kernel Changes ]

  * Revert "thinkpad_acpi: fingers off backlight if video.ko is serving
    this functionality"
    - LP: #311716

Thus this should reintroduce the original bug reported here for many people. It seems we cannot properly fix this without causing regressions for other people. However, with the current -proposed kernel, you can now install local modalias rules to fix your system. (See above). Thus setting back to verification-needed.

Hi Martin! I am not familiar with modaliases, which may be why I don't see anything above that could help me. Is there any more explicit fix for users such as myself as Guglielmo? Is it anticipated that all users in our situation will have to discover and address this issue ourselves, or is a fix for us planned as well? I'll try Jaunty and report my findings. Would we be better off creating a new bug report? Sorry for all the questions :)

I've the same questions as Michael. :)

Hi Michael, Guglielmo,

if you use the latest Intrepid kernel from -proposed, could you try adding either

acpi_backlight=video
or
acpi_backlight=vendor

to your kernel parameters, when you boot? In theory one or the other should work for you.

Thanks Stefan, acpi_backlight=vendor did the trick for me! Are there any
plans to handle this automatically in any way and/or should Jaunty fix the
issue? I tried myself with Alpha 3 but amd64 installed fine though failed to
boot, and x86 froze on installing.

#78> Which one? The only patch I see in your comment #73 are for gnome-power-manager. Not a whole lot useful to a Kubuntu user ;)

I can confirm that executing "echo -n N | sudo
tee /sys/module/video/parameters/brightness_switch_enabled" corrects the issue within a logged in X session, but leaves the TTYs and GDM unable to control the screen brightness.

yes, with my patch it works in GNOME and also TTY, KDE may use same system of fixing

I have put Pavol's patch in a PPA here: https://launchpad.net/~brian-rogers/+archive/power

Just run
sudo add-apt-repository ppa:brian-rogers/power

And then update your system to try it out. It also contains a patch to provide battery life estimates on laptops that don't normally get them.

The patch didn't help with the double increment in my case. Still happens.

In an effort to track down the bug, I commented out all the code within the gpm_brightness_foreach_resource function and that still did not correct the issue. Killing all gnome-power-manager stops the doubling, so the issue lies within g-p-m. Interestingly enough, the brightness OSD still shows when I use the hot-keys even without g-p-m running. I will continue testing but if anyone has any ideas please share them.

what? I cannot imagine how NotifyOSD can work without gpm running, I think, it is impossible, have you tried gpm with my patch and run it (I have compiled it e.g. to home/stage/gpm)

That's the first thing I did. Anyways I think I fixed the issue now but its a very ugly quick-fix. I commented out the calls to change inc/decrement the brightness values when the keys are pressed. I also had to always distrust the cached brightness value (like I said, ugly) to get the OSD to follow the changes in brightness that the kernel makes. As for the OSD still showing with no g-p-m, that was a strange issue, it hasn't happened again. My mangling of the cache trust system seems to have caused no serious bugs, but I've noticed only a couple little things that may or may not have already existed. None of the tiny bugs are as bad as the doubling up on the brightness control though so I can live with it until one of us makes a real patch or the Ubuntu team comes up with a better idea. If you want, I'll email you my changes, but I just don't want to put it online because of how ugly it is.

Yes, it is quite simple to comment it, but there is serious problem, because of there are laptops with correctly working brightness steps, so your patch disables regulation on them

My patch is simple, it watches changes in file in sys and compare it with cached value, so if kernel has changed it, gpm doesn't make another step

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Yes this issue still exists, and when it was filed, this series was still supported. In fact, isn't 10.04 a LTS release??? I will not re-file my bug report because nobody on the dev team seems to care... This issue exists all the way up to Ubuntu 11.04. Because of this, I have switched to Fedora (which does not have the bug).

I hate that nobody cares in ubuntu team

I have the problem in Ubuntu, Kubuntu, Lubuntu and Mint 11.10 with ThinkPad T520.
Defual 6 steps.
After "echo -n N | sudo tee /sys/module/video/parameters/brightness_switch_enabled"
increased to 9 Steps
In tty with brightness_switch_enabled=Y 16 steps
In tty with brightness_switch_enabled=N not working

xbacklight works flawlessly though.

still here, please add condition into gnome-power-manager to change it only if kernel didn't change it.

Does Xfce and KDE also use gnome-power-manager? I'm experience the same problem in Lubuntu and Kubuntu. Brightness change 3 steps at a time.
I found a workaround is to push {Home} and {End} together. That only increases the brightness by 1 step.

On Ubuntu just kill power manager and it should change only by one steps, but some devices do not support changing brightness without gpm. Easiest fix is just to add some checking to gpm if kernel already changed brightness or not. Gnome guys seem not keen in fixing it.

P Liu <email address hidden> wrote:

>Does Xfce and KDE also use gnome-power-manager? I'm experience the same problem in Lubuntu and Kubuntu. Brightness change 3 steps at a time.
>I found a workaround is to push {Home} and {End} together. That only increases the brightness by 1 step.
>
>--
>You received this bug notification because you are subscribed to the bug
>report.
>https://bugs.launchpad.net/bugs/257827
>
>Title:
> brightness changes twice when using hotkeys
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/gnome-power/+bug/257827/+subscriptions

There is another bug that looks very similar
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/959106

Hi, I noticed this issue from bug 959106, thank Alex Wolfson.
We know this issue and this is not only a issue in userpsace but in kernel, so it's not easy to fix it soon.
We need the code ready in userspace(such as gnome-settings-daemon in gnome) and then we will fix the code in kernel.
But the maintainer of the gnome-settings-daemon didn't accept the patch yet, see bug 959106

Anyway, there is an workaround to fix this, just do
   echo 1 | sudo tee /sys/module/video/parameters/brightness_switch_enabled

sorry, it should be
   echo 0 | sudo tee /sys/module/video/parameters/brightness_switch_enabled

I have an ugly patch (see earlier comment) somewhere buried in a backup amongst a couple of terabytes of other stuff. I will post it here in a few days, digging it up isn't as simple as typing it in the windows search box, and to be honest I have other things higher on my list of priorities. I want to take the time to learn how to make it into a PPA anyway, because I DO remember that I made a proper modification.

Also keep in mind that I made this patch on my HP G62, for my HP G62, and it is unlikely that it will work like it does on my HP G62 on any other machine.

Same problem on Ubuntu 12.04 (3.2.0-26-generic) and Thinkpad T500

echo 0 | sudo tee /sys/module/video/parameters/brightness_switch_enabled

or

echo 4 > /proc/acpi/ibm/cmos
echo 5 > /proc/acpi/ibm/cmos

works -> ~9 brightness steps instead of ~5 steps

dmesg: thinkpad_acpi: detected a 8-level brightness capable ThinkPad

xev-tool reports two key events:

MappingNotify event, serial 145, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 145, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 147, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248

MappingNotify event, serial 147, synthetic NO, window 0x0,
    request MappingKeyboard, first_keycode 8, count 248