Screen brightness resets to default (maximum) on idle with AC plugged in

Same problem here on amd64 and gutsy

Marking as confirmed. Can a dev please look into this? This is a regression from Feisty, and is quite annoying...

This is on a MacBook Core Duo (first generation), just so the devs know. It does NOT happen if I disable screen dimming altogether in gconf.

Here is the trace from gnome-power-manager when the brightness changes to maximum on idle...

gpm_screensaver_powersave_idle_changed] gpm-screensaver.c:102 (23:12:51): emitting powersave-idle-changed : (1)
[powersave_idle_changed_cb] gpm-idle.c:335 (23:12:51): Received GS powesave idle changed: 1
[gpm_idle_set_mode] gpm-idle.c:98 (23:12:51): Doing a state transition: 1
[gpm_backlight_notify_system_idle_changed] gpm-backlight.c:581 (23:12:51): we were active for 73.247393s
[gpm_backlight_notify_system_idle_changed] gpm-backlight.c:584 (23:12:51): changing powersave idle status to 1
[gpm_backlight_brightness_evaluate_and_set] gpm-backlight.c:374 (23:12:51): 1. main brightness 1.000000
[gpm_backlight_brightness_evaluate_and_set] gpm-backlight.c:387 (23:12:51): 2. battery scale 1.000000, brightness 1.000000
[gpm_backlight_brightness_evaluate_and_set] gpm-backlight.c:402 (23:12:51): 3. idle scale 1.000000, brightness 1.000000
[gpm_backlight_brightness_evaluate_and_set] gpm-backlight.c:422 (23:12:51): 4. ambient scale 1.000000, brightness 1.000000
[gpm_backlight_brightness_evaluate_and_set] gpm-backlight.c:440 (23:12:51): emitting brightness-changed : 100
[gpm_brightness_lcd_dim_hw] gpm-brightness-lcd.c:267 (23:12:51): new_level_hw=117
[gpm_brightness_lcd_dim_hw_step] gpm-brightness-lcd.c:198 (23:12:51): new_level_hw=117, last_set_hw=17
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 17 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 22 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 27 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 32 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 37 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 42 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 47 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 52 of 117

