brightness changes twice when using hotkeys

Reported by Juan Pablo Salazar Bertín on 2008-08-14
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Fix Released
linux (Ubuntu)
Ayan George
Nominated for Lucid by Pavol Klačanský

Bug Description

When using hotkeys to change screen brightness, it's changed twice. That is, I have 4 different brightness levels, but I should have 8.
When the acpi video module is blacklisted, brightness is changed as expected (I get the 8 levels).

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
Package: linux-image-2.6.26-5-generic 2.6.26-5.15 [modified: lib/modules/2.6.26-5-generic/modules.pcimap lib/modules/2.6.26-5-generic/modules.dep lib/modules/2.6.26-5-generic/modules.ieee1394map lib/modules/2.6.26-5-generic/modules.usbmap lib/modules/2.6.26-5-generic/modules.isapnpmap lib/modules/2.6.26-5-generic/modules.inputmap lib/modules/2.6.26-5-generic/modules.seriomap lib/modules/2.6.26-5-generic/modules.alias lib/modules/2.6.26-5-generic/modules.symbols]
ProcCmdLine: root=UUID=fba89e7a-4820-478a-881d-e247b5e8fbfc ro quiet
ProcVersionSignature: Ubuntu 2.6.26-5.15-generic
SourcePackage: linux

Nick Ellery (nick.ellery) wrote :

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

Changed in linux:
status: Unknown → Confirmed
Changed in linux:
status: Confirmed → Fix Released

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.


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

Christophe Dumez (hydr0g3n) wrote :

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).

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
DSHR (s-heuer) wrote :

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

DSHR (s-heuer) wrote :

My situation with Brightness Up:

$ lshal -m

Start monitoring devicelist:
14:27:36.724: computer_logicaldev_input_5 condition ButtonPressed = brightness-up
$ 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

findepi (piotr-findeisen) wrote :

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?

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 .

DSHR (s-heuer) wrote :

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.

Andy Whitcroft (apw) on 2008-11-18
Changed in linux:
assignee: ubuntu-kernel-team → apw
status: Triaged → In Progress
Andy Whitcroft (apw) wrote :

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:


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.


Tim Gardner (timg-tpi) on 2008-11-20
Changed in linux:
assignee: nobody → apw
milestone: none → intrepid-updates
status: New → In Progress
importance: Undecided → Low
Andy Whitcroft (apw) wrote :

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.

Andy Whitcroft (apw) wrote :

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.


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

TEST CASE: see bug report.

Andy Whitcroft (apw) wrote :

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

Changed in linux:
status: In Progress → Fix Committed
importance: Low → Medium
Andy Whitcroft (apw) wrote :

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

Changed in linux:
status: In Progress → Invalid
DSHR (s-heuer) wrote :

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

Steve Langasek (vorlon) wrote :

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!

Jon Oberheide (jon-oberheide) wrote :

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

arno_b (arno.b) wrote :

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

Andy Whitcroft (apw) wrote :

@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.

Steve Beattie (sbeattie) wrote :

@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,

Steve Beattie (sbeattie) wrote :

@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.

Michael Rooney (mrooney) wrote :

It was fixed for awhile after installing proposed updates, but yesterday I installed proposed, I think, 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?

Guglielmo Cola (guglielmocola) wrote :

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

Andy Whitcroft (apw) wrote :

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

Andy Whitcroft (apw) wrote :

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:


Guglielmo Cola (guglielmocola) wrote :

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.

Martin Pitt (pitti) wrote :

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.

Michael Rooney (mrooney) wrote :

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 :)

Guglielmo Cola (guglielmocola) wrote :

I've the same questions as Michael. :)

Stefan Bader (smb) wrote :

Hi Michael, Guglielmo,

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


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

Michael Rooney (mrooney) wrote :

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.

Stefan Bader (smb) wrote :

For Jaunty things are a bit in the moving state. In your case it currently will likely do the right thing, since the default there is either vendor or video. However, when we had the same in Intrepid it fixed this case but broke several others, so we reverted to have vendor _and_ video as the default for the time being. But the chances are not too bad that your case is good in Jaunty since this is the direction that upstream is currently taking.

Guglielmo Cola (guglielmocola) wrote :

