Brightness controls skips Levels.

Thanks for taking the time to report this bug and helping to make Ubuntu better. Could you please run apport-collect -p gnome-power-manager 527157 ? You might also want to take a look at the debugging instructions located at https://wiki.ubuntu.com/DebuggingGNOMEPowerManager and submit any other logs related to your problem. Thanks in advance.

I'd love to run apport-collect, but it crashes and won't send the bug report :) I did forget to mention that I'm on x86_64.

output of /usr/share/gnome-power-manager/gnome-power-bugreport

dmidecode log per https://wiki.ubuntu.com/DebuggingACPI

lspci as per https://wiki.ubuntu.com/DebuggingACPI

uname per https://wiki.ubuntu.com/DebuggingACPI

set to triaged/low as per Anzenketh's request.

Is there any other information that I can provide to help out? I understand this is low priority, but I'm hoping someone will have a "Eureka!" moment and find a workaround/fix.

It being set to Triaged means we have everything that we need. It is unlikely with this issue there is a workaround at this moment you will have to wait for a fix. If you know anything about programing you might want to look into a possibility of you making a patch yourself.

I tested this in Arch, and it affects Arch's current version as well. Every version of GPM I've seen seems to have this issue. Kubuntu's power manager does not have this problem. I looked into the code for GPM, and noticed that xrandr is used to adjust the brightness. The HAL code has an option to check an fdi for brightness_in_hardware, but the xrandr code does not have any similar option. My C kung-fu is not sufficient to fix this problem on my own at this time, but I will continue to work at it. \

I don't think we want to disable xrandr entirely for this model, since this would likely break stuff like "dim after a few minutes" or dim on battery. Instead, I think there should be an option to disable brightness up and down events being controlled by xrander, based on gconf or a setting in GPM.

I solved this problem by adding a gconf key, named brightness_in_hardware (reminiscent of HAL), for setting whether or not to use xrandr for stepping the brightness up/down. Please test my patch (agaist gpm 2.30.1) and see if it works for you.

Here's the updated patch.

Patch updated:
- Honor brightness_in_hardware setting regardless of the backend used (xrandr, HAL, or whatever future backend; for consistent behavior)
- Set default value of brightness_in_hardware to 'true' (most people would probably set this to 'true' anyway)

I made the modification to apply to gnome-power-manager-2.32.0 tarball in Maverick.

Please, test it.

For me it solve everything with brightness

 * Adding /apps/gnome-power-manager/backlight/brightness_in_hardware key.
  It is just workaround to prevent g-p-m from adjusting brightness,
  if Fn + Brightness Key was pressed. It must fixed:
  LP: #527157 - Skipping levels in case of Fn + Brightness Key
  LP: #415023 - Flushing or flickering on MSI WIND U100 with not-updated Bios (all clones too)
  LP: #261635 - Fn + Brightness keys could be added to /lib/udev/rules.d/95-keymap.rules
  to make them known.

Thanks everyone, i've fixed my backlight problem with following steps:
1) set options video brightness_switch_enabled=0
to /etc/modprobe.d/video.conf
2) compile and install patched gnome-power-manager

Hope this changes will go to upstream. The only minor problem is that gnome-power-manager is not using libnotify's baloons similar to sound adjustment one, instead it spawns widget in bottom-middle of the screen.

Tested Konstantin Lavrov's patch (Comment #15) in Natty (11.04). worked like a charm. With the patch, double brightness events are now gone in my Alienware M11xR2 as well. Please commit ASAP!

A patched GPM is available from my PPA: https://launchpad.net/~baudm/+archive/backports
The packages incorporate the original patch that I've posted here.

This bug is still a problem in Oneric.The version of Gnome Power Manager is completely different (3.1.3). Is there a fix possible for this? The bug is exactly the same. Two brightness levels when only one is needed.

I have better with my Thinkpad X100e : 4 levels of brightness per keypress !
This reduces from 16 to 5, which is quite annoying.

