LCD backlight turns off when between discrete levels, both from hotkeys and from dim-on-idle.

[Dana Goyette]

Binary package hint: gnome-power-manager

When gnome-power-manager dims the screen when on battery or when idle, the backlight turns entirely off.
In addition, during the fade the screen blinks: 100%, OFF, 75%, OFF, 50%, OFF.

        cat /proc/acpi/video/VGA/LCD/brightness:
        levels: 100 37 12 25 37 50 62 75 87 100
        current: 100

The screen is turning off whenever something requests a brightness level between the available discrete levels; thus the default dim-when-inactive brightness of 30 turns the backlight off. For a while, I thought my system was freezing at a black screen at login (battery) or idle (AC), until I remembered the brightness controls.

One factor in this is the new /sys/class/backlight/ interface for brightness control, common to all ACPI drivers:
This structure does not seem to provide the same, necessary information, such as available discrete brightness levels.

    /sys/class/backlight/acpi_video0/max_brightness: 100
    /sys/class/backlight/acpi_video0/actual_brightness: 62 <== changes when software or hotkeys are used.
    /sys/class/backlight/acpi_video0/brightness: 62 <== changes only when software requests a change.

HAL lists num_levels=101, while ideally it should be 8 or 9. Better yet, the kernel itself should provide the discrete levels, or rounding issues may appear.
Oddly. the brightness levels 12, 37, 62, and 75 work through echoing into /proc, but turn the backlight off if used in /sys, and thus HAL or g-p-m.
Echoing invalid values into /sys turns the backlight off, but echoing into the /proc structure returns 'invalid argument'.

Note: the data under /sys/class/backlight is not synchronized with /proc/acpi/video; for consistency, it should be.

(My DSDT also provides sys/class/backlight/acpi_video1/ and /proc/acpi/video/GFX0/DD0n/ for n from 1 to 5; LCD is 4. However, I would not expect the values there to be synchronized with acpi_video0 and VGA/LCD.)

Edit: As of the beginning of October 2003, changes to the kernel 'video' modue and HAL make me now have to hit my brightness keys 5 times before reaching the next brightness level; before, the brightness keys were still managed by the kernel.
In addition, upgrading HAL breaks brightness changes until the next boot.

[9johnny (s.j.)]

I can confirm, when using the laptops brightness control buttons, a small window pops up showing brightness level (great), but it blinks while I change the brightness, which is very irritating.

[Richard Hughes (richard-hughes)]

Lenovo laptop?

[Dana Goyette (danagoyette)]

Actually, my laptop is a Gateway M685 -- the non-consumer version of the NX860. Video card is NVIDIA GeForce Go 7600. Gateway actually does not have any proprietary ACPI modules -- they just have standard ACPI 3.0 code, likely in order to comply with Microsoft's desires for Vista.
http://www.google.com/search?q=acpi+in+windows+vista

I shall attach the output of acpidump (run with no parameters) from my system.

[Milosz Tanski (mtanski)]

There's some strange (similar things) happening with Gustry with a Lenovo laptop (Thinkpad Z61t). But strange things I mean:

 - I cannot use the laptops keys (anymore) to change my brightness settings. Whenever I use them, the screen flickers (brightness changes) and then it immediately changes back to what it was.
 - Sometimes when I'm working, I won't type for 5 seconds and it'll either flicker or dimm (randomly) even tho I have dim on idle disabled.
 - Using the gnome panel manager sliders when moving the sliders sometimes it'll flicker (switch to a random brightness level).

[Dana Goyette (danagoyette)]

Another note on my system: while my hotkeys still change brightness properly, Gnome somehow does not notice the change (reflected in the sysfs actual_brightness file), so the slider does not move. and I don't get any OSD. I do, however, get OSD on the (blinking) fades.

[Henrik Nilsen Omma (henrik)]

Hi, Could you please provide the information listed here: https://wiki.ubuntu.com/KernelTeamBugPolicies (esp. lspci -vvnn)? For the hotkey detection, please see: https://wiki.ubuntu.com/LaptopTestingTeam/HotkeyResearch