acpi_backlight=vendor worked for me too.

Michael Rooney (mrooney) wrote :

FYI the situation is hilariously worse out-of-the-box in Jaunty (as of Alpha 3), at least on my Dell M1330. The brightness seems to change 4-6 times when using the hotkey once, so in my case I have 2-3 brightness levels instead of 8. However using acpi_backlight=vendor also fixes it in Jaunty.

Launchpad Janitor (janitor) wrote :
Download full text (16.6 KiB)

This bug was fixed in the package linux - 2.6.27-11.25

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

  [ Jeff Layton ]

  * SAUCE: cifs: make sure we allocate enough storage for socket address
    - LP: #318565

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

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

  [ Andy Whitcroft ]

  * SAUCE: don't use buggy _BCL/_BCM/_BQC for backlight control
    - LP: #311716, #314119

  [ Jim Lieb ]

  * SAUCE: atl2: add tx bytes statistic
    - LP: #268622

  [ Upstream Kernel Changes ]

  * i915: Save/restore MCHBAR_RENDER_STANDBY on GM965/GM45
    - LP: #276943

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

  [ Andy Whitcroft ]

  * Revert "synchronise our linux-libc-dev with the kernel userspace
    headers". It was causing regressions.
    - LP: #300803

  [ Brian Rogers ]

  * SAUCE: Add support for MSI TV@nywhere Plus remote
    - LP: #281647

  [ Tim Gardner ]

  * SAUCE: Dell laptop digital mic does not work, PCI 1028:0271
    - LP: #309508

  [ Upstream Kernel Changes ]

  * Revert "sched_clock: prevent scd->clock from moving backwards"
  * AMD IOMMU: enable device isolation per default
  * bonding: fix miimon failure counter
  * x86 Fix VMI crash on boot in 2.6.28-rc8
  * libata: fix Seagate NCQ+FLUSH blacklist
  * e1000e: fix double release of mutex
  * can: Fix CAN_(EFF|RTR)_FLAG handling in can_filter
  * can: omit received RTR frames for single ID filter lists
  * iwlwifi: clean key table in iwl_clear_stations_table function
  * net: eliminate warning from NETIF_F_UFO on bridge
  * unicode table for cp437
  * console ASCII glyph 1:1 mapping
  * key: fix setkey(8) policy set breakage
  * firewire: fw-ohci: fix IOMMU resource exhaustion
  * ieee1394: add quirk fix for Freecom HDD
  * SUNRPC: Fix a performance regression in the RPC authentication code
  * b1isa: fix b1isa_exit() to really remove registered capi controllers
  * macfb: Do not overflow fb_fix_screeninfo.id
  * setup_per_zone_pages_min(): take zone->lock instead of zone->lru_lock
  * xilinx_hwicap: remove improper wording in license statement
  * Linux except for "iwlagn: fix RX skb alignment". Besides causing
    an ABI bump it only applies to machines using > 4K page size (such as PowerPC).
    Pick this one up on the next ABI bumping upload.
    - LP: #309731

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

  [ Andy Whitcroft ]

  * synchronise our linux-libc-dev with the kernel userspace headers
    - LP: #300803

  [ Jim Lieb ]

  * SAUCE: [PATCH 1/1] USB: Unusual devs patch for Nokia 5610
    - LP: #287701

  [ Michael Krufky ]

  * sms1xxx: use new firmware for Hauppauge WinTV MiniStick
    - LP: #299671
  * sms1xxx: add autodetection support for Hauppa...

Changed in linux:
status: Fix Committed → Fix Released
Michael Rooney (mrooney) wrote :

If you are going to consider this bug fixed, shall I open up a new bug for people like Guglielmo and myself? As mentioned the initial proposed fixed this and then the second un-fixed it, and it is still (more) broken in Jaunty. Let me know what to do, thanks!

M. Fatih KILIC (fatih77) wrote :

I'm using an updated Intrepid on an x61 and the problem still exists. My display is very dimmed and when I use brightness up and down controls it doesn't affect to display even backlight OSD goes up and down. It was working perfectly before the last updates.

tsaitgaist (kevredon) wrote :