I didn’t have the problem up to natty…

Here's a thread in the linux-thinkpad mailing list about this issue (it affects XFCE as well as GNOME):
http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2012-February/050576.html

The thinkpad-acpi kernel module maintainer says:
> This typically means broken crap that reacts to brightness *change* events as if they were keypresses.

Upstream bugs that seem related to this:

- ThinkPad X60s and X300, improper brightness adjustment using function keys Fn+{Home,End}, twice long step
  https://bugzilla.gnome.org/show_bug.cgi?id=579224

- Need a setting to tell g-p-m that brightness changes are handled in hardware when using xrandr
  https://bugzilla.gnome.org/show_bug.cgi?id=601410

Happy Birthday Bug 527157! Gee, has it been two years already? It feels like just yesterday I was wondering why I couldn't get more than 5-7 brightness levels! Three Ubuntu releases later, and I've had to find two different solutions to the same problem. Maybe it's a g-p-m bug! Maybe it's a kernel bug! I've heard claims that the kernel is reporting xrandr brightness change failures even though the change actually succeeded. Who knows?!

For those of you who are tired of patching Gnome-Power-Manager, or trying unsuccesfully to patch the new version in the Gnome 3 branches, I may have found a solution less likely to get clobbered by system updates. The fix worked for this bug on my next laptop, an Alienware M11x r2. I've since moved on to OS X on a Macbook Air, but my hope is that it will help other poor souls just trying to get a comfortable brightness level.

Add the following options to your kernel boot parameters:
acpi_backlight=vendor

I can't guarantee this will work on your laptop. It gave me 15 brightness levels on the Alienware (instead of the default 9 in windows or 4.5 in unmodified ubuntu). An unpleasant side effect was that the screen would go to sleep and not wake up, even though the system was still accessible via ssh. No amount of hand waving or xrandr prodding managed to fix this, or revive the comatose screen. I "solved" this by setting my display to never turn off unless I closed the screen.

Despite my snark, I am appreciative of the work put in by people to fix this bug. I would like to thank everyone who helped out on this bug with your comments and testing.