(gnome-power-manager:16993): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed
[gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (23:12:51): Setting 57 of 117

(gnome-power-manager:169...

Milestoning for RC since it's a regression.

The issue here is:

*g-p-m changes the brightness to the "dim" brightness on idle with dim enabled
*g-p-m changes brightness value to full brightness on leaving idle with dim enabled
*g-p-m changes brightness value to full brightness on idle with dim disabled

This all takes place in "gpm-backlight.c" in the source, in the "gpm_backlight_brightness_evaluate_and_set" function.

Instead:

*g-p-m should change the brightness to the "dim" brightness on idle with dim enabled *if not already set to a lesser value
*g-p-m should return the brightness to the original (pre-dim) brightness on leaving idle
*g-p-m should not touch the brightness on idle/leaving idle with dim disabled

I'm looking at the code, but I can't guarantee a patch since I'm a bit C-impared :)

Here is the patch I came up with. Basically, when the "idle" callback is called, this will stop it from changing the brightness if idle dimming is disabled. Hope this is suitable - I know one could suppress the idle callback from being called, but it seems that it is used for other things (gscreensaver, etc). If not, then that would be the preferred solution.

Your patch will only fix the bug when idle dimming is disabled. Ideally, gnome-power-manager should be notified whenever the fn keys are used to change the brightness, so it can update its configuration. If you open the power management preferences dialog, you can see that changes from the fn keys aren't synchronized.

Well, there isn't really a problem if idle dimming is enabled - in that case
it dims properly to the "idle" brightness setting. That is, unless
brightness is already set to a lower setting, in which case the brightness
increases (but that's another bug).

In any case, if some kind of patch can't be integrated, the whole
auto-brightness change logic should be disabled in Gutsy - it's so
incredibly buggy as to cause more problems than do good in its existing
form.

Tim

On 10/4/07, Simon Ruggier <email address hidden> wrote:
>
> Your patch will only fix the bug when idle dimming is disabled.
> Ideally, gnome-power-manager should be notified whenever the fn keys are
> used to change the brightness, so it can update its configuration. If
> you open the power management preferences dialog, you can see that
> changes from the fn keys aren't synchronized.
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of the bug.
>

It also seems like this bug is a duplicate of Bug #35223.

The problem with idle dimming enabled would be when the user stops being idle. The brightness would be "reset" to whatever g-p-m thinks the brightness is (100% by default), instead of what it was actually set to using the fn keys.

Yes - fixing that would require a "previous brightness" variable in the
code. It would basically be checked, and then the brightness code would
take it into account when exiting idle.

I figure the best way to fix all these brightness problems would be to:

1. Do not use "idle" events when idle_on_ac is disabled on AC (or
idle_on_batt on battery).
2. Store a "previous brightness" in the backlight struct and revert to this
when we update the brightness to return from a dimmed state.
3. Check if brightness is less than idle brightness before dimming. If it
is, leave it alone.

If these three things are implemented, the brightness logic should be
working as expected. My other patches fix the problems, but this seems like
a more ideal way to do it.

I may take a look, but I can't guarantee anything. I hope the devs get a
patch committeed 7.10 final - this is a big regression for laptop users,
and something that would probably be noticed by most users/reviewers on
laptops.

On 10/4/07, Simon Ruggier <email address hidden> wrote:
>
> The problem with idle dimming enabled would be when the user stops being
> idle. The brightness would be "reset" to whatever g-p-m thinks the
> brightness is (100% by default), instead of what it was actually set to
> using the fn keys.
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Tim's patch is certainly a big improvement if you set idle dimming to disabled. No more annoying dimming when you don't want it. Except when you open the gnome-power-manager preferences. Then it does seem to dim the display for some reason.

Also, this bug appears to be a duplicate of bug #133057. Not sure about bug #35223.

I very much doubt upstream will have anything before Gutsy release. Could we integrate my patch or possibly a similar one with some minor changes? It wouldn't be very good IMO to have the brightness randomly increasing in Gutsy final as it does now...

Is anyone seeing this on non-MacBook hardware? I ask because a few of the devs are not seeing this issue, and I would like to see it fixed in Gutsy. Also, does anyone have a patch from upstream or another distribution?

I'm having this issue on an Acer 5920.

On 10/10/07, Tim Hull <email address hidden> wrote:
> Is anyone seeing this on non-MacBook hardware? I ask because a few of
> the devs are not seeing this issue, and I would like to see it fixed in
> Gutsy. Also, does anyone have a patch from upstream or another
> distribution?

I see this on an Dell Vostro 1400, which is the same hardware as the
Inspiron 1420 laptops that Dell is shipping Ubuntu on. It would be
somewhat embarrassing not to fix this.

Could everybody who is seeing this bug please e-mail the Ubuntu Technical Board at <email address hidden> and give detailed information about your hardware/how this issue effects you? I'm having trouble getting any devs to look at this - they think it is MacBook-specific, and are thus considering it an "unsupported hardware regression" of a lower-priority. If you are also seeing brightness increased on idle with idle brightness dimming *on* (i.e. when you reduce the brightness to minimum), please mention bug #63543 as well. I reiterate what the previous poster said - this would be quite an embarrassing bug to make it into the final release.

Why not send a link to this bug?

I have - they haven't seemed to really notice it...

On 10/11/07, Simon Ruggier <email address hidden> wrote:
>
> Why not send a link to this bug?
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Hi

My laptop is Compaq V3527, Core 2 Duo 7300, Intel X3100 and I have exactly the problem described above. The screen brightness goes up to 100% from 80% when dimming is set enabled. After reading this bug, I disabled the dimming and the problem has gone.

Note that, I have only this annoying problem after upgrading to Gutsy AMD64 from Egdy AMD64.

The issue is new on Gutsy, so that would be expected.
If you can, try the patch I posted above, However, this would require
compiling gnome-power-manager from source...

On 10/18/07, Vaioinman <email address hidden> wrote:
>
> Hi
>
> My laptop is Compaq V3527, Core 2 Duo 7300, Intel X3100 and I have
> exactly the problem described above. The screen brightness goes up to
> 100% from 80% when dimming is set enabled. After reading this bug, I
> disabled the dimming and the problem has gone.
>
> Note that, I have only this annoying problem after upgrading to Gutsy
> AMD64 from Egdy AMD64.
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of the bug.
>

In my laptop (MSI EX600 with Ubuntu Gutsy final) there is a similar behaviour - the brightness is adjusted automatically without an apparent reason - the screen can get dim or bright more or less randomly (actually it happened a few times while writing this message). Removing "Dim display when idle" option has no effect.
When adjusting the brightness via keyboard, pressing a key combination (Fn+Increase of Decrease) can cause following actions: it can be no response, it can increase the brightness one step, or decrease it. The general direction of the adjustment is correct - if you press the relevant keys long enough, you'll get the screen bright or dim.
In Feisty it worked more or less correctly, so it is a real regression.

Yuri, it sounds like your bug is a different bug, I haven't seen that behaviour.

The same problem with an Asus F3JC laptop (C2D T5500, Geforce Go 7300) on Ubuntu Gutsy Gibbon 64 bits version.

I have an update: it seems that the problem with random dims shows up when the gnome-power-manager decides (without apparent reason) that the computer runs on battery, while it runs on AC power. The applet shows that the computer runs on battery, and some random time until charged (???)
There is no problem when the power manager recognizes the power source correctly. When gnome-power-manager process is terminated, the brightness is also constant.
Simon: it is possible, despite the fact that the behaviour seems related. Would you suggest filing another bug?

On 10/22/07, Yuri Glushkov <email address hidden> wrote:
> Simon: it is possible, despite the fact that the behaviour seems related. Would you suggest filing another bug?

Yes, because this bug would be fixed if g-p-m was notified whenever
the user changes the brightness with the fn keys, but it sounds like
your bug would still be there.

Same happens to me with a fresh install of gutsy on a Dell inspiron 9400 / E1705. When running on AC power if I change my monitor brightness to some value near 50%, after a minute it automatically turns to 100% without "Dim display when idle" checked.

Same problem with Dell inspiron 1420n.
Very annoying bug.

For those of you who are annoyed, there's a panel applet to control
the brightness that updates the setting correctly, unlike the Fn key
function. It's the next most convenient way to control the
brightness, with the other option being to change it in the
gnome-power-manager preferences dialog.

I just started having this problem on my T42p. I can confirm that:
1. If I change the brightness using the Fn keys, after a while, the brightness level is reset.
2. If I set the brightness using the Fn keys and open gnome-power-manager, it resets the brightness to what was previously set there.
2. Using the brightness applet instead of the Fn keys to change brightness resolves this problem.

Another interesting aspect to note is that the brightness applet is capable of "reading-in" the current brightness level. For instance, if I change the brightness using the Fn keys and click on the brightness applet, the proper brightness level is reflected there. Thereafter, if I open the gnome-power-manager, it will reflect this value.

Hence, another workaround is to use the Fn keys and immediately click on the brightness applet once. This will essentially sync the current brightness value with gnome-power-manager.

Its been more than a month since I installed Gutsy. I have been playing around with my system (install/uninstall tpb among others). Also, I just installed kde4 . I am wondering if some of these could have been the source of the problem.

- Naveen

Perhaps this bug is related? I have trouble with g-p-m, brightness applet, and xbacklight on my HP notebook.
https://bugs.launchpad.net/ubuntu/+bug/178818

This is very annoying bug. I used to adjust brightness for videos (up) and for text (down). Now, several minutes after any adjustment, display just returns to power setting. Something is seriously broken in gnome brightness applet.

Things I noticed:

Brightness can be adjusted using Fn keys, applet pops up at the time.

After several minutes, brightness returns to the power settings default.

Confirming the issue, I'll make sure it's fixed for hardy

Same problem there with a Dell Latitude D630

With AC plugged the brightness resets to maximum value very often

My laptop is running hardy alpha 4 with latests updates

Thanks ;)

This still happens on Hardy alpha 5. I posted a potential fix in this bug - could devs look at this/potentially tidy up what I did? I'm kind of "out of the loop" for Hardy (first discovered this in Gutsy testing cycle), but I do plan to be back for the Intrepid Ibex test cycle (hopefully it will be fixed then).

This bug also happens in gutsy on the Dell M1330 (not dell-buntu) -- and with the LED backlight, going to 100% brightness is an extreme jump.

Could this be nominated for beta? It is still around, and it would be pretty bad IMO to have this in the final product - particularly for an LTS. I had a posted fix that works somewhat (towards the beginning of this bug) - could the devs responsible for g-p-m take a look at this and integrate it, improving if possible?

happens on my Thinkpad x60s ... very frustrating to say the least

Problem is still here with Hardy alpha 6. It appears every five minutes only when I don't use the computer (mouse or keyboard)

It would really be a shame if this bug made it into Hardy, considering Hardy will be and LTS. LTS releases are supposed to solve problems just like this one.

I have put a couple of fixes intended to solve this bug in my PPA. Could you please try the GNOME Power Manager there to see if it fixes this issue.

http://launchpad.net/~ted-gould/+archive/

Thanks.

Ted, I tried it and now the brightness is dropped when the system is left idle, but when I resume work it drops to minimum :)

Also, AC plugged in the settings have no meaning, ie. it doesn't set the brightness to the level that's on the capplet, but maybe 30% more than what it used to be on battery.

Ted, unfortunately It didn't work on my notebook. :(
It still increases and decreases automatically and continuously..

How can I help you more to solve this problem?
I can send infos, logs, etc. that you will need.

I added your gusty repos
deb http://ppa.launchpad.net/ted-gould/ubuntu gutsy main
deb-src http://ppa.launchpad.net/ted-gould/ubuntu gutsy main

I updated the gnome-power-manager and other 2 packages.

2008/3/12, Timo Aaltonen <email address hidden>:
> Ted, I tried it and now the brightness is dropped when the system is
> left idle, but when I resume work it drops to minimum :)
>
> Also, AC plugged in the settings have no meaning, ie. it doesn't set the
> brightness to the level that's on the capplet, but maybe 30% more than
> what it used to be on battery.
>
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Ali Deniz EREN
<email address hidden>