[Dana Goyette (danagoyette)]

Also, a note:
With the recent updates to the kernel 'video' module, gnome-power-manager, and the acpi-support scripts, my brightness keys no longer work at the kernel level. Instead, it is left up to the userspace, which renders the system unable to change brightness when in console-only mode. This also means that I have to hit the brightness keys 5 times to go between valid brightness levels; everything in the middle is entirely off.
I found a workaround for the new behavior: add 'options video no_automatic_changes=0' to some /etc/modprobe.d/ file -- this gives me the best of both worlds: I get the kernel-level brightness changing with the additional gnome OSD. *
However, either way the brightness applet isn't synced with the hotkey-changed brightness.
I also have the strange behavior when hitting 'down' while at the lowest brightness level: the LCD will alternate between low and off, with the OSD matching.

* That OSD is partly redundant on my system where I have a small, blue, BIOS-level OSD in the upper-left corner of the screen; the gnome brightness OSD is also rather ugly compared to the volume OSD.

[Dana Goyette (danagoyette)]

Oh great, now my workaround has been broken, too! Now I have to press the brightness keys FIVE times to go between adjacent brightness levels -- and some levels are still missing! I can't, for example, use the levels 12, 37, 62, or 87, despite those levels working when I directly manipulate the backlight sysfs entries.

This is the change that re-broke
hal (0.5.9.1-1ubuntu9) gutsy; urgency=low

  * debian/patches/64_read_brightness_not_actual_brightness.patch: Read
    the brightness from /sys/class/backlight/foo/brightness, not
    actual_brightness. It makes more sense to change based on the
    brightness that we wanted to set, not the brightness that we
    actually set.

Where's the logic in that? You should show the actual brightness, not what you asked for! Try applying the "act based on what we asked for, not what we got" logic to everyday situations, and see how well it works...

Having no_automatic_changes=0 now results in my screen BLINKING every time I press a brightness key, as the DSDT changes brightness to the right level, and then gnome-power-manager stupidly changes it back to an invalid value. Starting from 100%, it's like this:
100%, BLINK, BLINK, BLINK, BLINK, 75%, BLINK, BLINK, BLINK, BLINK, 50%, BLINK, BLINK, BLINK, BLINK, 25%, BLINK, BLINK, BLINK, BLINK, 0%.

[Matthew Garrett (mjg59)]

"no_automatic_changes=0" is expected to break things in the desktop environment, which is why it's not the default.

[Dana Goyette (danagoyette)]

Hmm, good point there. However, it still frustrates me that something was broken, and then I found a workaround, and then that workaround was broken without fixing the original issue, which is the lcd backlight turning off.
In addition, when gnome-power-manager isn't running, then only the automatic-changes plus actual-brightness method seems to allow brightness changing. Are there any plans for a console brightness control?

[reh4c (gene-hoffler)]

I can confirm this fn key brightness bug on my MSI 1221 laptop. Also, I've found that gnome power manager cannot determine correctly if I'm on battery or plugged in when I resume from hibernate. Are these issues all related to gnome PM?

[Mackenzie Morgan (maco.m)]

I also have this bug on my laptop. My bug is now marked as a duplicate.

[Dana Goyette (danagoyette)]

Oh, and now I still get the LCD turning off when idle, and what's worse is that now if I don't do my no_automatic_changes=0 workaround, my brightness keys don't work at all! What gives?
Also, I'm still curious why the multiples of 13 don't work through /sys/, but do work through /proc.

[Dana Goyette (danagoyette)]

Okay, it turns out that the total-breakage was merely HAL breaking on upgrade; this was fixed by rebooting.

[Matthew Rothman (xerxian)]

I am getting this bug on my Compaq Presario f500 laptop, whenever something changes the brightness, it turns the backlight off completely.

The backlight doesnt even turn back on with a reset, I have to pull the battery out.

This did not happen with fiesty.

[Dana Goyette (danagoyette)]

