display is fully dimmed after resume from suspend

Same problem.
Yes, seems to only affect the first suspend operation between total shutdowns.

Not sure if these are also bugs, but:

1. If I suspend by closing the lid I'm asked for a pswd upon resumption, whereas suspend by selecting suspend in shutdown menu does not require a pswd to resume.

2. My internet connection (mobile broadband) does not auto resume. (think this is actually prob. with network manager)

Also experiencing the same problem. Also using the non-free nvidia kernel module. Screen brightness is dimmed only on first resume from suspend, but I've also noticed that the screen is not responding/redrawing correctly on every resume. New windows are drawn but anything that happens within a window is not i.e. typing in a window, selecting a different window, opening a new tab in firefox.

Confirming the bug. Dim on first resume after boot. Using non-free Nvidia drivers.

Can anyone test this on Kubuntu to make sure it is a bug in gnome-power-manager and not pm-utils or something else?

Bug #417610 may also be a duplicate of this bug, though the scope of that bug report is currently limited to intel graphics cards.

A weird part of this bug: after you resume from suspend and the brightness is low, raising the brightness by one spawns a notification, as it should, except the notification shows the brightness as full. If you raise the brightness again, the notification will display the correct (low) brightness level though.

I can confirm this bug & Gabe's last post.

Added regression-release tag since this worked before Karmic.

This has been fixed for me, though I have no idea which updates did the trick. Is anyone else still experiencing this after all Karmic updates are applied?

This is most definitely still a problem for me. I put my laptop to sleep before posting this just to check. I am 100% up to date on updates.

OK, putting this back to confirmed since this isn't fixed for everyone.

I have gotten this bug again, though it's not as consistent as it use to be; sometimes I suspend and it resumes at normal brightness, and sometimes it's dimmed.

yes ,this bug is seen in karmic,i didnt have it in jaunty.
the brightness is at the lowest after suspend,it is very consistent.

This is also a problem for me. After a suspend the brightness is at its lowest and said notifications show that the brightness is at its highest.

The one thing I have noticed is that when I resume from standby, the display level is still at 100%.

Also, I am using AC power when entering standby and still on ac power when resuming from standby

gateway mt3422
ubuntu 9.10 i386 up-to-date
using default gnome-power-manager settings
test done on ac power only. 100% reproducible as stated here.
screen too dim only on first resume from suspend after boot.
when checked, power-manager reports brightness at 100%.
adjusting gnome-power-manager display brightness slider 'wakes up' display back to full brightness.

attached: gnome-power-bugreport.txt made from /usr/share/gnome-power-manager/gnome-power-bugreport

I can confirm this bug with all the Ubuntu 9.10 updates to this date. (HP dv5-1050en)

Confirming this bug too on Dell Vostro 1500 with nvidia drivers.

I can confirm this bug in Lucid daily build 03/11 with nouveau driver on a Dell Precision M90 (x86_64)

I can confirm i'm having the same problem/bug on Compaq CQ60-210US with nvidia geforce 8200m. it is also plugged in when put to sleep, and is still plugged in when resuming. ubuntu 9.10 Karmic

I'm experiencing this problem on ASUS F3Jp with ATI Radeon X1700. So same here, dimmed screen on the first resume, but bright on the second.

Thanks

similar to bug #35223?

@Sebastien: I don't think it is the same bug, I only have this problem between suspend/resume cycles, I will test what happen on reboot, but as far as I remember it was brightness was being saved OK.

This is still a problem on lucid gnome power manager here on a dell inspiron with nvidia 7300

I wonder if there was a change in how acpi records / sets brightness and gnome-power-manager was not updated to realize it.

I notice 2 different kernel locations on my system for brightness.

One is /sys/devices/virtual/backlight/acpi_video0/brightness and has the value of 0 on boot up. This seems strange because the lcd is at maximum brightness.

The other is /sys/devices/virtual/backlight/acpi_video0/actual_brightness and has the value of 7 on boot up. On my system, 7 is the maximum.

I suspect on suspend | hibernate that gnome-power-manager is saving "brightness" rather than "actual_brightness" and restoring that upon resume.

So, I added this little script to /etc/rc.local to set them the same.

brt=`cat /sys/devices/virtual/backlight/acpi_video0/brightness`
abrt=`cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness`
if (( $brt != $abrt )) ; then
echo $abrt > /sys/devices/virtual/backlight/acpi_video0/brightness
fi

Now, on my first suspend the bug does not occur.

I'm not sure if this will be the same for everyone. To find out your own brightness, just search /sys/ with this command:

paul :~$ find /sys/ -iname '*bright*'
/sys/devices/virtual/backlight/acpi_video0/brightness
/sys/devices/virtual/backlight/acpi_video0/actual_brightness
/sys/devices/virtual/backlight/acpi_video0/max_brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:01.1/leds/mmc0::/brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:03:01.1/leds/mmc0::/max_brightness
/sys/module/video/parameters/brightness_switch_enabled

