Bug 166957

Well it is now switching off OK, so it must be the screen type being detected.  Hopefully someone will know what to do with this to make it automatically detect the right type in future.

Please attach `hwinfo --monitor' and point out errors in the displayed information.

Quentin, please don't only attach "hwinfo --monitor", but the output of a complete "hwinfo" run. 

Created attachment 80392 [details]
Requested patch

I should point out that I have recently purchased a new monitor and have been playing around with the xorg.conf file so things may be a bit messed up there.  I can however still confirm after a fresh install of RC2 that this is still a problem on my particular set up.

FYI, changing to the generic LCD actually didn't fix it, it seems to work randmonly, it's almost as if it goes to sleep and something wakes it up, but only the backlight.  Very hard to pin down.

Holger, can you help here?

Quentin, do you use gnome or kde?

Does 'xset dpms force off' switch off the backlight for you which it does for me with RC3 on such a machine?

I use both but the requested tests were run on Gnome as KDE's a bit screwed up at present.  I'm fairly sure I've seen this happen under both anyway.  I ran the xset command just now and it did turn my external monitor off, will try with the laptop monitor when I get home.  The interesting thing was that every second time I ran it, the monitor did not stay off, I ran it 6 times with the same result.

So if this command turns the screen off, it's a plain conifguration issue IMO. There's a difference if the screen is justed blanked or completely turned off. Under KDE, you can control the dpms settings either in the control center or via kpowersave. So please try again with KDE after checking the screen options in kpowersave.

Unfortunatelly, I can't find a possibility to change the dpms settings under GNOME. Can you help here, Rodrigo?

Rodrigo, I'm not sure if you are the right one to ask, because it's not directly related to gnome-power-manager, but maybe you know as a gnome-developer.

What DPMS settings you mean? From the g-p-m preferences applet you can set whether to suspend the display and the hard disk. What other settings are you looking for?

Yes, Rodrigo, that was what I'm looking for. I was just too blind.

I tried gnome power manager and it does never switch off my screen. It works with kpowersave, though.
I now see that g-p-m does not set any dpms settings. The minutes for display timeouts specified in the gpm-preferences dialog do not get set. While looking at the code I see that they are never passed to the x11_sync_server_dpms_settings() functions in the gpm code. Can that be true, Rodrigo?

So this is a gnome power manager bug IMO, assinging to you Rodrigo...

I have confirmed also now (in RC3) that the screen get's turned off when I close the laptop lid, however if it is in my room at night, the screen backlight comes back on while the lid is still closed and has not been opened.  I don't know how long it takes, I just know that when I wake up I can see light coming from between the monitor lid and the keyboard.  I've now experienced this many times.

if dpms extension is enabled, that code should be being called, so not sure exactly what is going on. DPMS seems to be enabled by default in autobuild, but maybe we need to explicitly enable it always (--with-dpms-ext).

Building a test package with that in...

Created attachment 83435 [details]
Test package with DPMS enabled

Please test attached package (for i386). Not sure if it will make any difference though, provided you're saying the screen gets switched on after suspending, which is totally done by powersave. That is, g-p-m just calls powersave to suspend and just stops doing things until resumed.

OK, interestingly the package you provided was gnome-power-manager-2.14.0-22 and I had (newer) gnome-power-manager-2.14.0-25.  So I erased it and added your version anyway, will let you know how that goes.

Sorry, no difference, except to say that I have now observed that the time it takes to turn the screen back on after closing the lid is likely what the screensaver delay is set to.  I have therefore put the 10.1 GM version of power manager back on.

Quentin, so every 2nd time you run 'xset dpms force off' has the same result? (the screen going back on)

Because, really, I can't find anything in g-p-m that would wake up the screen when suspended. Only gnome-screensaver could, but it's not supposed to be running when the computer is suspended, isn't it?

I had recently some problems with powersave package from one of the betas when suspending. So, could you try with the very latest update (RC1 if available) and see if this still happens.

I just re-ran the xset command.  It now appears it is not every second time, it is in fact intermittent.  The screen turned off correctly the 1st, 3rd, 6th , 8th, 9th times, so a bit random.  I can't help thinking there is some kind of issue around that.  FYI, when I close my lid the computer does not suspend, it just turns the screen off and that I believe is how the OS is designed to be these days?  I'm confused about your comment regarding RC1, I am running OpenSuSE 10.1 GM, I presume you are talking about SLED?  I can install that instead if you would like.

ok, so what setting do you have in yast->power management for the lid button action? If it's 'Ignore', then yeah it should just ignore the lid being closed, and thus not suspend the computer. If you change that to 'Suspend', what happens?

The option "Laptop lid closing" says "Start Screen Saver"  this is interesting because closing the lid also turns the screen off (I can tell because at night there is no light coming out from between the cracks, and also I just pressed the lid button now with the screen open and it went blank, when unpressing I found that the screensaver was running.  Therefore perhaps the button tells the hardware to turn the screen off at that time not the software, so something might be specifically or accidentally turning it back on?

Yes, on a lid close event, the hardware turns off the backlight. Maybe it's also the hardware which turns it back on, but I doubt that. It also has nothing to do with DPMS settings if I read through this bug again. 

Quentin, it would really be helpful if you try the same with KDE, or even if you are not logged in. gnome-screensver should not run in gdm, right? We really need to figure out if it is an application or hardware hardware problem.

Right, gnome-screensaver won't run when on the gdm login screen, and neither would do gnome-power-manager, so it should be safe to discard/confirm it's coming from the GNOME side.

Anyway, if Quentin has 'run screensaver' on the lid close event, then it's working as expected, right?

Yes, it's ok that the screen is locked, but not that the backlight is turned on again. So Quentin, please confirm that behaviour while being logged out.

Quentin: ping

Created attachment 85587 [details]
The output of hwinfo on Vadym's Dell Inspiron 8600.

Hi. I've got the same problem  with Suse 10.1 for i386 running KDE 3.5.2 on Dell Inspiron 8600. The output of hwinfo is the preceding attachment and the output of lspci is below.
00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01)
01:00.0 VGA compatible controller: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]
02:00.0 Ethernet controller: Broadcom Corporation BCM4401 100Base-T (rev 01)
02:01.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 02)
02:01.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller
02:03.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02)

fireball:~ # rpm -q powersave
powersave-0.13.2-2  #Vadym: updated from suse-factory
fireball:~ # rpm -q kpowersave
kpowersave-0.6.1-7

Holger, do you see anything interesting in the logs? Also, if happening in KDE also, I'd guess it is a powersave problem, isn't it?

So if it also happens with kde, I think it's neither a g-p-m/kpowersave, nor a powersave bug. I suspect a hardware problem and not a software problem. But I think we need some help from the X guys here...

Stefan, do you remember something similar with the backlight being turned on after some time? Or do you have any idea?

Assigning to me for now...

Hi. Some additional info to go along with comment #28. "xset dpms force off" used to work just fine on the same notebook while running Suse 9.2/9.3/10.0, so, IMHO, it does not quite look like a hardware issue.

>Stefan, do you remember something similar with the backlight being turned on
>after some time? Or do you have any idea?
Unfortunately I don't. :-(

*** Bug 132304 has been marked as a duplicate of this bug. ***

Any progress on this issue? Is there anything I can help with - like enabling extra logging or installing a debug version? 

I've just noticed that /var/log/messages is full of repeated messages like the following

Jul  9 14:45:04 fireball [acpid]: received event "battery BAT0 00000080 00000001"
Jul  9 14:45:04 fireball [acpid]: notifying client 2622[0:0]
Jul  9 14:45:04 fireball [acpid]: notifying client 3901[0:0]
Jul  9 14:45:04 fireball [acpid]: notifying client 6847[0:0]
Jul  9 14:45:04 fireball [acpid]: completed event "battery BAT0 00000080 00000001"

The notified clients are 
root      2622  2302  0 Jul08 ?        00:00:01 hald-addon-acpi
root      3901     1  0 Jul08 ?        00:02:00 /usr/sbin/powersaved -d -f /var/run/acpid.socket -v 3
root      6847  4572  8 Jul08 tty7     01:58:53 /usr/X11R6/bin/X -br -nolisten tcp :0 vt7 -auth /var/lib/xdm/authdir/A:0-zD9XLk

Previously, I never saw these messages in /var/log/messages.

Quentin, the information requested from comment #25 could still be helpful. How is the behaviour if you are at the login screen?

Sorry but I uninstalled OpenSuSE some time ago in favour of SLED10.  There was just too many problems with it for me to deal with given my current scope of work.  I am so busy I don't even know if the problem exists on SLED10 or not, I think it has actually gone away.  If there is any info from SLED10 I can give you on the assumption that it is working, please ask away.

Well, you just need to suspend and close the lid, and see if the screen is switched on. I'll close it, so if you can replicate it again, please re-open