I would like to give special thanks to Darwin Bautista and Konstantin Lavrov for working so diligently on the original patch. Your work let me use my machine with the proper brightness levels right up until the 3.x tree of GPM. Without you guys (and especially Darwin's ppa), I would've never had proper screen brightness, and would've never known where to look when resolving this issue in the next version of GPM.

From the bottom of my heart, thank you all.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.3 kernel[1] (Not a kernel in the daily directory). Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag(Only that one tag, please leave the other tags). This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.3-rc7-precise/

This patch is for GNOME 3.2 that permanently disables gnome-settings-deamon's ability to step-up and step-down the backlight. For those who still can't get the correct brightness steps, this is a workaround. It works perfectly on my Lenovo Thinkpad x220.

I'm not usually a code hacker or patcher, so feel free to make corrections if it isn't formatted correctly.

This was tested on the current Debian Wheezy GNOME 3.2 environment, but I thought that you Ubuntu folks could benefit from it as well.

Please note that the above patch is ONLY for those encountering this problem and should definitely be used ONLY on an individual basis. It will break backlight control for everyone else using GNOME 3.2.

Oh yeah! #24 is really dirty one!

But it gave me a clue, how this bug should be fixed:
Patching StepUp/StepDown handlers is very bad practice, because these methods may be called by some other applications. We need to prevent calls to these methods depending on some parameter.

The problem itself: bios changes brightness on keypress and reports acpi keypress event, instead of just reporting event (this might be fixable in DSDT), then some process handles this event and issues dbus calls to org.gnome.SettingsDaemon.Power.Screen.StepUp/StepDown methods. Then g-p-m changes brightness too; g-p-m has no ways to determine, whether it should change brightness when handling StepUp/StepDown dbus calls, or not. Neither 'some process' do.

The solution, how I see it: find code, which handles acpi keypresses (that's not g-p-m, g-s-d may be?) and add user-changeable option there to disable acpi brightness keypresses handle (e.g. gconf parameter).

I would change status on g-p-m to 'Invalid' and assign bug to other package.

Dmitriy: Yes it is a dirty hack :) I don't know of any other applications that would increment the backlight up and down, and GNOME's ability to set the brightness to a specific percentage (without going through steps inbetween) *should* still be functional with it...although even the unpatched gnome-settings-daemon in Debian Wheezy doesn't know how to handle simple things like "dim on battery power" correctly yet so I can't test that conclusively right now.

I think that your solution might require a patch to the kernel itself. At least in my case, backlight keypresses are handled by the thinkpad-acpi module, and I'm guessing non-thinkpad problem laptops use the kernel's built-in acpi functionality. I could be wrong though.

Either way, this bug now belongs to gnome-settings-daemon, since all power-handling functionality has moved over there. This bug entry should probably be marked 'Invalid' as you said, and a new bug should be opened.

James: no, there is no need to touch kernel. You should have noticed, that brightness control works as expected, before you login (during boot or even on login screen).

Problem is in user-level process running during user session. We have to find that process, than fix will be pretty simple.

See plugins/media-keys/gsd-media-keys-manager.c:1528, function do_screen_brightness_action_real(): looks like it is correct place for patch.
Later I will think on good solution.

Oh, that was about g-s-d source!

Fix itself is pretty simple, but all that g/dconf mess confuses me.
Need to understand, how to create new key in dconf...

Here is the patch. Please review it.

My patch is similar to one in comment #15.
Differences are:
- it uses gsettings api (commonly used by g-s-d now)
- it doesn't break StepUp/StepDown dbus methods
- it's smaller

Thanks. I'll test this out as soon as I find time to.

Patch didn't work for me. What gnome-settings-daemon version did you work on? (3.2.2 here)

$ patch -p1 < ../52_brightness_in_hardware.patch
patching file data/org.gnome.settings-daemon.plugins.power.gschema.xml.in.in
patching file plugins/media-keys/gsd-media-keys-manager.c
Hunk #1 succeeded at 65 (offset -2 lines).
Hunk #2 FAILED at 142.
Hunk #3 FAILED at 1535.
Hunk #4 succeeded at 1719 (offset -219 lines).
Hunk #5 succeeded at 1750 (offset -217 lines).
2 out of 5 hunks FAILED -- saving rejects to file plugins/media-keys/gsd-media-keys-manager.c.rej

Hmm... really strange.
I made patch ubuntu 11.10, g-s-d 3.2.2-0ubuntu2.1. May be you upgraded to 12.04 already?
Actually, I should make patch for 12.04, as it's latest stable now. Will do this bit later.

Sorry, I didn't write instruction:
- put the file into debian/patches/ dir
- add line 52_brightness_in_hardware.patch to 'series' file in that dir (not sure if this step is required)
- build package as usual

This patch should be applied last, after all ubuntu/debian patches. That's why it fails. Have you install package source using 'apt-get source gnome-settings-daemon' or just unpacked source tarball?

I'm using Debian Wheezy, but I tried it on Ubuntu's 3.2.2 source package and it failed with the same error.

I tried unpacking the package and using patch -p1 < 52_brightness_in_hardware.patch, and that didn't work.
I tried putting it in the debian/patches directory and using dpkg-buildpackage, but it failed with the same error.

What steps are you using to get this to work? Where did you get the source for gnome-settings-daemon? (I used packages.debian.net and packages.ubuntu.org)

In order for this patch to apply properly, it should be applied last, after all ubuntu patches. In you case you don't have any of them applied.

If you got package from packages.ubuntu.com, there are 2 source files: one http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-settings-daemon/gnome-settings-daemon_3.2.0.orig.tar.bz2 -- source itself, second -- http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-settings-daemon/gnome-settings-daemon_3.2.0-0ubuntu5.debian.tar.gz -- all patches.

I see that I need to make patch independent of theese ubuntu changes.

Patch 16_use_synchronous_notifications.patch -- is the one, that my patch heavily depends on.
Also, as far, as I understand, it's incompatible with debian.

To make patch for debian, I need to understand, where to get correct params for update_screen_cb(), to call it from do_screen_brightness_action().

You can try to help with this, see plugins/media-keys/gsd-media-keys-manager.c.rej -- second piece from there must be inside do_screen_brightness_action().

gsd-media-keys-manager.c.rej :

--- plugins/media-keys/gsd-media-keys-manager.c 2012-04-14 11:13:20.000000000 +0400
+++ plugins/media-keys/gsd-media-keys-manager.c 2012-04-14 11:20:07.772836587 +0400
@@ -142,6 +144,8 @@
         NotifyNotification *volume_notification;
         NotifyNotification *brightness_notification;
         NotifyNotification *kb_backlight_notification;
+
+ gboolean brightness_in_hardware;
 };

 static void gsd_media_keys_manager_class_init (GsdMediaKeysManagerClass *klass);