I managed to fix my LCD-turns-off issue by editing my DSDT; it turns out that whoever coded it foolishly used "if LEqual" instead of "if LLessEqual", which meant that any time an invalid brightness value was passed in, the LCD would turn off. I changed the conditions to make more sense, and now I no longer get the horrid blinking.
However, it would be nice if HAL and the kernel would pass correct (as in, not unlisted) brightness values to the ACPI controller. I still don't get why the values of 12, 37, 62, and 87 didn't work, though.

[Matthew Dutton (matthewrdutton)]

This also affects Gateway MP8708(from another post) and MP8709(mine).

The reason why values 12, 37, 62 and 87 aren't working is because of the way G-P-M increments/decrements brightness values. If HAL reports laptop_panel.num_levels < 20 then G-P-M will change the brightness level by 1 for each key press. Otherwise, it assumes that there are a lot of different levels and changes the brightness level by 5% each increment. See gpm_brightness_lcd_get_step in src/gpm-brightness-lcd.c for reference.

Since our laptops report laptop_panel.num_levels=101, G-P-M thinks that all levels 0-100 are valid and is trying to switch through them 5 at a time. The brightness values 12, 37, etc don't happen to be multiples of 5.

These seems like a mostly Gateway issue. It looks like we have a few options but I don't know which one fits best with the way HAL/G-P-M/ACPI works.

1.) Change whatever it is listening at /sys/class/backlight/XXX/brightness to use contiguous values (e.g. 0-8) [Seems like the best]
2.) Change HAL to use a custom laptop_panel.access_method that translates from 0-8 to 0,12,25,37,etc. [Seems like the easiest/most hackish]
3.) Change G-P-M to recognize the difference between 101 contiguous levels and the broken crap we have. [Seems like the hardest/least standard]

Option 1 seems like the best but I don't know what that involves or how to do it. Anyone have any references I could read regarding Option 1?

I working on some changes to the brightness get/set scripts to do this hack. It will also involve an .fdi file to change the num_levels, etc. I'll post it if I get something workable.

I'm not sure if the list of legal levels is provided by HAL and seems like a bad change just for some special boards. I think HAL expects num_levels to mean 0 to num_levels but I haven't read the spec yet.

