Um, do you mean ac_dpms_sleep_method?

Bug occurs for me too.

We are doing:

gpm_dpms_set_mode (manager->priv->dpms, GPM_DPMS_MODE_OFF, &error);

i.e. setting the monitor off - correctly.

Does "xset force dpms off" turn off your backlight?

Yes it does turn it off correctly with xset.

If I set ac_dpms_sleep_method to 'off', then it works, but *only* if I close the lid twice. I.e. the first time I close the lid, with my session 'unlocked', I can see (both via a remote session with xset, and by peering through the edge of my laptop) that the backlight is still on. If I open the lid, it unblanks and presents me with a 'locked' display. If I /then/ close the lid, the backlight *is* turned off.

I guess there are two problems here (but I'm not quite sure):

1. The prime topic of this bug: g-p-m should default to turning off backlight on AC lid close. It does not, unless one twiddles with a magic gconf key.

2. Even if one does so, there seems to be a bug that causes g-p-m to not reliably  
   'Off' the screen. you have to close/open/close the lid as 'OFF' only seems to
   work reliably from locked session.

Xset also turns off my backlight fine.

When i have ac_dpms_sleep_method set to 'off' it all works fine. I close the lid and it turns off the screen and backlight first time every time. It did not used to do this when i had acpid running but after a fresh install (Dont remove python and gcc on a Gentoo system ;)).

In regards to the comment above,

1. Yes, g-p-m does not do that and this should be fixed.

2. This only seems to happen with some people on different setups, as it works fine with or without my screen been locked.

Iam running 'Power Manager 2.16.0'. I have aa Dell Inspiron 1300 and dont have acpid running. Also suspend does work on this laptop but not with gentoo (This is another bug for another day ;)). I assume my suspend issues and hibernate are to do with my own hand rolled kernel.

In my case:

- Dell D420 (intel i915)
- acpid running (seems to report lid events reliably btw)

acpi_listen (lines prefixed with '->' are my commentary):

-> gnome session not locked, lid is closed:
video VID 00000080 00000000
button/lid LID 00000080 00000003
-> xset reports monitor still 'On'
-> backlight is still on
-> lid opened:
video VID 00000080 00000000
button/lid LID 00000080 00000004
-> display unblanks and we see the screensaver 'unlock' dialogue
-> close the lid:
video VID 00000080 00000000
button/lid LID 00000080 00000005
-> now xset reports DPMS 'Off'
-> peering in laptop seems to confirm backlight is finally off

What other information would be useful?

I also have an intel i915 chip in my laptop. 

Have you tried locking the screen and then shutting the lid ? If that works it seems that the screen is been locked after the lid is closed and the screen is told to be turned off. Also it might be gnome-screensaver and g-p-m settings interfearing but they should not be doing this.

If you need any debug info or output from lshal or lspci just ask :)

Well, locking the screen first makes no difference, if I close the lid with the screen blanked (not Off) due to manually locking. *BUT* if before closing the lid I move the mouse so the screen is unblanked and I see the g-screensaver 'unlock' dialogue and I *then* close the lid, it works! (good thinking on that one!)

If I look in the g-p-m 'information' at the events, I see no difference between the case of lid closed the first time and the case of lid re-opened and closed (other than the lid-open events obviously). In both cases it goes:

Lid closed: The laptop lid has been closed
DPMS off: DPMS blanking screen because the lid has been closed on ac power
DPMS off:

Perplexing..

So it sounds very much like the problem is that something fails to DPMS Off the screen when it is already blanked (but not DPMS Off). Is that enough of a clue for someone to find the problem? 

Note that 'xset dpms force off' works fine always, regardless of whether screen is blanked or not.

This is interesting, what model/brand is your laptop ? 

Have you tried shutting down acpid and then attempting to let g-p-m do its thing ?

If that does not work i think it may be a an ordering issue of when things are run, but this is just a wild stab in the dark as i know nothing about how g-p-m works ;).

Could it be the last dpms time event wasn't long enough to trigger the screen?

We currently have:

	/* Some monitors do not support certain suspend states, so we have to
	 * provide a way to only use the one that works. */
	if (strcmp (dpms_method, "default") == 0) {
		/* suspend after one timeout, turn off after another */
		standby = timeout;
		suspend = timeout;
		off     = timeout * 2;
	} else if (strcmp (dpms_method, "standby") == 0) {
		standby = timeout;
		suspend = 0;
		off     = 0;
	} else if (strcmp (dpms_method, "suspend") == 0) {
		standby = 0;
		suspend = timeout;
		off     = 0;
	} else if (strcmp (dpms_method, "off") == 0) {
		standby = 0;
		suspend = 0;
		off     = timeout;
	} else {
		/* wtf? */
		g_warning ("unknown dpms mode!");
		g_free (dpms_method);
		return;
	}

Patrick, do you mean the key ac_dpms_sleep_method or action_ac_button_lid is set to default? Richard.

Yes, i did mean ac_dpms_sleep_method is set to default rather than off, thats what happens when you dont get enough sleep ;)

2006-09-18  Richard Hughes  <richard@hughsie.com>

	* src/gpm-dpms.h:
	* src/gpm-dpms.c: (gpm_dpms_method_from_string)
	* src/gpm-manager.c: (sync_dpms_policy):
	Add gpm_dpms_method_from_string(), and try to do more sane things for
	laptop hardware to try to fix bug #354726.

Can somebody test CVS HEAD and confirm if this fixes the bug please? Thanks.

Works in CVS HEAD here, thanks for fixing Richard :).