If your locations are different, then change /etc/rc.local to the different values for yours.

regards,

@pauls: that's a great find and I can confirm that syncing "brightness" to "actual_brightness" at boot time fixes the problem. I just had to make a small modification to the script for it to work on karmic:

brt=`cat /sys/devices/virtual/backlight/acpi_video0/brightness`
abrt=`cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness`
if [ "$brt" != "$abrt" ]; then
echo $abrt > /sys/devices/virtual/backlight/acpi_video0/brightness
fi

Dell XPS M1330, Nvidia GeForce 8400M GS graphics card here. I can confirm everything. I had this bug already on Karmic, did an upgrade to Lucid - the bug continues.
pauls's script with Harm's mod works like a charm for me.

Thanks Harm. I forgot that "!=" is for strings and strings require quotes. I guess I should have used "-ne" instead and it probably would have worked. My script failed to set brightness to 7 on a subsequent boot and I had the dim display upon resume again. But, after changing it, it seems to always work now.

I am running 10.04 (final) on a MacBook Pro 5,5 and the workaround described by Harm and pauls does not work. Even though after resume from suspend the screen is clearly on maximum brightness, both /sys/devices/virtual/backlight/mbp_backlight/brightness and /sys/devices/virtual/backlight/mbp_backlight/actual_brightness contain the value "5" (or whatever I set via the brightness keys).

Marten, you might want to try something like this in your /etc/rc.local:

brt=`cat /sys/devices/virtual/backlight/mbp_backlight/brightness`
abrt=`cat /sys/devices/virtual/backlight/mbp_backlight/actual_brightness`
logger -t rc.local "brightness was $brt , actual_brightness was $abrt"
if [ "$brt" != "$abrt" ] ; then
echo $abrt > /sys/devices/virtual/backlight/mbp_backlight/brightness
afterbrt=`cat /sys/devices/virtual/backlight/mbp_backlight/brightness`
logger -t rc.local "changed brightness to $afterbrt and actual_brightness is $abrt"
else
afterbrt=`cat /sys/devices/virtual/backlight/mbp_backlight/brightness`
logger -t rc.local "no brightness change needed, brightness is $afterbrt and actual is $abrt"
fi

This should give you a log entry in /var/log/messages that will show some helpful information when /etc/rc.local executes. So, after booting, check the log with:

$ grep bright /var/log/messages

and see what happened during boot.

It seems like you could have a different problem since your /sys/ entry is different than ours. Take a look in /proc/ to see if you have any more places where brightness is set or shown:

find /proc/ -iname '*bright*'

hth

I am also experiencing this bug with 10.04. I just can't remember having it with 9.10.

Hmm... strange.

I overwrote the values in /sys/devices/virtual/backlight/mbp_backlight/brightness and /sys/devices/virtual/backlight/mbp_backlight/actual_brightness and now the brightness seems to be properly saved on suspend.

Same problem. This is using 64Bit Ubuntu 10.04 on a VAIO VGN-FW373J. ATI Mobility Radeon HD 3650.

The Bug has put me between a rock and a hard place (such that using Ubuntu on this system looks undoable). The screen is too dim to use after any Sleep or Hibernation.

Installing the 2D-3D driver solves the dimness, but introduces a host of other bugs. The screen (graphics and resolution) scrambles when recovering from screen savers, screen locks and hibernation. The Plymouth logo is also mucked up - a simple Bug that hasn't been dealt with,

//I overwrote the values in /sys/devices/virtual/backlight/mbp_backlight/brightness and /sys/devices/virtual/backlight/mbp_backlight/actual_brightness and now the brightness seems to be properly saved on suspend.//

Phillip, if you have a solution, please provide some guidance? The information you offered isn't specific enough for those of us who are non-hackers.

Patrick,

1) install the fglrx driver you desire
2) open terminal and enter:

$ find /sys/ -iname '*bright*'

3) post back the results and we'll help you with the rc.local script.

Thank you, Pauls. The fglrx driver suggested by Ubuntu was the generic: "3D-accelerated proprietary graphics driver for ATI cards." Installing the driver seemed to create more (and more serious) problems than it solved, so I uninstalled it. (I'm not a gamer and probably don't need accelerated graphics.) Here is the result of the command you suggested with no proprietary driver present:

find: `/sys/fs/fuse/connections/8388613': Permission denied
find: `/sys/fs/fuse/connections/8388609': Permission denied
find: `/sys/fs/fuse/connections/8388610': Permission denied
/sys/devices/virtual/backlight/acpi_video0/brightness
/sys/devices/virtual/backlight/acpi_video0/actual_brightness
/sys/devices/virtual/backlight/acpi_video0/max_brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::radio/brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::radio/max_brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::assoc/brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::assoc/max_brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::RX/brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::RX/max_brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::TX/brightness
/sys/devices/pci0000:00/0000:00:1c.3/0000:06:00.0/leds/iwl-phy0::TX/max_brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:0a:03.1/leds/mmc0::/brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:0a:03.1/leds/mmc0::/max_brightness
/sys/module/video/parameters/brightness_switch_enabled

Is syncing brightness to actual_brightness an acceptable solution to this problem? If so, can we push to get this fix into Lucid, or at least Maverick?

Adding the following, as per Pauls instructions, seems to have worked on my system (as far as suspend goes):

brt=`cat /sys/devices/virtual/backlight/acpi_video0/brightness`
abrt=`cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness`
if [ "$brt" != "$abrt" ]; then
echo $abrt > /sys/devices/virtual/backlight/acpi_video0/brightness
fi

I notice that my function keys (for brightness) no longer "work". When I use them, the brightness slider appears, but I can't adjust the brightness of the screen. I'm not sure this is related...

Gabe, is it possible to find out the source code that sets the values for brightness and actual_brightness and get them to agree after boot up?

It certainly would be better to try to fix it at the upstream source.

My limited knowledge of /sys/ directory is that it's mostly created by kernel drivers .. is there a way to get one of the kernel coders to just look at this bug and see if it could be in the kernel code? If so, then I'm sure linus would appreciate getting a bug filed.

If you decide to add a fix to /etc/rc.local (or some other script), one problem is that each different graphic card / driver seems to create the /sys/../brightness and /sys/../actual_brightness in different locations. To meet this issue, any script would have to search /sys/ first and then test and assign the appropriate values.

Keep in mind that doing this on boot wastes a bit of boot time (milliseconds), but that contradicts one of the goals of ubuntu to cut current boot times in half.

regards,

I really don't know anything about the code, but if you claim the correct place to fix this is in the kernel then I recommend filing a bug upstream, if one hasn't already been filed. Also make sure you test this on the mainline kernel to make sure it's not caused by an Ubuntu patch.

The problem for me is I have no way of figuring this out myself. I'm not a dev and don't know coding. All I did is stumble upon the fact that brightness and actual_ brightness were different after boot and the same after resuming and that setting them the same before suspending eliminated this problem.

IMO my idea here is a work around, not a bug fix.

Same symptoms for me with Lucid Lynx on my HP Mini 1000 (actually a Compaq Mini 700), using a GMA 945 Intel display card.

When resuming from suspend to RAM, I need to use the "increase brightness" function keys to restore to a normal/usable brightness level. Happens on battery and AC, does not matter.

Tried to play with "quirk" in HAL w/o success, eventhough the pm-suspend --quirk-reset-brightness is working.

If I resume from sleep after this command, the brightness is OK (a tad too much actually but is OK).

Same problem here on Lucid on an HP EliteBook 8530w. On resume the screen is dimmed and to make things worse the brightness controls don't function either (making it impossible to turn the brightness back up).

I've tried the solution mentioned in comment 31 & comment 38 but this didn't help. brightness and actual brightness are are equal (both 24) so the script has no effect :(

velitchko@VELITCHKO-PC:~$ find /sys/ -iname '*bright*'
/sys/devices/virtual/leds/hp::hddprotect/brightness
/sys/devices/virtual/leds/hp::hddprotect/max_brightness
/sys/devices/virtual/backlight/acpi_video0/brightness
/sys/devices/virtual/backlight/acpi_video0/actual_brightness
/sys/devices/virtual/backlight/acpi_video0/max_brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::radio/brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::radio/max_brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::assoc/brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::assoc/max_brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::RX/brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::RX/max_brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::TX/brightness
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/iwl-phy0::TX/max_brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:86:09.1/leds/mmc0::/brightness
/sys/devices/pci0000:00/0000:00:1e.0/0000:86:09.1/leds/mmc0::/max_brightness
/sys/module/video/parameters/brightness_switch_enabled

and my rc.local file looks like this

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
brt=`cat /sys/devices/virtual/backlight/acpi_video0/brightness`
abrt=`cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness`
if (( $brt != $abrt )) ; then
echo $abrt > /sys/devices/virtual/backlight/acpi_video0/brightness
fi

but the problem is that the display is still dim after reloging from hibernate or suspend.
Does anyone have any ideas?

Seems to be gone on 10.10 Beta. Can't remember the behaviour on 10.04.

gateway MT3422 | 1.7 ghz amd athlon64 | nvidia go 6100 | kubuntu 10.04

same laptop i had UBUNTU installed at the time of subscribing and commenting about this bug [comment #17 on this thread].

suspend-to-ram (sleep mode) seems to work fine under KUBUNTU 10.04

IBM X41 thinkpad, ubuntu maverick meerkat default (ATI ?) drivers.

Happens RARELY, maybe 1/50 of all resume from standby operations.

Still - the only "workaround" I know of: squint and make out what's going on to close and save and shut down cleanly; reboot.

tp.

Same problem on Toshiba Qosmio F10-120 laptop with nvidia fx go5700 gpu.

This problem appears to be fixed in Natty Narwhal (11.04)

No, at least not for a Sony Vaio VPCF12M1E with Nvidia Gforce 330m.

Yep, same issue. 10.04 LTS on Toshiba Satellite Pro L510.

I'll add I'm not using any non-free drivers, using Xubuntu 10.04. Dimming after suspend not a problem in 10.10 or 11.04 with Xubuntu (or Ubuntu). Graphics:

01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric

This Bug happens to me all the time

 System Info: #11
    Manufacturer: "Hewlett-Packard"
    Product: "HP EliteBook 8530w"
    Version: "F.11"

34: PCI 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.318]
  Unique ID: VCu0.BB4zKyzKUBD
  Parent ID: vSkL.PuMaBpmAjf4
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "nVidia VGA compatible controller"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x065c
  SubVendor: pci 0x103c "Hewlett-Packard Company"
  SubDevice: pci 0x30e7
  Revision: 0xa1
  Driver: "nouveau"
  Driver Modules: "drm"
  Memory Range: 0xd2000000-0xd2ffffff (rw,non-prefetchable)
  Memory Range: 0xc0000000-0xcfffffff (ro,non-prefetchable)
  Memory Range: 0xd0000000-0xd1ffffff (rw,non-prefetchable)
  I/O Ports: 0x5000-0x5fff (rw)
  IRQ: 16 (1981 events)
  Module Alias: "pci:v000010DEd0000065Csv0000103Csd000030E7bc03sc00i00"
  Driver Info #0:
    Driver Status: nvidiafb is not active
    Driver Activation Cmd: "modprobe nvidiafb"
  Driver Info #1:
    Driver Status: nouveau is active
    Driver Activation Cmd: "modprobe nouveau"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #14 (PCI bridge)

I don't have that laptop anymore but I found a fix a year ago in the ubuntu forum archives that worked.

Can't find it right now but I had to do someting like this:

blacklist intel agp in modprobe.conf
use "nv" as default driver in xorg

maybe someting else was involved but I hope this comment will help.

I'm getting the same symptoms as this bug in precise with 304 series drivers and a GTX 680 - on a desktop, not a laptop.

$ uname -a
Linux fatherboard 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Please reopen.

Xubuntu 12.04, dimmed every suspend, have to kill xorg (Relog) to regain proper brightness.

Confirmed on xubuntu 12.04.1

Linux dt-xubu64 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

dpkg --list|grep -i nvidia
ii nvidia-common 1:0.2.44.2 Find obsolete NVIDIA drivers
ii nvidia-current 295.40-0ubuntu1.1 NVIDIA binary Xorg driver, kernel module and VDPAU library
ii nvidia-current-updates 304.43-0ubuntu0.1 NVIDIA binary Xorg driver, kernel module and VDPAU library
ii nvidia-settings 295.33-0ubuntu1 Tool of configuring the NVIDIA graphics driver
ii nvidia-settings-updates 304.43-0ubuntu0.2 Tool of configuring the NVIDIA graphics driver

After each resume one or both of my monitors are very dim. To work around, I launch nvidia-settings and force it to update the displays by changing something. This only started happening to me after the last nvidia package update.

Ian

Confirmed on Kubuntu 14.04, ThinkPad T61 , nVidia Quadro NVS 140, NVIDIA binary driver - version 331.38

Same problem with Kubuntu 14.04, on a HP 8530w, NVIDIA Quadro FX 770M, xserver-xorg-video-nouveau 1:1.0.10-1ubuntu2.

It seems it works with Kubuntu 14.04 and Kernel 3.16 (Utopic) on a TP X200.

Problem still exists on Kubuntu 15.10, on a Sony Vaio SVT13126CGS

Still a problem in Xubuntu 16.04

Same here in Ubuntu 16.04 on a Dell Inspiron 1540 laptop

Status changed to 'Confirmed' because the bug affects multiple users.

Problem exists lenovo T420 laptop

Intermittent suspend issue on HP EliteBook 8530w, Ubuntu 16.04 (LinuxLite), NVIDIA Quadro FX 770M, nvidia-graphics-drivers-340 with suspend f4 key/software log-out suspend. Always blank screen after lid close suspend, then resume.

Please open a new report if you still encounter this issue in any of the currently supported Ubuntu releases.