If a dev could chime in with his opinion on this, I could get it done. I'm just not sure whats the best route for the long term. I'll try to get the short-term fix(#2) up tonight.

@DanaGoyette: /sys/.../brightness works fine when I force feed it 12, 37, etc. I haven't had that issue that you were describing.

[Matthew Dutton (matthewrdutton)]

BTW, as mentioned before, this broke from Feisty to Gutsy.

[Matthew Dutton (matthewrdutton)]

Here is a really ugly hack that lets HAL/G-P-M work with the odd brightness levels mentioned. There is a README inside the tarball. You have to hard code the legal brightness levels in an FDI file and add some sh script to some HAL scripts. It only works for devices that use the sysfs interface to set brightness but could easily be adapted.

The tarball is named with Gateway, etc but can work with any computer with this issue.

[Matthew Dutton (matthewrdutton)]

Slightly cleaned-up version of the above workaround.

I have had my X session reset a couple times while using this script if I press the brightness Fn keys really fast. But I don't know if that was happening before I was using this script or not. Besides that, it seems stable enough.

[Richard Hughes (richard-hughes)]

Please don't encourage people to work around the problem like that.

Please report the problem to upstream HAL or kernel bugzilla.

[Matthew Dutton (matthewrdutton)]

HAL LP Bug:
https://bugs.launchpad.net/ubuntu/+source/hal/+bug/162725

[Roman Nurik (roma086)]

I'm having the same problem on my Gateway CX210X... would really love to get this thing fixed. Anyone try a manual kernel build?

[Ludovico Cavedon (cavedon)]

I have the same problem on my laptop (hp dv2000): the backlight is set to 100% if the value written to /sys/class/backlight/acpi_video0/brightness is not among the values provided in /proc/acpi/video/VGA/LCD/brightness:
 levels: 100 60 20 28 36 44 52 60 68 76 84 92 100

I think that the kernel has to patched either to return error when setting invalid values, or to set the brightness to the closest valid value.

I am attaching a patch for the second option. It is working for me.

[James Black (linux4909)]

(THIS POST IS JUST ME STATING THAT I CHANGE THE SETTINGS IN GCONFIG. TO SKIP THE READ, VIEW THE ATTACHMENT ON THE SETTINGS I'VE USED TO GET MY LAPTOP TO STOP THE BLACK SCREEN)

Hello All,
I found a way to fix this. I know nothing about writing patches or anything. I've only been on Ubuntu for about 4 months. But i found a way to fix the brightness dimming to a black screen. First let me say, i have a Gatewat T2080, just got it and i'm within the 14 day return policy. I almost took it back cuz i thought it was my Ubuntu and if it wasn't going to run Linux, i dont want it. But then i read this bug report. Here's what i did and i think this will work for many of you.

hit Alt+F2, then type gconf-editor.
Apps>gnome-power-management>backlight
then change/adjust the settings as you please.
this worked for me. i no longer get the backlight going blank on me.
here are my settings. try them for you to see if they work for you:

brightness_ac -- 100
brightness_battery -- 100
dpms_method_ac -- default
dpms_method_battery -- default
enable -- checked
idle_brightness -- 90
the last 3 options are unchecked and idle time is 0.

***NOTE***
That while you are adjusting the times and brightness level, it MAY go black.
just use your fn + F8 to brighten the screen and keep setting the levels.
when you exit, it should not go dark anymore. i've done this and have yet to get the blank screen again.
if i am repeating something already said, i'm sorry. and i hope this works for all until this issue is fixed. if it is fixed, please
message me a patch or something.

p.s.i also unchecked all my lowpower settings.

[Matthew Carpenter (matt-eisgr)]

as posted in 138300
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/138300

Similar behavior on Kubuntu with guidance-power-manager on an HP Pavailion DV6000T.
Closing screen can cause the backlight to shut-off altogether. Noting that the brightness level per guidance-power-manager is 0.
Setting the brightness levels in guidance-power-manager makes the brightness change... but that does not make use of the brightness buttons (Fn-F7/F8 for this box). When I unplug the machine, the screen dims to where the BIOS thinks it should be for battery-power (as set by the Fn-F7/F8 keys the last time on battery). As soon as the "Switching to battery mode." knotify message comes up, the brightness changes again....
Killing guidance-power-manager does *not* fix the problem for me however...
Can I shut off the power-manager handling of these events? and can I get the Fn-keys to work again? This all worked in Feisty. I just rebuilt the box onto a new hard drive this weekend. Mostly a good upgrade, but this is not good.

[lostangel78 (lostangel78)]

Try typing the following command in a terminal:

xgamma -gamma 0.75

If that doesn't work you need to install xgamma from the repos.

I have posted my own solution here on setting it up:

http://ubuntuforums.org/showthread.php?p=4168042#post4168042

[Dana Goyette (danagoyette)]

Hmm, when I was looking at the changelog for 2.6.25-rc1, I noticed the following two changelogs and bug reports that may address this issue:

    ACPI: video: Rationalise ACPI backlight implementation
    http://bugzilla.kernel.org/show_bug.cgi?id=9277

It also addresses this second issue of having two video objects (though it doesn't break anything for me):

    ACPI: video: Ignore devices that aren't present in hardware
    http://bugzilla.kernel.org/show_bug.cgi?id=9614

I would like to see this change incorporated into the Hardy kernel -- and backported to Gutsy, if at all possible.

[Leann Ogasawara (leannogasawara)]

Thanks Dana. I'm including the corresponding upstream git commit id's for the kernel team to reference. Thanks.

commit 38531e6fe51ad5c7dfe72e0e066b5f54bc1921cd
Author: Matthew Garrett <email address hidden>
Date: Wed Dec 26 02:03:26 2007 +0000

    ACPI: video: Rationalise ACPI backlight implementation

    The sysfs backlight class provides no mechanism for querying the
    acceptable brightness for a backlight. The ACPI spec states that values
    are only valid if they are reported as available by the firmware. Since
    we can't provide that information to userspace, instead collapse the
    range to the number of actual values that can be set.

    http://bugzilla.kernel.org/show_bug.cgi?id=9277

    Signed-off-by: Matthew Garrett <email address hidden>
    Acked-by: Zhang Rui <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

commit 3fa2cdcc45a0176de15cac9dbf4ed2834ebf8932
Author: Matthew Garrett <email address hidden>
Date: Thu Feb 7 01:44:06 2008 +0000

    ACPI: video: Ignore ACPI video devices that aren't present in hardware

    Vendors often ship machines with a choice of integrated or discrete
    graphics, and use the same DSDT for both. As a result, the ACPI video
    module will locate devices that may not exist on this specific platform.

    Attempt to determine whether the device exists or not, and abort the
    device creation if it do not exist.

    Signed-off-by: Matthew Garrett <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

[Ben Collins (ben-collins)]

Should be in the next kernel upload

[Dana Goyette (danagoyette)]

Thank you! I'm glad to see that the 2.6.24-11-generic kernel I recently installed has fixed this!
One slightly odd request: sometimes, for a gimmick, it's fun to turn off the backlight deliberately; is there any way to do this now, perhaps by echoing a specific negative value into sysfs manually? I'd think it'd require some alteration to the patch.

[Ryan Sinn (ryan-sinn)]

This was working fine for me on my ThinkPad X61T laptop until the latest Kernel this worked fine.

With the latest kernel (24-11) my laptop display now properly displays after resuming from suspend, but now I cannot control the brightness through the Gnome applet or the function keys on my keyboard.

The keys (via OSD) and slider work and show that the brightness is being changed, but it doesn't actually change the brightness of the screen.

[Dana Goyette (danagoyette)]

I thought of a different way to re-add zero: simply allow it as one of the usable values. As it is right now, gnome-power-manager's indicated brightness levels
(100, 85, 71, 57, 42, 28, 14, 0)
 no longer match the indicated values in the dsdt:
(100, 87, 75, 62, 50, 37, 25, 12, and a true zero you could add.)

In addition, some time try out guidance-power-manager, and you'll notice that its backlight control is far more sane -- it actually remembers the levels you set for each power state.

[Pedro Villavicencio (pedro)]

not a gpm bug.

[Leann Ogasawara (leannogasawara)]

@Ryan, is this fix still the cause of a regression for you? Does the regression still remain in the upcoming Jaunty 9.04 release - http://cdimage.ubuntu.com/daily-live/current/ . Please let us know. Thanks.

[Ryan Sinn (ryan-sinn)]

This seems to be resolved. I've upgraded to 9.04 on both my laptops and
I haven't had backlight issues since.

On 4/21/2009 2:15 PM, Leann Ogasawara wrote:
> @Ryan, is this fix still the cause of a regression for you? Does the
> regression still remain in the upcoming Jaunty 9.04 release -
> http://cdimage.ubuntu.com/daily-live/current/ . Please let us know.
> Thanks.
>
> ** Changed in: linux (Ubuntu)
> Status: Fix Committed => Fix Released
>
> ** Changed in: linux (Ubuntu)
> Assignee: Ben Collins (ben-collins) => (unassigned)
>
>

[tralala28 (tralala28)]

i still have this problem on my Sony VPCF12M1E , actually i have it on some linux distributions , fedora ubuntu suse debian (all current releases, havent tried the others).
About ubuntu i tried both 10.04lts and 10.10.

The situation is that the screen either works at full brightness or doesnt work at all, because when decreasing it, the screen becomes black.
This is what happens both when i manually decrease the screen brightness from 100% level AND when the power management program decreases brightness due to user inactivity or because of power manag. profile switching (for example when you unplug the acadapter)....

this's a big problem for laptops, i hope it gets fixed.

thanks, goodbye.