the latest fix 2.22.0-0ubuntu1~ppa4
seems to have fixed this problem on my lenovo T60p

thanks!

I see some feedback that this change doesn't fix the problem for all users. Should the bug status be rolled back from 'fix committed', or is there reason to think that there's more than one bug at play here?

Ted: Your patch is working fine on my Dell Latitude D630, I hope your patch will be included into the final Hardy.
I used gnome-power-manager_2.22.0-0ubuntu1_i386.deb (3.1 MiB)

Thanks! :)

@Timo

Yes, the idea now is that it adjusts by a value set in the GConf keys not to a fixed value. So it is a -30% on unplug and +30% on plug in. This also is intended to fix some problems users have with external programs setting the brightness outside of GPM (sadly).

@ali_deren

Unfortunately I have only built the patch into the Hardy repository. I can look at building the Gutsy one also, but it's unlikely to get included into the main repository for gutsy. Is there any chance that you could test Hardy on your machine?

@Steve

No, not yet.

Just installed hardy on my acer 5920 laptop. This issue seems to be fixed there for me. The screen 'flickers' when i adjust the brightness, but the levels are set correctly, and they stay that way. I'm happy! :)

Err spoke too soon :-( Brightness is set in a nicer way than feisty, but if i turn down brightness while on AC, after a while it automagically jumps backup :-(

s/feisty/gutsy/

On 3/15/08, Jochem Kossen <email address hidden> wrote:
> Err spoke too soon :-( Brightness is set in a nicer way than feisty, but
> if i turn down brightness while on AC, after a while it automagically
> jumps backup :-(

The root of this issue (if I'm not mistaken) is that when the hotkeys
are used to adjust the brightness, the adjustment doesn't get saved to
gconf. If that gets fixed, this problem will go away.

I don't know anything about gconf, but I am certain that this problem only happens to me when I use hotkeys. I discussed this matter in the following post, under the section "Steps to repeat issue 1":
https://bugs.launchpad.net/ubuntu/+bug/155485/comments/1

Hmm yes, with the brightness applet setting the brightness now works correctly in hardy. Just the hotkeys are still screwed up.

@Jochem - As far as I know, the applet has never been a problem. At least I have never experienced any problems with the brightness applet. The problem for me has always been, and continues to be, the hotkeys (I am not running any of the patches, I'm still on Gutsy).

The latest g-p-m fixed this for me - the buttons work correctly and the brightness level does not get reset after some time.

Hmm yes, with g-p-m 2.22.0-0ubuntu1 all problems are gone here as well. Nice work!

Now I have a problem...

I have an Asus Z96J and now the slider that controls brightness doesn't work and also, the display never enters DPMS off with timeout. The backlight always stays on...

The keyboard controls work, but gnome power-manager is completely wrong in what related to the backlight...

I'm going to go ahead and marked this fixed released.

@Luís Silva

I think the DPMS issues is a different issue. And the slider in the dialog is now deprecated. I've removed it in the latest package in my PPA. If you want to have a slider to adjust the brightness please use the brightness applet.

Thanks everyone for your help. Ted.

I can also confirm the DPMS regression caused by this patch.

See bug 207553 for the introduced DPMS issue.

Hardy fixed some of these issues, but introduced more at the same time. I haven't done extensive testing, but I can provide you with my observations.

In Gutsy, I had the following problem. If I set the brightness with the [Fn + Up] or [Fn + Down] keystroke, the brightness would at some point revert to the value set in the Brightness Applet. In Hardy, it seems that the opposite happens. If I set the brightness with the Brightness Applet, it will at some point revert to the value set by the [Fn + Up] or [Fn + Down] keystroke. Worse, the brightness level always reverts to some (seemingly random) value after a reboot.

I opened up a new bug to discuss the new problems (feel free to mark it a duplicate if you think that would be appropriate):
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/223954

I have the same issue in Hardy Heron x86_64 but:
- screen brightness resets to default (medium value)
- the issue happens even with no AC power but with battery plugged in

I've 8.04.1 AMD64 installed and this has not been fixed yet.

Should't it be marked as "Confirmed"?

@clovepower, I think you are right. It should be marked confirmed for Hardy and "not fix released" as it's not fixed yet. The bug is very annoying.

The bug is still present in Hardy

I'm experiencing this again on Jaunty, so this is a regression (if this was ever fixed).

$ apt-cache show gnome-power-manager
Package: gnome-power-manager
Priority: optional
Section: gnome
Installed-Size: 12524
Maintainer: Ted Gould <email address hidden>
Original-Maintainer: Debian GNOME Maintainers <email address hidden>
Architecture: amd64
Version: 2.24.0-0ubuntu12

Ted can you bump the version in your PPA to match jaunty, so I can test it?

The bug appeared again after upgraiding kernel version to 2.6.27-11-generic on Interpid.
Everything worked fine in 2.6.27-10
My laptop is Asus X50N

I have the same problem on DELL Studio 15 with Interpid and 2.6.27-10-generic from proposed (the previous kernel handled the brightness keys wrongly)

I have the same issues on an Asus eeepc 901, running Ubuntu Netbook Remix 9.04, 2.6.28-11-generic. Running on battery power, when I dim my display beyond the "idle" dimness and let it sit until my computer is finally considered "idle," the display brightens to the "idle" dimness! Lastly, when I move my mouse thus bringing my computer out of the "idle" state, the display goes to maximum brightness. I can't believe this bug has been plaguing us since 7.10. If someone needs to see my settings, tell me what to run and I'll post the results.

:~$ gconftool -a /apps/gnome-power-manager/backlight
 dpms_method_battery = default
 idle_dim_time = 30
 battery_reduce = true
 brightness_ac = 100
 idle_brightness = 30
 enable = true
 idle_dim_ac = false
 brightness_battery = 70
 dpms_method_ac = default
 idle_dim_battery = true
 brightness_dim_battery = 50

Same problem, also on eee w/ 9.04, 8.10 worked fine, though..

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

Scott, I apologize for taking so long– work has been taking all my time! Finally, I was able to test Karmic, and I can tell you that the bug IS NOT present in Karmic. It has been fixed (at least for me).

Again, I am running an Asus eeepc 901. I ran the Karmic netbook remix off of a flash drive, and ran the following two tests:

1) On AC:

     a) Put screen at full brightness. After idle time expired (which I set to 1 minute), the screen dimmed. So far so good.
     b) Put screen at minimum brightness (almost– but not quite– off). After idle time expired, the screen simply faded off. How classy! Upon moving my mouse, the screen woke back up TO THE SAME brightness I set it to (minimum brightness). Quite nice.
     c) Put screen a few notches above minimum brightness. After idle time expired, the screen again simply faded off. Again, upon moving my mouse, the screen woke back up to the same few-notches-above-minimum brightness.

2) On battery power

     This does not need to be enumerated, as the results were identical to experiment (1).

          The conclusion drawn from this is:
               o If the brightness is ABOVE idle brightness, then when idle time expires the screen is dimmed to the idle brightness.
               o If the brightness is BELOW idle brightness, then when idle time expires the screen is faded off.

     I really like this solution! Scott, is there any way to have this backported?

Great to hear! Thanks for testing. Unfortunately, we can't bring this into previous versions of Ubuntu. The Stable Release Update [1] and backporting policy [2] generally only allows security bugs or bugs that could cause severe loss of data. Thanks again for helping make Ubuntu better!

[1] https://wiki.ubuntu.com/StableReleaseUpdates
[2] https://help.ubuntu.com/community/UbuntuBackports

That's alright Scott, I figured that would be the case– policies are in place for a reason. I'm just glad to know that it IS fixed! If the changes aren't too huge, I'd be willing to test a patch file if you've got one, I'm sure people subscribed to this would appreciate it. What do you think?

There has been a pretty significant change in how GPM and power
management in general works between Jaunty and Karmic, a patch won't
easily work (dependencies have changed significantly, HAL has been
deprecated in favor of devicekit-power). Fixing bugs in power
management has been a moving target over the past couple months and is
only now beginning to stabilize with all the improvements. We're glad
that it will be working in Karmic.

On Wed, Jul 22, 2009 at 1:23 PM, Kyle
Fazzari<email address hidden> wrote:
> That's alright Scott, I figured that would be the case– policies are in
> place for a reason. I'm just glad to know that it IS fixed! If the
> changes aren't too huge, I'd be willing to test a patch file if you've
> got one, I'm sure people subscribed to this would appreciate it. What do
> you think?
>
> --
> Screen brightness resets to default (maximum) on idle with AC plugged in
> https://bugs.launchpad.net/bugs/137598
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Gnome Powermanager: Fix Released
> Status in “gnome-power-manager” package in Ubuntu: Fix Released
> Status in gnome-power-manager in Ubuntu Hardy: Fix Released
>
> Bug description:
> Binary package hint: gnome-power-manager
>
> In Gutsy, if I adjust my screen brightness (i.e. to lower than the default, which is the maximum) and let the system sit idle (no mouse/keyboard movement) for a while, the screen brightness automatically adjusts to maximum on idle.  This is with the AC plugged in.  It seems like the brightness should NOT be changed automatically with the AC plugged in - and if it does, it should only be to dim it on idle and return to the previous level when there is system activity.
>

Whoa, HAL's gone? I need to keep up-to-date! I am glad to hear it's stabilizing, though :) . Meh, I only have a couple of months to wait for Karmic, right? Keep up the good work.

correct state for the hardy task is 'wontfix', not 'fix released'.

Just upgraded to the Karmic Beta - and the whole screen brightness alternates (low/high) every 1/2 second until the power applet kicks in and is displayed. Once the Gnome power manager 2.28.0 applet starts - the display is fine, and it stablises. This wasn't the case in 9.1 Jaunty.
Is this related?

Can anyone explain why this bug still exist in Karmic? Is anyone going to offer a way to fix this? Thanks.

I have this bug, running Karmic (ubuntu 9.10)

When I run on AC power, I have the screen brightness set, using power manager, at ~80%. I'd like it to stay there.
After I let the computer idle for about 38 seconds, the brightness Increases to 100% and stays there unless I "bother" the computer (for example, touch the mouse), at which point brightness reverts back to the correct value of 80%

I don't use the keyboard to change brightness.

Still correct for Lucid with gnome-power-manager 2.30.0-0ubuntu1

I'm using Ubuntu 11.04 on Dell Inspiron 1464 which has onboard graphics. I too had the same problem and I wrote a script to overcome this issue. Thought it would good to share it with the community.

http://blog.ishans.info/2011/09/25/set-brightness-automatically-at-the-startup-in-linux/