this bug is still in linux - 2.6.27-11.27 : the applet works, the brightness does not change
I use a ThinkPad R61
another way to change the brightness, directly on the cmos : echo 5 | sudo tee /proc/acpi/ibm/cmos

Pavol Klačanský (pavolzetor) wrote :

I have thinkpad T500 with Jaunty 64 bit and there proble is occured, when I press button brightness goes from 0 to 2, 2 to 4 and so on,

Pavol Klačanský (pavolzetor) wrote :

this acpi_backlight=vendor fixed it for me, but I think this is no simple for basic users

Pavol Klačanský (pavolzetor) wrote :

lastest updates fix it to me, thx

Pavol Klačanský (pavolzetor) wrote :

hmm, lastest updates brokes it, the bahaviour is strange, first step is too big like 5 normal steps

Changed in linux (Ubuntu):
status: Invalid → Incomplete
Pavol Klačanský (pavolzetor) wrote :

lucid, problem is still there

Stephen Warren (srwarren) wrote :

Comment 271 in bug 415023 indicates that this bug, or at least something with the same symptoms (hotkeys changing 2 brightness levels at a time) apply to the MSI Wind U100 in Karmic. I certainly do see the same symptom, but have not yet validated whether blacklisting the acpi video module solves it, like it did for the initial reporter of this bug.

Stephen Warren (srwarren) wrote :

Sorry, I meant comment 272 not 271.

Rolf Leggewie (r0lf) on 2010-01-31
tags: added: lucid
Fail2Ban (failtoban) on 2010-02-20
tags: added: i386
tags: added: verification-done
removed: verification-needed
Steve Langasek (vorlon) on 2010-02-20
tags: removed: i386
Mitch Towner (kermiac) wrote :

@ Fail2Ban: please do not assign/change/remove tags without first reading https://wiki.ubuntu.com/Bugs/Tags
Thanks in advance!

tags: added: verification-needed
removed: verification-done
Pavol Klačanský (pavolzetor) wrote :

I have lucid, and problem is still alive

wub (wub) wrote :

I just installed the first lucid beta and this just became an issue for me. From 7.04 to 9.10, I have been able to use my full range of brightness settings with fn + f6/f7 on my Fujitsu Lifebook. Now, I see a horizontal bar indicator that only cycles through the top end of the brightness setting.

/proc/acpi/video/OVGA/LCD/brightness says I have 8 levels of brightness, but the lowest I can set is 6. Also, I found a thread indicating this 'file' could be edited to set levels, but I am unable to save changes to it.

In the same directory, the file EDID contains only "<not supported>".
 the file info contains:
device_id: 0x0400
known by bios: no

and the file state contains:
state: 0x1f
query: 0x00

If any of that might be useful.

wub (wub) wrote :

One further note: I have discovered a work-around, sort of. In my case, when I use Fn +F6 to reduce the brightness to the minimum (for me, level 6 initially) if I then use Fn +F7 to increase brightness BY JUST ONE INCREMENT to 7, then I can return to Fn + F6 and drop down to 4. If I continue this process of 'three steps down, one step up'

This looks like some sort of problem initializing a variable, one that gets set when brightness is moved up, and decremented when brightness goes down. Each time the brightness is moved up, it goes to a value like 3, and can be reduced three times?

Hope this helps.

Pavol Klačanský (pavolzetor) wrote :

It is quite strange, buttons change it by twice steps, but this:
sudo sh -c "echo 10 > /sys/devices/virtual/backlight/acpi_video0/brightness"
sudo sh -c "echo 9 > /sys/devices/virtual/backlight/acpi_video0/brightness"
and so on can change brightness properly

Andy Whitcroft (apw) on 2010-06-18
Changed in linux (Ubuntu):
assignee: Andy Whitcroft (apw) → nobody
Changed in linux (Ubuntu Intrepid):
assignee: Andy Whitcroft (apw) → nobody
Pavol Klačanský (pavolzetor) wrote :

also in VT1 it works properly, I think it is problem of GNOME

Pavol Klačanský (pavolzetor) wrote :

I am working on patch

Pavol Klačanský (pavolzetor) wrote :

Hallo, after some investigation I found source of problem (IMHO)
at kernel space, brightness is changed for one step, but in user space by gnome-power-manager it is changed for another one step and 1 + 1 = 2 => so brightness is changed twice