@@ -1535,6 +1539,11 @@
         GsdMediaKeysManager *manager = data->manager;
         GError *error = NULL;

+ if(manager->priv->brightness_in_hardware) {
+ update_screen_cb(source_object, res, user_data);
+ return;
+ }
+
         GVariant *old_percentage = g_dbus_proxy_call_finish (G_DBUS_PROXY (source_object),
                                                              res, &error);
         if (old_percentage == NULL) {

Just popped in to check on this bug. I don't have the hardware I filed this against anymore, and I'm still happy on OS X and my Macbook Air, but I feel a responsibility to the users still stuck with this problem.

Why are you guys marking the g-p-m bug invalid? The switch to g-s-d doesn't invalidate the original bug, which was logged against a still-supported LTS version. 10.04 still uses g-p-m. By all means, open a new bug for the new g-s-d incarnation of the bug, but please don't hose the LTS users...

> Why are you guys marking the g-p-m bug invalid?
Because see previous comments.
g-s-d handles media keys. This bug is appeared, because we have a case, when g-s-d should handle brightness keys differently.

Hello,

I have this exact same issue on 12.04 32bits on Dell VOSTRO 3450.
I am a bit confused of all the posts above... is there a patch for 12.04 at the end?

Short instruction on how to apply the patch will be highly appreciated (or a link to a wiki or something about applying patches in general, if there is such thing at all). Sorry for the incompetence, I'm not that deep into Linux, but I would like to learn.

Thank you,
 - Christo

This bug seems to have gone stale (again?), but I'd like to report that it affects me with:

* 13.10, fully updated
* Thinkpad T440p (FHD panel, if that matters)

Using the slider in Settings > Brightness & Lock, it seems that there is ~15 brightness levels (it's hard to get an exact count, since each level is pretty subtle, and the mechanics of manipulating the slider aren't the most precise). However, using the screen brightness "media" keys (doubling as F5 and F6), I can distinguish between only 4 brightness levels. Each press of these keys pops up the brightness overlay/notification in the upper-right, and the bar there changes properly, but the actual screen brightness changes in a step function, rather than linearly.

This bug needs more attention.

There are still big amount of laptops where the brightness is incorrectly adjusted by 2 or 3 steps per one brightness key press.

Some affected machines:

* Dell E4300
* Asus F200CA
* Fujitsu E751

Seems odd to me that this bug is a low priority. The results are pretty poor UX.

There are 3 interesting solutions here.
http://askubuntu.com/questions/208331/brightness-control-increments-brightness-by-4-instead-of-1

Fix 1 is a partial fix that worked for me right away. Still looking into the others.

The bug is still present in Ubuntu 15.04.

I have had success with acpi_backlight=native.

The superfluous listeners for backlight really should be muted...