Screen brightness double level changes on Dell laptops

I can confirm that. I've just upgraded from gutsy to hardy on my dell inspirion 1520. But I'm using kubuntu (it's guidance-power-manager in kde).
When I'm in kde, pressing Fn+up/down skips one brightness level. And I can see 2 popups showing brightness level (one under another).
In console everything works fine.
I can set any level with 'echo [something] > /proc/acpi/video/VID/LCD/brightness'. I can set any level in guidance-power-manager. I can even increase/decrease brightness level by one with 'dcop guidance power-manager brightnessDown/brightnessUp'

Maybe it's hal error?

$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
12:55:17.525: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
12:55:17.525: computer_logicaldev_input condition ButtonPressed = brightness-up
12:55:18.012: computer_power_supply_battery_BAT0 property battery.voltage.current = 12542 (0x30fe)
12:55:18.738: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
12:55:18.754: computer_logicaldev_input condition ButtonPressed = brightness-down

After stopping hal and acpid (/etc/init.d/acpid stop; /etc/init.d/hal stop) I can adjust brightness in console and kde with all levels, but there is no popups in kde (guidance uses hal?). So it looks like that there are two services that handling brightness changing (hal+kdeish_tools[kmilo+kde-guidance] and something else).

I'm also experiencing this issue on my dell inspiron 6400 recently. I don't believe it was a problem a couple of weeks ago...

Same problem with a Dell XPS M1330.
Gusty was working good, the problem is since Hardy.

I've solved problem by putting "blacklist video" in /etc/modprobe.d/blacklist

Also have this problem with Dell 1420n running Hardy Beta

Adding "blacklist video" in /etc/modprobe.d/blacklist also solve the problem on my Dell XPS M1330

But that's only a temporary workaround and not really a fix... right?

On Fri, Apr 11, 2008 at 11:20 AM, Flo <email address hidden> wrote:

> Adding "blacklist video" in /etc/modprobe.d/blacklist also solve the
> problem on my Dell XPS M1330
>
> --
> Screen brightness double level changes
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Source Package "gnome-power-manager" in Ubuntu: New
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> I have a fresh installation of Hardy with the latest updates installed on
> a Dell Inspiron 6400 laptop. The brightness settings (Fn+Up/Down) work
> although they seem to skip a level each time.
>
> '/proc/acpi/video/VID/LCD/brightness' tells me that it supports brightness
> levels 12, 24, 36, 48, 60, 72, 84 and 100. Without gnome-power-manager
> running pressing Fn+Up will transition up into each level and back down
> again smoothly.
>
> When gnome-power-manager is running increasing the brightness from 12 I
> can only get levels 36, 60, 84 and 100. Decreasing the levels from 100 I
> only get 72, 48, 24 and 12. Running gnome-power-manager with the verbose
> option shows that when I press the brightness-up button once it is recorded
> twice. I ran gnome-power-manager in a debugger thinking it was a timing
> issue and it still happened.
>
> I have included the output from pressing the brightness-up button (Fn+Up)
> once below. This only happens when gnome-power-manager is running and did
> not happen using Feisty. I have looked at the code and I cannot see why the
> button event is triggered twice, I don't have any experience of the code but
> if you can give me any ideas of where to start I can try to look into this
> myself.
>
> Thanks!
>
>
> [hal_device_condition_cb] gpm-button.c:391 (00:11:48):
> condition=ButtonPressed, details=brightness-up
> [emit_button_pressed] gpm-button.c:335 (00:11:48): emitting
> button-pressed : brightness-up
> [button_pressed_cb] gpm-manager.c:999 (00:11:48): Button press
> event type=brightness-up
> [button_pressed_cb] gpm-srv-screensaver.c:167 (00:11:48): Button
> press event type=brightness-up
> [button_pressed_cb] gpm-backlight.c:563 (00:11:48): Button press
> event type=brightness-up
> [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (00:11:48):
> GetBrightness returned level: 0
> [gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (00:11:48):
> Setting 1 of 7
> [gpm_brightness_lcd_up] gpm-brightness-lcd.c:362 (00:11:48): emitting
> brightness-changed (14)
> [brightness_changed_cb] gpm-backlight.c:755 (00:11:48): Need to display
> backlight feedback value 14
> [gpm_feedback_display_value] gpm-feedback-widget.c:144 (00:11:48):
> Displaying 0.140000 on feedback widget
> [gpm_refcount_add] gpm-refcount.c:100 (00:11:48): refcount now: 1
> [gpm_refcount_add] gpm-refcount.c:101 (00:11:48): non zero, so
> sending REFCOUNT_ADDED
> [brightness_changed_cb] gpm-backlight.c:759 (00:11:48): emitting
> brightness-changed : 14
> [button_pressed_cb] gpm-info.c:698 (00:11:48): Button press event
> type=brightness-up
> [hal_device...

Right, it's just a hack. I hope a fix will be available when the heron will take off...

Not much time left on that. Slipping through the cracks? Shouldn't it be assigned to someone?

Almost the same problem with Gutsy on a dell inspiron 1520N laptop
 At startup the brightness controls works (FN+Key UP/FN+ Key Down) (until gdm is loaded) and afterwards the keys are extremely sensitive and any kind of brightness control works only after I login. Nothing happens when I press them after gdm is started and before login or if I switch to text mode.

I don't think that it's important but I've updated from 7.10 to 8.04 using update-manager --devel-release. At update time I've chosen to overwrite all config files with the ones provided by the new package version. After the first boot (I'm using compiz) all the windows that were in the backgroud (not minimized, just having a dialog opened in front of it) lost their title bar and when switching back to them the title bar comes up again. I've used sudo nvidia-xconfig -xvmc-uses-textures --xinerama --use-events --no-sli --render-accel to reconfigure the X server and now all works fine with compiz.

Back to the brightness issue.
Running kernel: 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux
Content of the dmesg:
Please note the following. During the boot I've kept pressing Brightness UP/Down on the keyboard. It does work for a while. It's stops working at the same time that messages like
[ 25.182603] atkbd.c: Unknown key pressed (translated set 2, code 0x85 on isa0060/serio0).
[ 25.182699] atkbd.c: Use 'setkeycodes e005 <keycode>' to make it known.
stops showing up. (Before the Nvidia module is loaded. That might be only a coincidence because I'm not able to press the keyboard as fast as the kernel loads a module)

--------------DMESG output
[ 0.000000] Linux version 2.6.24-16-generic (buildd@palmer) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Thu Apr 10 13:23:42 UTC 2008 (Ubuntu 2.6.24-16.30-generic)
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
[ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003fe6d800 (usable)
[ 0.000000] BIOS-e820: 000000003fe6d800 - 0000000040000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed18000 - 00000000fed1c000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000feda0000 - 00000000feda6000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved)
[ 0.000000] 126MB HIGHMEM available.
[ 0.000000] 896MB LOWMEM available.
[ 0.000000] Entering add_active_range(0, 0, 261741) 0 entries of 256 used
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 229376
[ 0.000000] HighMem 229376 -> 261741
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 261741
[ 0.000000] On node 0 totalpag...

I apologize. The first line of the previous comment should be:
"Almost the same problem with Hardy on a dell inspiron 1520N laptop"

Hello,

I've a Inspiron 1525 with Hardy.

If I use the hotkeys (Fn + up/down) I only get 4 steps.

If I use the "Power Manager Brightness Applet" there are 8 brightness levels. However it takes 100 clicks on the + and - buttons to get from one end to the other. That seems like Bug #149780

Same problem with a Lenovo Ideapad Y510.

Intel GM965/GL960 gfx card.

Also, Fn+up/Fn+down are reversed, so Fn+up = Fn+down, and Fn+down = Fn+up.

Confirming the same with Hardy on Dell Inspiron 6400.

Fiesty worked fine, only in Hardy.

Fn + up/down key behavior is ok.

Same exact problem on a Dell M1330 with Hardy. Prior to the Hardy upgrade, brightness keys worked as expected. Now, I'm observing the same brightness skipping behavior as described in the bug report.

Please only comment on bugs if you're saying something that can contribute to fixing the bug.

In my case (Dell Inspiron 9400) I get 4 events with every key press, and 4 brightness level change by gnome-power-manager respectively.
This is with 1 brightness down key press:

snifer@snifer-laptop:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
19:25:50.117: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
19:25:50.124: computer_logicaldev_input_1 condition ButtonPressed = brightness-down
19:25:50.124: computer_logicaldev_input condition ButtonPressed = brightness-down
19:25:50.328: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

I can confirm the behavior of 4 brightness levels per key press on a Dell XPS M1210 under KDE. "lshal -m" shows the same thing here.

Bug #218889 and bug #212733 seem to describe the same problem.

Also related to #211948 and #220310.

That's what "Mark as duplicate" is for.

related to, not duplicates, wise guy. but one fix may help another.

I realise that. There is no need to insult me. There is a Code of Conduct to folllow here.

Insult shminsult. What I wrote wasn't a duplicate, it was related, so your "That's what 'Mark as duplicate' is for" comment was snarky. Or does a code of conduct only work one way?

Aye, probably. I'll shut up now, this is pointless noise over nothing.

Here's me shutting up too.

Also affects kde-guidance-powermanager on certain laptops. Should be partly fixed in kde-guidance-powermanager.

I observed that the brightness can be set to the desired value using the brightness widget to the panel. You can use it to set brightness level until fix is available.

I observed that the brightness can be set to the desired value using the brightness widget. You can use it to set brightness level until fix is available.

Blacklisting the video module works as a workaround for me, but I think it's not the real solution. I'm attaching my lshal output after backlisting the video module.

This is after pressing brightness down hotkey 1 time:

snifer@snifer-laptop:~$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
23:00:06.637: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

The fix for the kde-guidance-powermanager part of this problem is attached. See also duplicate bug 218889 for further info.

This bug was fixed in the package kde-guidance - 0.8.0svn20080103-0ubuntu17

---------------
kde-guidance (0.8.0svn20080103-0ubuntu17) intrepid; urgency=low

  * Edited kubuntu_23_kde-powermanager_gpmhelper.patch to prevent
    multiple brightness- or hibernate-calls happening on certain
    machines. Already implemented for sleep-calls. (LP: #207473)

 -- Andreas Wenning <email address hidden> Mon, 12 May 2008 16:45:38 +0200

Same bug here on a XPS M1330.

"blacklist video" fixes the original problem, BUT causes other (more serious) problems: When backlight is dimmed because of idle, the touchpad stops working for a few seconds (and backlight is not dimmed):
psmouse.c: TouchPad at isa0060/serio1/input0 lost synchronization

Is there some other fix (in gnome) for the brightness problem other than "blacklist video"?

I'm waiting for a proper fix too :( Same problem as you Hinrinch I confirm yet.

The above SRU is handled in bug 82279 .

Do you have any news? When this will be repair without blacklist video?
ps: What means "SRU" please ?

Thanks

SRU means "stable release update". I'm working at getting the kde-guidance part of the fix into hardy.

Will there be a fix for Gnome? The kde-guidance fix will only fix this for KDE, right?

What is your vCard ???? please reply me de source code and the details of
your drivers.
Regards

On 6/11/08, Sympy <email address hidden> wrote:
>
> Will there be a fix for Gnome? The kde-guidance fix will only fix this
> for KDE, right?
>
>
> --
> Screen brightness double level changes
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are subscribed to Ubuntu.
>

--
Atentamente :

Francisco Miguel Rincon Garcia

@Sympy
There are two parts to this problems:
(1) Driver/HAL problems
(2) Problems with the software handling it (kde-guidance/gnome equivalent).

Depending on your hardware, you could be affected by either (1) or (2) or both. (2) affects kde in hardy (fix is in hardy-proposed); but I don't know (and don't suppose) that gnome is also affected. So your problems is most likely regarding (1).

Well, the original post mentions that without g-p-m the brightness transition works smoothly, so I thought a fix could also be possible with Gnome.

My card is a GeForce 8400M GS (I have a Vostro 1400 lappy) and I have this problem with both nv and nvidia-glx-new. Please let me know of any technical details I can give to help.

What I find curious is that I see a lot of people solving this problem by tweaking /etc/acpi/video_brightnessdown.sh and /etc/acpi/video_brightnessup.sh, while for me changing those files - even deleting them - has no effect all. It seems they're not what the system is calling when I press the fn brightness keys.

This what lshal -m reports with a single touch to fn + up:

07:27:06.173: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
07:27:06.178: computer_logicaldev_input_1 condition ButtonPressed = brightness-up
07:27:06.178: computer_logicaldev_input condition ButtonPressed = brightness-up
07:27:06.364: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

There are no "posts" on bug trackers, only comments. They are not discussion forums.

No reason to be condescending.

Sympy, are you seeing two brightness level changes at a time now (and not four)? If so, that seems to be the current proper state of things given your hardware and the hal/driver problems that Andreas mentioned.

I've got the same hardware as Sympy, and exactly the same experience. Way back in late feisty, this was one percentage amt (approx 10%) was given to one button press. AFAIK this is gpm. Early gutsy, it managed get the steps about right, but it was still using percentages rather than hardware. Since gutsy has been finalized, this happens. Four events per one press causes four steps (approx. 60%, if it matters...) instead of one step, such as when 'video' module is missing.

The reason I go through all that is that I believe that the problem is seated soley in hal (in our case). I'm not quite sure what you mean by "the current proper state of things" but AFAIK this is not entirely correct behavior: Whatever is controlling brightness is working properly, faithfully changing brightness four times, because the one button generates four events.

For conveinance (and possible comparison), here's my lshal -m output:

--snip--

10:45:58.670: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
10:45:58.670: computer_logicaldev_input_1 condition ButtonPressed = brightness-up
10:45:58.670: computer_logicaldev_input condition ButtonPressed = brightness-up
10:45:58.903: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

--un snip--

Some things here that seem to be of possible interest...

Lines 1-3: occur at the same exact (down to millisecond) time
Lines 2 and 3: slightly different logicaldev_input thing... two hardware pieces (unlikely) or two sources for the same event?
Line 4: Same as Line 1, but approx. 250 milliseconds later

Could each line beginning with "platform" be tied to one of the lines beginning with "computer"?

Sorry for the confusion; what I meant is that the proper level of breakage at the moment (with the patched g-p-m in hardy-proposed) is two brightness levels per button press due to the two key press events still coming through hal.

I was only pointing out that bug comments are only for useful comments that help fix the bug in question, rather than random discussion.

Thanks for the response, radsaq. But are you sure there's a patched g-p-m in hardy-proposed? I just checked the repository and the hardy-changes list and found nothing...

PS: Sorry about the confusion about posts and comments. It wasn't my intention to infer this is a discussion forum.

On Wednesday 11 June 2008 19:38, Sympy wrote:
> Thanks for the response, radsaq. But are you sure there's a patched
> g-p-m in hardy-proposed?

https://launchpad.net/ubuntu/hardy/+source/kde-guidance/0.8.0svn20080103-0ubuntu16.1

Scott, I know that an update to kde-guidance is available, but that's a fix only to KDE users, right?

I was asking about an update for gnome-power-manager and if it's possible at all. I'm willing to help with any reports needed.

Bruce, I merely asked something that I think is relevant for gnome users who want this bug fixed. I'm perfectly aware that my original question about g-p-m, and this one, are not *directly* contributing to fixing the bug, but I'm asking for small details needed to contribute better. Does the fact that only a kde-guidance fix is available means that g-p-m cannot be fixed for one reason or the other? Or just means that there is not enough info about g-p-m so far? Etc, etc. I'm willing to contribute if the second case is true. I really don't think that's "random discussion". I just wanted to help on the Gnome part of the problem.

Furthermore, given the attitude I'm receiving from you (and the attitude you'd thrown at J Wood in this same report), it's very much possible that if I simply posted technical info on my experiences with this bug and g-p-m, I would receive a "A fix is already commited. Shut up." in my face, so don't blame me for being careful. This is the second time I'm asking a question in Launchpad with the best of intentions and genuine desire to contribute and receive nothing but condescending bashing from people I'm trying to help.

g-p-m in this context is Guidance Power Manager (which is for KDE).

@Sympy
If you receive 4 brightness step changes with 1 key-press with gnome's power manager, it seams that the gnome power manager (i suppose that is the one handling the brightness changes; but I'm not sure about that) is also affected in the same way as kde-guidance.

If that is the case, I would advice you to open a new bug against the correct gnome package, or set this bug to also affect gnome power manager. But considering the confusion, that both gnome's as well as kde's power management features are referred to as g-p-m, opening a new bug is to me to be preferred. You could very well refer to this bug in your new bug report. You should of course check that the bug report doesn't already exist against gnome power manager.

Bug #239413 reported. I don't know if someone will consider it a duplicate, but I couldn't find a report of this exact problem already published.

I recently noticed that the problem does not happen only with brightness keys. See Bug #239706.

Do you think the following bugs are a duplicate of this bug?
bug 239706
bug 239413

It seems that the reporter of bug 212733 is also experiencing the same problem too, but it's not the only problem.

I wanted to say something more, but I forgot. If I can think of it again I'll comment again. ;)

I reported #239413 following the advice above of Andreas Wenning and reported #239706 when I noticed that the scope of the multiple key pressing problem goes beyond the scope of the brightness keys. I think the difference between them is that this one (#207473) and #239413 deal with the power-manager part of the problem (KDE and Gnome, respectively), while #239706 deals directly with the hal problem, which is also affecting the CRT/LCD key.

The brightness control with the Fn Keys works very sensitiv, I'm not able to switch every step (using Ubuntu 8.04).
Whatever, with the brightness applet from the panel I'm able to switch to every step.

With Ubuntu 8.04 Alpha the brightness control with the Fn Keys had worked fine.

The hal-update that arrived lately (yesterday?) fixes this, it seems.
However, unblacklisting the video-module breaks FN-F8 (CRT/LCD-Switcher) for me.
Brightness-control works fine again, even with video-module loaded.

Bug still here for me (8.04, GNOME, Dell XPS M1330, Nvidia 8400)

I checked too after the hal-info (i think?) update yesterday evening. Still not working right for me either. I'm not blacklisting anything. Using the brightness control applet has always worked fine, I believe. The large jumps in brightness only occur when using the Fn+Up /Fn+Down keys.

It looks like the fix for the kde-guidance package in hardy-proposed can be verified.

The latest updates didn't fix anything for me either (8.04, GNOME, Dell XPS M1330, Intel graphics)

Should this be considered "verification failed", or are there cases for which this update represents a partial improvement?

Given that we're verifying Kubuntu's Guidance Power Manger in this bug, I think it's not at all suprising that the KDE change didn't fix the Gnome user's problem. I'd vote irrelevant. Personally I've seen considerable improvement from this fix and I don't actually have the problematic hardware. I think it's a definite improvement.

ok, marking as 'verification-done' here.

kde-guidance copied to hardy-updates.

Same problem here with Dell XPS M1330, with Ubuntu 8.10 Beta and nVidia 8400 GS

I have noticed something interesting..
When a menu is open (Applications,Places or Systems), and Fn+up/Fn+down keys are pressed, the screen brightness is changed correctly without any double/quadruple steps, although, now there are only 5 brightness levels, whereas my LCD screen supports 8 levels . Can somebody confirm this?

I can confirm that killing the gnome-power-manager process fixes the multiple brightness level hopping, however there are only 5 brightness levels.

Now, the amount of brightness "hops" in my case have varied from 2 to 4 steps for a single Fn+Up/Down press. Which leaves me with the conclusion that the acpi & gnome-power-manager brightness controls are overlapping.

For now im sticking to a gnome-panel brightness applet, the "blacklist video" hack creates a lot of new problems here.
Running Dell M1330, GF9400M GS, 2.6.27-7-generic, and latest Intrepid updates as of now.

Same notebook here: Dell XPS M1330, nvidia GF8400 GS.

I can confirm that, as you say, "the amount of brightness 'hops' in my case have varied from 2 to 4 steps for a single Fn+Up/Down press".
However it seems to me that the number of brightness hops also vary when a menu is open. The only difference to me is that this progress bar indicating the brightness level is not shown.

Same result as Kuba Górski too on my Dell XPS M1330 with Nvidia 8400.

I get the same result as Kuba Górski, hardware is Dell Inspiron 1720.

Related to brightness issues: did anyone else notice the problem with the brightness applet described in bug #81339, more precisely what described in the commend I posted there (https://bugs.launchpad.net/ubuntu/+source/hal/+bug/81339/comments/11)?

On my Dell XPS M1330 it seems to me that changing the brightness from the applet works fine, but if I open a menu and I press the brightness key, nothing changes.

(I'm the reporter of bug #282963, which has been marked as a duplicate of this bug.)

The brightness applet doesn't work for me. If I try changing the brightness with it, the applet hangs, and appearts to steal keyboard and mouse focus until I switch to a text VT and kill the applet. I have a Dell Inspiron 630m.

this is actually caused by a BIOS bug/kernel bug (depends who you talk to). It's because the BIOS has tables in the DSDT to represent the possible different video cards that would ship with the box (UMA or discrete). There is a fix available upstream, but it causes regressions on other machines. It will need to be tracked until it's ready.

This bug was a bug about the KDE Guidance that didn't work, while at
the same machine the Gnome power guidance would work perfectly.

Allow me express my frustration with Ubuntu bug management people that
are WAY too eager to:
- mark different bugs as duplicates from each other;
- folks that don't read the bug history, and start changing the
packages the bug applies to.

Kind regards,
Franciso

On Mon, Oct 20, 2008 at 9:46 AM, Bug Watch Updater
<email address hidden> wrote:
> ** Changed in: linux
> Status: Unknown => Confirmed
>
> --
> Screen brightness double level changes
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Francisco

In my case, the problem is on GNOME with Ubuntu 8.04 and 8.10.

This bug ended up having multiple parts. The Guidance part was fixed long
ago.

Would it be feasible to include the upstream patch in Dell specific packages in dell ppa or would that require to recompile the entire kernel?

In any case, I found that getting rid, by renaming them, of /etc/acpi/video_brightnessup.sh and /etc/acpi/video_brightnessdown.sh seems to workaround the problem. I do not know if this may cause any regression.

Also, why wasn't this a problem in gutsy? My brightness shortcut keys worked just fine then. It wasn't until 8.04 that it was broken (and lingers in 8.10, so far). Was there something that specifically prevented this behavior in gutsy, or was there something introduced in hardy that caused it?

I am also experiencing this bug, but at least now it doesn't change the brightness by 3 levels but "only" 2.

Ubuntu 8.10 intrepid final
XPS m1330

I experience the same behaviour as above. Inrepid 8.10 final, Dell Inspiron 1520, using NVIDIA 177.80 on a 8600M GT. There are 7 levels of brightness supported by the hardware:

root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# ls
actual_brightness brightness power uevent
bl_power max_brightness subsystem
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 1 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 2 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 3 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 4 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 5 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 6 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 7 > brightness
root@fackamato-laptop:/sys/devices/virtual/backlight/acpi_video0# echo 8 > brightness
bash: echo: write error: Invalid argument

There is also a acpi_video1 directory, with same files. They also change the brightness of the LCD monitor.

I'm also experiencing this problem on both xps M1330 ( 8400M GS ) and inspiron 9400 (7900M GS ) . Moreover this bug is present since 7.10 and follow me to 8.04 and 8.10 apparently...

As stated somewhere else, by renaming /etc/acpi/video_brightness<up/down>.sh or modifying their contents to e.g.
#!/bin/sh

test -f /usr/share/acpi-support/key-constants || exit 0

. /usr/share/acpi-support/key-constants
#acpi_fakekey $KEY_BRIGHTNESSUP

the screen brightness won't double-change anymore. However, what I notice is that when for instance reducing the brightness, it first goes to the minimum, and then immediately to the desired level. The same applies for increasing brightness: it first jumps to the maximum, and then to the desired level, what is not really healthy for the LCD backlight... The change is usually so fast that one can hardly notice it.
If I use the brightness applet, everything works fine, except that the applets still states that it cannot get the panel brightness (though working fine!).

The original problem observed in gnome-power-manager (that is multiple levels change of back-light using Fn keys when g-p-m is running) is not yet resolved. It started for me after upgrading to 8.04 and is still there after upgrading to 8.10. My system is a Dell Inspiron 6400.

The odd thing I want to report is that after upgrading to 8.10, using Fn keys to adjust brightness changes the brightness randomly. At least in 8.04 it always changed in double levels. But now in Intrepid, using Fn keys, the brightness level changes by 1, 2 or 3 levels with no pattern and changes in a random fashion.

Another odd observation, IMHO, is that such a nasty bug that affects so many of us linger for so long. Where doth the problem lie?!

On my xps 1330, the two workarounds behave as follows:

- putting "blacklist video" in /etc/modprobe.d/blacklist

The brightness keys work fine, the only issue is that the brightness indicator does not appear when you press the buttons.

NOTE: this workaround was causing a serious problem, disabling keyboard events after changing the brightness (bug #261721). However, this bug was fixed by the 2.6.27-8 kernel (available in proposed), so with this kernel the workaround can be used again.

- deleting /etc/acpi/video_brightness<up/down>.sh

This also works, including the brightness indicator. However, as reported by Sandro Mani above, the brighness jumps to 100% and then quickly back to the desired level, which is annoying and potentially harmful for the screen.

So I personally prefer the first workaround for now (hoping for a fix soon)

This may be related to bug #257827, on that bug we have built some test kernels with fixes for some systems which show this issue. If you are running/able to test with intrepid kernels there are some recent test kernels at the url below. If you could test those and report back that would be useful:

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

On my Dell XPS 1330, the test kernel (i386) doesn't seem to make any difference. Without the workarounds, brightness increases twice at each press. The two workarounds behave exactly as I describe in my previous post (two posts above).

Andy, the bug is still present using the kernel you linked to. This is on a Dell 640m, i386.

Thanks for those who have tested, clearly this is not related directly.

@Mario Limonciello -- you mentioned applying an upstream patch, which an updated version was applied to the test kernels above. Could you see if this fixes your case.

Could those still suffering this problem confirm if this is still a problem with the gnome-power-manager updates from -proposed which are slated to fix a number of brightness control issues.

Not fixed with g-p-m from intrepid-proposed on my Thinkpad T61. G-p-m still reports one brigtness-down keypress as two.

Still an issue after the updates on my dell xps m1330.

Just tested Jaunty Alpha 2 with kernel 2.6.28-3 and it is not fixed there either, despite the patch having been applied to 2.6.28-rc4.

Hello all,

I have a XPS 1330 with Intel GM965/GL960. Ubuntu Intrepid.

This problem is resolved for me installing the new version of xserver-xorg-video-intel -> 2.5.1

I installed it from this PPA: https://launchpad.net/~intel-gfx-testing/+archive

Regards

Would someone with some specific knowledge into this issue take a minute to see if bug 257827 is a duplicate of this one? Thanks!

As far as I can tell bug 257827 covers the kernel part of this bug. As only the kernel part of this bug is still open and bug 257827 seems to contain the most information regarding that part of the bug, I would suggest marking this bug as a duplicate of bug 257827 (eg. letting bug 257827 be the master-bug).

If the package xserver-xorg-video-intel -> 2.5.1 fixes the problem, can it be backported to Hardy?

Tested Jaunty latest cdlive. The bug is still there.
Given that Dell actually sells the laptops affected by this bug with Ubuntu preinstalled, it seems incredible to me that after more than a year the bug is still not fixed.

I don't see this bug in Jaunty Alpha 6. Fixed maybe.

I can confirm what Mike B. said, I haven't experienced this on my XPS
M1330 since a fresh install of Alpha 5. However I believe this is the
same laptop Mike B. has, so if this affects more than this specific
model it might be good to get confirmations there.

Unfortunately I can confirm that on my xps m1330 with intel x3100 and jaunty 64bit up-to-date the problem still occurs.

The behaviour has changed, however: before Jaunty the levels I could cycle through where always 4. Now it varies, sometimes 4, sometimes 5, others 6.

As usual, stopping g-p-m makes the FN+Up/Down work fine: 8 brightness levels to choose from.

Any hope to see this bug really fixed?

Appears to be fixed for me on my T61 (nvidia quadro nvs 140m) with 32-bit Jaunty final

Yes, Jaunty has fixed this issue on my Dell XPS M1330 as well.

Sounds like this can be considered fixed on the Dell laptops now, for jaunty and beyond.

Users of non-Dell laptops who are experiencing similar symptoms should file separate bug reports (preferably, after checking whether the problem still affects them with Ubuntu 9.04).

Can somone confirm that the bug is fixed on Dell m1330 with intel graphics?

I have such a model and I keep seeing double changes in brightness when I press FN+Up or Down and g-p-m is running. Also using latest intel drivers did not help. Using the .30 mainline kernel does give one-step increments, however the scale of the slider gets much bigger than eight steps as it should be on this model.

I can confirm that this is fixed in my Dell Inspiron 6400.

But a new problem is introduced: when pressing Ctrl+Fn Down immediately
after Ctrl+Fn Up (or vise versa), the brightness continues to go up, as if
it has an inertia. Of course, this may be a bug with Jaunty's new
notification system.

On Fri, Apr 24, 2009 at 5:07 AM, Steve Langasek <
<email address hidden>> wrote:

> Sounds like this can be considered fixed on the Dell laptops now, for
> jaunty and beyond.
>
> Users of non-Dell laptops who are experiencing similar symptoms should
> file separate bug reports (preferably, after checking whether the
> problem still affects them with Ubuntu 9.04).
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Fix Released
>
> --
> Screen brightness double level changes on Dell laptops
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Use the stylish "X Series 2" standard Persian fonts. Download from here:
http://wiki.irmug.org/index.php/X_Series_2#Download_fonts

Please spread the word!

On Fri, May 8, 2009 at 7:58 AM, Guido Conaldi <email address hidden> wrote:
> Can somone confirm that the bug is fixed on Dell m1330 with intel
> graphics?

For clarity, my aforementioned resolution was on an XPS 1300 with
nvidia, not intel.

Amir,

The new notification system has no bearing on how hotkeys are handled. If you're seeing a hotkey having the wrong effect, please follow the troubleshooting guide at https://wiki.ubuntu.com/Hotkeys/Troubleshooting to determine where in the system the second hotkey is going wrong, and file a new bug on the corresponding package.

Thanks Steve,

After I looked more deeply into the problem, I found that the problem is not
with brightness level changes -- it changes correctly when I press
Fn+Up/Down keys.

The problem is that there are 6 brightness levels (as reported in
'/proc/acpi/video/VID/LCD/brightness'), which are 12, 24, 36, 48, 60, 72, 84
and 100, whereas the brightness pop-up (of the new notification system)
shows 7 levels; That's why it seems to get confused when showing the
brightness levels while the brightness is changing correctly. For example,
when LCD brightness is at level 0 (lowest), it still shows the brightness at
level 1.

I don't know exactly which package I should submit this bug against. Could
you help? And sorry if I disscussed the isse in the wrong place.

On Sat, May 9, 2009 at 1:09 PM, Steve Langasek <<email address hidden>
> wrote:

> Amir,
>
> The new notification system has no bearing on how hotkeys are handled.
> If you're seeing a hotkey having the wrong effect, please follow the
> troubleshooting guide at https://wiki.ubuntu.com/Hotkeys/Troubleshooting
> to determine where in the system the second hotkey is going wrong, and
> file a new bug on the corresponding package.
>
> --
> Screen brightness double level changes on Dell laptops
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I made a mistake. There 8 levels of brightness reported, and the brightness
pop-up also shows 8 levels correctly.
The problem is that one level is sometimes jumped over randomly. I'll read
the link you sent more carefully again and try find the source of the
problem.

Thanks.

On Sat, May 9, 2009 at 2:20 PM, Amir Reza Khosroshahi <
<email address hidden>> wrote:

> Thanks Steve,
>
> After I looked more deeply into the problem, I found that the problem is
> not with brightness level changes -- it changes correctly when I press
> Fn+Up/Down keys.
>
> The problem is that there are 6 brightness levels (as reported in
> '/proc/acpi/video/VID/LCD/brightness'), which are 12, 24, 36, 48, 60, 72, 84
> and 100, whereas the brightness pop-up (of the new notification system)
> shows 7 levels; That's why it seems to get confused when showing the
> brightness levels while the brightness is changing correctly. For example,
> when LCD brightness is at level 0 (lowest), it still shows the brightness at
> level 1.
>
> I don't know exactly which package I should submit this bug against. Could
> you help? And sorry if I disscussed the isse in the wrong place.
>
>
> On Sat, May 9, 2009 at 1:09 PM, Steve Langasek <
> <email address hidden>> wrote:
>
>> Amir,
>>
>> The new notification system has no bearing on how hotkeys are handled.
>> If you're seeing a hotkey having the wrong effect, please follow the
>> troubleshooting guide at https://wiki.ubuntu.com/Hotkeys/Troubleshooting
>> to determine where in the system the second hotkey is going wrong, and
>> file a new bug on the corresponding package.
>>
>> --
>> Screen brightness double level changes on Dell laptops
>> https://bugs.launchpad.net/bugs/207473
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>
>
>
>
>

--
Use the stylish "X Series 2" standard Persian fonts. Download from here:
http://wiki.irmug.org/index.php/X_Series_2#Download_fonts

Please spread the word!

OMG, fresh karmic kubuntu clean install on Dell Inspiron 1520, and bug is still here:
$ lshal -m

Start monitoring devicelist:
-------------------------------------------------
08:27:42.662: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
08:27:42.676: computer_logicaldev_input condition ButtonPressed = brightness-up
08:27:44.339: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
08:27:44.352: computer_logicaldev_input condition ButtonPressed = brightness-down
08:27:46.348: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
08:27:46.348: computer_logicaldev_input condition ButtonPressed = brightness-up

There were single brightness-up and single brightness-down pressed.
The bug is 1.5 years old. Is it going to be fixed someday?

Why do you think this is the same bug when this bug report has been marked as fixed since Ubuntu 8.10?

Look at lshal's output in beginning of the thread, and in my previos message.
They are the same!

--------- 2008-03-27: -------------
$ lshal -m
Start monitoring devicelist:
 -------------------------------------------------
 12:55:17.525: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
 12:55:17.525: computer_logicaldev_input condition ButtonPressed = brightness-up
 12:55:18.012: computer_power_supply_battery_BAT0 property battery.voltage.current = 12542 (0x30fe)
 12:55:18.738: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
 12:55:18.754: computer_logicaldev_input condition ButtonPressed = brightness-down

---------- 2009-10-30 -----------------
$ lshal -m
Start monitoring devicelist:
 -------------------------------------------------
 08:27:42.662: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
 08:27:42.676: computer_logicaldev_input condition ButtonPressed = brightness-up
 08:27:44.339: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
 08:27:44.352: computer_logicaldev_input condition ButtonPressed = brightness-down
 08:27:46.348: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
 08:27:46.348: computer_logicaldev_input condition ButtonPressed = brightness-up

Reopening the linux task, then. afunix, please look at https://wiki.ubuntu.com/Hotkeys/Troubleshooting to help is figure out why you're getting two events instead of one.

$ xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
keycode 36 = (keysym 0xff0d, Return), state = 0x0
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

xkbmap.txt
----------------------------
xkb_keymap {
 xkb_keycodes { include "evdev+aliases(qwerty)" };
 xkb_types { include "complete" };
 xkb_compat { include "complete+ledscroll(group_lock)" };
 xkb_symbols { include "pc+us+ru:2+inet(evdev)+group(ctrl_shift_toggle)+level3(ralt_switch)" };
 xkb_geometry { include "pc(pc105)" };
};

I'm using kubuntu, so I can't apply gnome-*/gconf* instructions

ACPI says:

$ acpi_listen
video LCD 00000086 00000000
video LCD 00000087 00000000

And I can change brightness normally in console and echoing to /sys/class/backlight/.../brightness

Afunix: I found a work-around to this problem.
Open up "Global Keyboard Shortcuts" in system settings and select "KDE Daemon" in the
KDE Component drop-down.
There you should see the Decrease/Increase screen brightness, I just set both to
custom: none and after that I only got one brightness-change for each keypress,
however I still get two events in `lshal -m` and in xev.
I can live without a progress bar telling me how bright my screen is, after all I'm looking at it.

Yes. It works.
So, does acpid set brightness?
How should both systems (acpi and kde) work together?

i am running a fresh install of 9.10 on a Dell XPS M1330 laptop

getting two events per each keypress:

11:07:03.785: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up
11:07:03.799: computer_logicaldev_input condition ButtonPressed = brightness-up

11:07:05.477: computer_logicaldev_input condition ButtonPressed = brightness-down
11:07:05.477: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down

xev output looks normal (one down, one up event for each keypress). The output of acpi_listen doesn't show any events that acpid/acpi-support react to by default.

Please try stopping acpid (sudo service stop acpid) and test again, and see whether this makes any difference (I don't expect that it will).

Please also attach the output of 'lshal'.

You were right, after "sudo service acpid stop" nothing changed.

Thanks. Please run each of the following commands, and confirm that you see output with each when pressing the brightness-up key:

  sudo /lib/udev/keymap -i input/event4
  sudo /lib/udev/keymap -i input/event5

I get this:

revorm@sovereign:~$ sudo /lib/udev/keymap -i input/event4
Press ESC to finish
scan code: 0x86 key code: brightnessup
scan code: 0x85 key code: brightnessdown
scan code: 0x86 key code: brightnessup
scan code: 0x85 key code: brightnessdown
scan code: 0x01 key code: esc
revorm@sovereign:~$ sudo /lib/udev/keymap -i input/event5
Press ESC to finish
scan code: 0x00 key code: brightnessup
scan code: 0x00 key code: brightnessdown
scan code: 0x00 key code: brightnessup
scan code: 0x00 key code: brightnessdown

On Tuesday 03 November 2009 10.27.20 Steve Langasek wrote:
> Thanks. Please run each of the following commands, and confirm that you
> see output with each when pressing the brightness-up key:
>
> sudo /lib/udev/keymap -i input/event4
> sudo /lib/udev/keymap -i input/event5
>

Single brightness-up press gives single event:
$ sudo /lib/udev/keymap -i input/event4
Press ESC to finish
scan code: 0x86 key code: brightnessup
scan code: 0x01 key code: esc
$ sudo /lib/udev/keymap -i input/event5
Press ESC to finish
scan code: 0x00 key code: brightnessup

/lib/udev/keymap does not detect pressed ESC with event5.

I just want to mention that on my Dell XPS 1330 with Karmic, I do NOT
experience this issue at all, everything regarding brightness works as
expected out of the box.

I wonder if this affects only KDE or not, Michael, are you running KDE or
something else?

On Tuesday 03 November 2009 20.38.35 Michael Rooney wrote:
> I just want to mention that on my Dell XPS 1330 with Karmic, I do NOT
> experience this issue at all, everything regarding brightness works as
> expected out of the box.
>

I can confirm that on Gnome Karmic on my xps M 1330 I also do not experience the issue, didn't tested under KDE as I never used Kubuntu.

I've been using Kubuntu (KDE on Ubuntu) for a couple years. Once I
installed Kubuntu on my new Dell XPS M1330 a couple years ago, I found a
workaround to fix the double brightness issue; which was to blacklist video
module. It worked but when I upgraded to 9.10 that no longer worked.

On Tue, Nov 3, 2009 at 11:50 AM, Mikael Gerdin <email address hidden>wrote:

> I wonder if this affects only KDE or not, Michael, are you running KDE or
> something else?
>
> On Tuesday 03 November 2009 20.38.35 Michael Rooney wrote:
> > I just want to mention that on my Dell XPS 1330 with Karmic, I do NOT
> > experience this issue at all, everything regarding brightness works as
> > expected out of the box.
> >
>
> --
> Screen brightness double level changes on Dell laptops
> https://bugs.launchpad.net/bugs/207473
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The Linux Kernel: Fix Released
> Status in “hal” package in Ubuntu: Invalid
> Status in “kde-guidance” package in Ubuntu: Fix Released
> Status in “linux” package in Ubuntu: Confirmed
> Status in hal in Ubuntu Hardy: Invalid
> Status in kde-guidance in Ubuntu Hardy: Fix Released
> Status in linux in Ubuntu Hardy: Confirmed
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> I have a fresh installation of Hardy with the latest updates installed on a
> Dell Inspiron 6400 laptop. The brightness settings (Fn+Up/Down) work
> although they seem to skip a level each time.
>
> '/proc/acpi/video/VID/LCD/brightness' tells me that it supports brightness
> levels 12, 24, 36, 48, 60, 72, 84 and 100. Without gnome-power-manager
> running pressing Fn+Up will transition up into each level and back down
> again smoothly.
>
> When gnome-power-manager is running increasing the brightness from 12 I can
> only get levels 36, 60, 84 and 100. Decreasing the levels from 100 I only
> get 72, 48, 24 and 12. Running gnome-power-manager with the verbose option
> shows that when I press the brightness-up button once it is recorded twice.
> I ran gnome-power-manager in a debugger thinking it was a timing issue and
> it still happened.
>
> I have included the output from pressing the brightness-up button (Fn+Up)
> once below. This only happens when gnome-power-manager is running and did
> not happen using Feisty. I have looked at the code and I cannot see why the
> button event is triggered twice, I don't have any experience of the code but
> if you can give me any ideas of where to start I can try to look into this
> myself.
>
> Thanks!
>
>
> [hal_device_condition_cb] gpm-button.c:391 (00:11:48):
> condition=ButtonPressed, details=brightness-up
> [emit_button_pressed] gpm-button.c:335 (00:11:48): emitting
> button-pressed : brightness-up
> [button_pressed_cb] gpm-manager.c:999 (00:11:48): Button press event
> type=brightness-up
> [button_pressed_cb] gpm-srv-screensaver.c:167 (00:11:48): Button
> press event type=brightness-up
> [button_pressed_cb] gpm-backlight.c:563 (00:11:48): Button press event
> type=brightness-up
> [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (00:11:48):
> GetBrightness returned level: 0
> [gpm_brig...

Thanks, that confirms that the keypress event is being shown twice on two different kernel input devices. This is definitely a kernel bug - marking as triaged, and handing it over to the kernel team.

I have some interesting behavior to report -- brightness change hotkeys interacting with Gnome-Do with a fresh install Karmic Koala 9.10 on XPS M1330

1. I have access to 5 brightness levels (bug) via the brightness hotkeys: brightest/dimmest plus four additional key presses
2. I SHOULD have access to 8 brightness levels via the brightness hotkeys: brightest/dimmest plus 7 additional key presses
3. With Gnome-Do running: Press <super>space to active the Gnome-Do search function. Adjust brightness: have access to all 8 brightness levels via brightness hotkeys, but no brightness notification appears in the upper right corner upon keypress. "lshal -m" still outputs two button press events per keypress

This sounds like a bug with Compiz?

aahh, never mind. <super>space with Gnome-Do stops all other software input, effectively blocking gnome-power-manager from registering the brightness keypresses, giving access to all brightness levels.

stopping gnome-power-manager produces access to all 8 brightness levels via brightness hotkeys.

this seems like a bug with gnome-power-manager on Karmic Koala 9.10 still...

On Tue, Nov 3, 2009 at 11:50 AM, Mikael Gerdin wrote:
> I wonder if this affects only KDE or not, Michael, are you running KDE or
> something else?

I am indeed using Ubuntu and not Kubuntu.

verified the commit in Lucid. Marked Fix Released. Declined nomination for Intrepid.

-JFo

Okay, so... where is the fix?
I'm a complete Linux newbie, but I'm raging right now because everything is so fricking hard to find out about. Yes, I am smashing my head and my fists against a brick wall right now. :)

I should have just downgraded to 7.10 right now, but then I wouldn't be able to activate my graphics card drivers, because they stop supporting the current Linux distrubation after two days.

Does this issue still exist in Hardy Heron?

I still have this problem in Natty. If I kill gnome-power-manager and acpid, I can still change the brightness (I get all 8 steps that way). But I get no output at all with either lshal -m or sudo /lib/udev/keymap -i input/event4 and sudo /lib/udev/keymap -i input/event5 in this mode. Is the brightness being changed by the bios?

I have similar problem on my HP 6715s. I think bios controls the brightness, and when I change the brightness, it goes 2 steps.
Ubuntu 11.04 x64

I can confirm this bug on Dell Inspiron 1520 and fresh Ubuntu Natty

Is three years is not enough to fix this bug?
There were seven releases!
hardy [LTS]. intrepid. jaunty. karmic. lucid [LTS]. maverick. natty.

Similar problem on my ThinkPad T400, but with steps of two or three.
cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness goes 0 -> 2 -> 5 -> 8 -> 11 -> 14 -> 15 (max), down: -> 13 -> 11 -> 8 -> 6 -> 3 -> 0. Manual setting of each single step via panel is possible.
I haven't had this on maverick, if that is any help.

lshal -m does not generate any output.

I'm also having this problem on a Dell Latitude E6410 with Ubuntu 11.04, using the Classic (no effects) desktop.

A new (I think) detail, though:
If I have a menu open in the panel, any menu (applications, places, system, volume, time/date, etc), and try changing the brightness with it open, it only changes by one level. As soon as I leave the menu, it goes back to changing two levels back to back, for one button-press.

lshal -m gives me "The program 'lshal' is currently not installed. You can install it by typing: sudo apt-get install hal"

Is there anything else I should try and post the results?

Yeah! Cool!
It is a three-year-old bug and I can still reproduce it in Ubuntu 11.10!

Let's leave this bug for the third LTS! I will miss this one if someday it will be fixed!

I'm also still experiencing this bug in 11.10, although now the brightness level changes by 3 steps instead of 2 when pressing the brighntess-up/down key once.
It's interesting that this happens just after login in. On the login screen (LightDM) it's working fine, so maybe it's still a gnome-related bug?

No. This bug can be found in kde and gnome. It looks like hal-related bug. You can switch to console (Alt-Ctrl-F1) and change brightness by one step.
This behavoir is known since April 2008...

And I can confirm that pressing brightness-up/down changes brightness by 3 steps.

I'm using ubuntu, lubuntu, and kubuntu 11.10 and thinkpad T520. Pressing brightness-up/down changes brightness by 3 steps.

I have this bug ever since I first started using Ubuntu - please don't take it away...

OK, in all seriousness, this is not a workaround, but I find it useful https://launchpad.net/~indicator-brightness/+archive/ppa

I was using Ubuntu 11.10 (32 bit) on a ThinkPad W510, and having this problem. Fn+Down decreased brightness by 2 steps, and Fn+Up increased it by 3 steps.

I just changed my installation to Xubuntu 11.10 64 bit, and am having the same issue, thus it's not specific to Gnome nor KDE. I don't have HAL installed. The two commands below have no effect:

/etc/init.d/acpid stop
/etc/init.d/hal stop (No such file or directory)

The temporary workaround is described in the comment by Kuba Górski. I can also overwrite the brightness file to set the desired level (0-15).

The same problem. 4 events. The brightnes in/decrased by 2 steps:
Ubuntu 11.10 Unity
Ubuntu 11.10 Gnome-shell

$ cat /sys/class/dmi/id/sys_vendor
Hewlett-Packard
$ cat /sys/class/dmi/id/product_name
HP Pavilion dm4 Notebook PC

$ sudo killall gnome-settings-daemon
$ /etc/init.d/acpid stop
$ /etc/init.d/hal stop (No such file or directory)

$ sudo /lib/udev/keymap -i input/eventX
.....
# single decrease brightness button pressed
got scan code event 0xAB without a key code event
got scan code event 0xAB without a key code event
.....
# single increase brightness button pressed (YES !!! the same key-code)
got scan code event 0xAB without a key code event
got scan code event 0xAB without a key code event
.....

$ xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
...
# single decrease brightness button pressed
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
keycode 232 = (keysym 0x1008ff03, XF86MonBrightnessDown), state = 0x0
# single increase brightness button pressed
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0
keycode 233 = (keysym 0x1008ff02, XF86MonBrightnessUp), state = 0x0

I think that's all...

Binding these commands to other hotkeys helps me.... not critical but ....
xbacklight -inc 10
xbacklight -dec 10

One more thing respectively to my previous comment:

$ acpi_listen
# single brightness down button pressed (Fn+F2)
video DD02 00000087 00000000
video DD02 00000087 00000000
# single brightness up button pressed (Fn+F3)
video DD02 00000086 00000000
video DD02 00000086 00000000

> $ cat /sys/class/dmi/id/product_name
> HP Pavilion dm4 Notebook PC

This bug report is about Dell laptops. Please open a separate bug report for your issue.

I have seen Lenovo bug notify here too... I don't think it is related with vendor Dell...

The bug report is titled too narrowly, as the problem obviously encompasses multiple hardware platforms. This should be a clue for the developers.

On Fri, Mar 23, 2012 at 10:54:31AM -0000, Daniel Ansari wrote:
> The bug report is titled too narrowly

No, because if you're seeing such a symptom on different hardware, it is an
*unrelated bug* and you should file a new bug report.

Confirmed here, since a lot a Ubuntu release, now:

Ubuntu 11.10 64-bit, kernel Linux 3.2.13 on Dell XPS M1330 Intel graphic x3100. This behaviour occur both with main graphics driver than with the onces included in this PPA https://launchpad.net/~oibaf/+archive/graphics-drivers

I think it's not just the brightness, either. It seems to be the
multimedia keys as well. Just trying to pause the music player with
the pause button on my Dell XPS M1330 is very difficult, because
pressing the pause button sends it twice, so the music pauses and
instantly unpauses. If I tap it a bunch of times, I eventually get
lucky and end up with an uneven number of keypresses received. The
same happens with next/previous and volume buttons (e.g. mute works
the same as pause).

Adam, I think you issue with pause/next/prev buttons is something different. Because everyone in this thread has problem with brightness and noone reported problem with these keys. Actually, I have "doblue-brightness" issue on my Dell Inspiron 1520 (with 12.04 beta 2!! will it ever be fixed?!) and pause/prev/next buttons work just fine.

Ubuntu 12.10.. The bug is still here.

ditto on a Dell Inspiron 1440 -- still here. no workarounds that i know of

Dell XPS m1330 -- adding "acpi_backlight=vendor" to grub boot parameters
resolves the issue

ethan

On Mon, Nov 5, 2012 at 8:55 AM, Pavel Malyshev <email address hidden>wrote:

> Ubuntu 12.10.. The bug is still here.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/207473
>
> Title:
> Screen brightness double level changes on Dell laptops
>
> Status in The Linux Kernel:
> Fix Released
> Status in “hal” package in Ubuntu:
> Invalid
> Status in “kde-guidance” package in Ubuntu:
> Fix Released
> Status in “linux” package in Ubuntu:
> Fix Released
> Status in “hal” source package in Hardy:
> Invalid
> Status in “kde-guidance” source package in Hardy:
> Fix Released
> Status in “linux” source package in Hardy:
> Confirmed
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> I have a fresh installation of Hardy with the latest updates installed
> on a Dell Inspiron 6400 laptop. The brightness settings (Fn+Up/Down)
> work although they seem to skip a level each time.
>
> '/proc/acpi/video/VID/LCD/brightness' tells me that it supports
> brightness levels 12, 24, 36, 48, 60, 72, 84 and 100. Without gnome-
> power-manager running pressing Fn+Up will transition up into each
> level and back down again smoothly.
>
> When gnome-power-manager is running increasing the brightness from 12
> I can only get levels 36, 60, 84 and 100. Decreasing the levels from
> 100 I only get 72, 48, 24 and 12. Running gnome-power-manager with the
> verbose option shows that when I press the brightness-up button once
> it is recorded twice. I ran gnome-power-manager in a debugger thinking
> it was a timing issue and it still happened.
>
> I have included the output from pressing the brightness-up button
> (Fn+Up) once below. This only happens when gnome-power-manager is
> running and did not happen using Feisty. I have looked at the code and
> I cannot see why the button event is triggered twice, I don't have any
> experience of the code but if you can give me any ideas of where to
> start I can try to look into this myself.
>
> Thanks!
>
>
> [hal_device_condition_cb] gpm-button.c:391 (00:11:48):
> condition=ButtonPressed, details=brightness-up
> [emit_button_pressed] gpm-button.c:335 (00:11:48): emitting
> button-pressed : brightness-up
> [button_pressed_cb] gpm-manager.c:999 (00:11:48): Button press
> event type=brightness-up
> [button_pressed_cb] gpm-srv-screensaver.c:167 (00:11:48): Button
> press event type=brightness-up
> [button_pressed_cb] gpm-backlight.c:563 (00:11:48): Button press
> event type=brightness-up
> [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (00:11:48):
> GetBrightness returned level: 0
> [gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (00:11:48):
> Setting 1 of 7
> [gpm_brightness_lcd_up] gpm-brightness-lcd.c:362 (00:11:48): emitting
> brightness-changed (14)
> [brightness_changed_cb] gpm-backlight.c:755 (00:11:48): Need to
> display backlight feedback value 14
> [gp...

This release has reached end-of-life [0].

[0] https://wiki.ubuntu.com/Releases

Are you serios? This bug is confirmed in 12.04 and 13.04. It can't be invalid!

Is this a HAL problem? It's still a problem in 14.04 LTS...

Just FYI:
The bug, which Ubuntu cannot fix for 7 (SEVEN!!!) years, was fixed in Fedora in 1.5 months: https://bugzilla.redhat.com/show_bug.cgi?id=1141525

adding "acpi_backlight=vendor acpi_osi=linux" to grub boot options:
a. fully fixes this problem in a Dell Inspiron 1545 running 14.04 (all
behavior normal and as expected, including indicator popups for brightness
adjustment)
b. partially fixes the problem in a Dell Inspiron 1440 running 12.04 (full
access to all brightness levels via dedicated buttons, indicator pops up
but does not visually exhibit a brightness level change)

ethan

“A society grows great when its elders plant trees whose shade they know
they shall never sit in.” -- an ironic Greek proverb

On Sun, Aug 30, 2015 at 3:30 AM, Pavel Malyshev <email address hidden>
wrote:

> Just FYI:
> The bug, which Ubuntu cannot fix for 7 (SEVEN!!!) years, was fixed in
> Fedora in 1.5 months: https://bugzilla.redhat.com/show_bug.cgi?id=1141525
>
> ** Bug watch added: Red Hat Bugzilla #1141525
> https://bugzilla.redhat.com/show_bug.cgi?id=1141525
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/207473
>
> Title:
> Screen brightness double level changes on Dell laptops
>
> Status in Linux:
> Fix Released
> Status in hal package in Ubuntu:
> Invalid
> Status in kde-guidance package in Ubuntu:
> Fix Released
> Status in linux package in Ubuntu:
> Fix Released
> Status in hal source package in Hardy:
> Invalid
> Status in kde-guidance source package in Hardy:
> Fix Released
> Status in linux source package in Hardy:
> Invalid
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> I have a fresh installation of Hardy with the latest updates installed
> on a Dell Inspiron 6400 laptop. The brightness settings (Fn+Up/Down)
> work although they seem to skip a level each time.
>
> '/proc/acpi/video/VID/LCD/brightness' tells me that it supports
> brightness levels 12, 24, 36, 48, 60, 72, 84 and 100. Without gnome-
> power-manager running pressing Fn+Up will transition up into each
> level and back down again smoothly.
>
> When gnome-power-manager is running increasing the brightness from 12
> I can only get levels 36, 60, 84 and 100. Decreasing the levels from
> 100 I only get 72, 48, 24 and 12. Running gnome-power-manager with the
> verbose option shows that when I press the brightness-up button once
> it is recorded twice. I ran gnome-power-manager in a debugger thinking
> it was a timing issue and it still happened.
>
> I have included the output from pressing the brightness-up button
> (Fn+Up) once below. This only happens when gnome-power-manager is
> running and did not happen using Feisty. I have looked at the code and
> I cannot see why the button event is triggered twice, I don't have any
> experience of the code but if you can give me any ideas of where to
> start I can try to look into this myself.
>
> Thanks!
>
>
> [hal_device_condition_cb] gpm-button.c:391 (00:11:48):
> condition=ButtonPressed, details=brightness-up
> [emit_button_pressed] gpm-button.c:335 (00:11:48): emitting
> button-pressed : brightness-up
> [button_pressed_cb] gpm-manager.c:999 (00:11:48): Button press
> event type=brightness-up
> [button_pressed_cb...

The Fedora fix seems much more elegant and less invasive by simply finding
and eliminating a software keymapping duplicate of hardware/bios activated
keys, if it's the same issue! Maybe it's part of the fix, because the
Inspiron 1545 running 14.04 already has those changes in its
/lib/udev/hwdb.d/60-keyboard.hwdb

# Dell Inspiron 1520
keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnInspiron*1520:pvr*
 KEYBOARD_KEY_85=unknown # Brightness Down, also emitted by acpi-video,
ignore
 KEYBOARD_KEY_86=unknown # Brightness Up, also emitted by acpi-video,
ignore

although perhaps we need to generalize this to more Dells and activate it
via the computer model identifier referenced in the Fedora bug?

ethan

“A society grows great when its elders plant trees whose shade they know
they shall never sit in.” -- an ironic Greek proverb

On Mon, Aug 31, 2015 at 2:07 PM, ethan a young <email address hidden> wrote:

> adding "acpi_backlight=vendor acpi_osi=linux" to grub boot options:
> a. fully fixes this problem in a Dell Inspiron 1545 running 14.04 (all
> behavior normal and as expected, including indicator popups for brightness
> adjustment)
> b. partially fixes the problem in a Dell Inspiron 1440 running 12.04 (full
> access to all brightness levels via dedicated buttons, indicator pops up
> but does not visually exhibit a brightness level change)
>
> ethan
>
> “A society grows great when its elders plant trees whose shade they know
> they shall never sit in.” -- an ironic Greek proverb
>
>
> On Sun, Aug 30, 2015 at 3:30 AM, Pavel Malyshev <<email address hidden>
> > wrote:
>
>> Just FYI:
>> The bug, which Ubuntu cannot fix for 7 (SEVEN!!!) years, was fixed in
>> Fedora in 1.5 months: https://bugzilla.redhat.com/show_bug.cgi?id=1141525
>>
>> ** Bug watch added: Red Hat Bugzilla #1141525
>> https://bugzilla.redhat.com/show_bug.cgi?id=1141525
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/207473
>>
>> Title:
>> Screen brightness double level changes on Dell laptops
>>
>> Status in Linux:
>> Fix Released
>> Status in hal package in Ubuntu:
>> Invalid
>> Status in kde-guidance package in Ubuntu:
>> Fix Released
>> Status in linux package in Ubuntu:
>> Fix Released
>> Status in hal source package in Hardy:
>> Invalid
>> Status in kde-guidance source package in Hardy:
>> Fix Released
>> Status in linux source package in Hardy:
>> Invalid
>>
>> Bug description:
>> Binary package hint: gnome-power-manager
>>
>> I have a fresh installation of Hardy with the latest updates installed
>> on a Dell Inspiron 6400 laptop. The brightness settings (Fn+Up/Down)
>> work although they seem to skip a level each time.
>>
>> '/proc/acpi/video/VID/LCD/brightness' tells me that it supports
>> brightness levels 12, 24, 36, 48, 60, 72, 84 and 100. Without gnome-
>> power-manager running pressing Fn+Up will transition up into each
>> level and back down again smoothly.
>>
>> When gnome-power-manager is running increasing the brightness from 12
>> I can only get levels 36, 60, 84 and 100. Decreasing the levels from
>> 100 I only get 72, 48, 24 and 12. Running gnom...