Pavol Klačanský (pavolzetor) wrote :

I have commented two rows ("XRRChangeOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight, XA_INTEGER, 32,
     PropModeReplace, (unsigned char *) &value, 1);") in file gpm-brightness-xrandr.c and brightness works properly, but I think this is kernel problem, because, it shouldn't change level of brightness if it is handled by other apps

What fix do you choose?

Pavol Klačanský (pavolzetor) wrote :

tested on Lenovo Thinkpad T500 and also FSC V5505

in E17, there is not this problem

Changed in gnome-power:
status: Unknown → New
Pavol Klačanský (pavolzetor) wrote :


please, provide me there some info, it could help me in investigation

Pavol Klačanský (pavolzetor) wrote :


Pavol Klačanský (pavolzetor) wrote :

It seems it is intel problem

Martin Bajer (fict10n) wrote :

II can confirm the bug on my ThinkPad X60s.
running Ubuntu 10.04, kernel 2.6.32-24-generic #42-Ubuntu SMP

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in gnome-power:
importance: Unknown → Medium
Zhang Rui (rui-zhang) wrote :

module parameter /sys/module/video/parameters/brightness_switch_enabled is designed as a switch to disable/enable the backlight control in ACPI video driver.
does the problem still exist after running "echo 0 > /sys/module/video/parameters/brightness_switch_enabled"?

Pavol Klačanský (pavolzetor) wrote :

hmm, interesting, but then brightness control doesn't work in TTY

le père Léon (news-leon) wrote :

Le 08/10/2010 08:17, Zhang Rui a écrit :
> does the problem still exist after running "echo 0 > /sys/module/video/parameters/brightness_switch_enabled"?

Good! it solves the problem.

also working (I had a Y by default) :
  echo "N" > /sys/module/video/parameters/brightness_switch_enabled


Pavol Klačanský (pavolzetor) wrote :

ok, this is nice, but what about switching to e.g. TTY1. There users cannot regulate brightness. So I am working on patch for gnome-power-manager (no root access needed, just if is brightness changed, GPM will not change it twice)

tags: added: maverick
Pavol Klačanský (pavolzetor) wrote :

I am a bit of lost in building packages and creating branches, but please, I think, this should help

Pavol Klačanský (pavolzetor) wrote :

My friend has tested it and it works

Pavol Klačanský (pavolzetor) wrote :

Hi, in Gnome, they didn't commit, so I really don't know, how could I submit it :/, I use it in my laptop about 2 months without any problem

mlx (myxal-mxl) wrote :

"Me too" since Intrepid all the way up to and including Maverick on Fujitsu-Siemens Esprimo Mobile U9200.
echo N > /sys/module/video/parameters/brightness_switch_enabled fixes everything for me, and brightness in tty still works. I'll check single-user (recovery) mode to be sure KDE is not involved.

Pavol Klačanský (pavolzetor) wrote :

I use my patch, please test it

mlx (myxal-mxl) wrote :

#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.

Pavol Klačanský (pavolzetor) wrote :

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

Brian Rogers (brian-rogers) wrote :

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.

Pavol Klačanský (pavolzetor) wrote :

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.

Pavol Klačanský (pavolzetor) wrote :

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

Changed in linux:
importance: Unknown → High

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.

Changed in linux (Ubuntu):
status: Confirmed → Won't Fix

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).

Pavol Klačanský (pavolzetor) wrote :

I hate that nobody cares in ubuntu team

Ayan George (ayan) on 2011-11-18
Changed in linux (Ubuntu):
assignee: nobody → Ayan George (ayan)
P Liu (lpc921) wrote :

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.

Pavol Klačanský (pavolzetor) wrote :

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

P Liu (lpc921) 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.

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
> brightness changes twice when using hotkeys
>To manage notifications about this bug go to:

Changed in gnome-power:
status: New → Unknown
Alex Wolfson (awolfson) wrote :

There is another bug that looks very similar

AceLan Kao (acelankao) wrote :

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

AceLan Kao (acelankao) wrote :

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.

Schmankerl (schmankerl) wrote :

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


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

Schmankerl (schmankerl) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.