Tested with newest DRM from git://anongit.freedesktop.org/git/mesa/drm. Problem still occurs.

We can not reproduce this bug with yesterday's tip on T61(GM965).

The suspend command we used is: echo mem > /sys/power/state

My bet the problem is with kernel 2.6.23 , could you try a kernel 2.6.22 ? 

I used kernel 2.6.23.1 (comment #2), there is no this bug.

Are you using any framebuffer drivers?  Is there an ACPI backlight control method available on your laptop (using the kernel's video driver and looking in /sys/class/backlight should tell you).

I open a bug on kernel bugzilla 
http://bugzilla.kernel.org/show_bug.cgi?id=9642 

Like I had write before, could you try with kernel 2.6.22, and report your experience please ? 

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

It seems that we lose response from the bug reporter... Largely it's a kernel regression. I'm rejecting this bug. Please reopen if you have new findings...

Strange, I remember commenting that it happened with kernel 2.6.22 and 2.6.23, made no difference which. There is no framebuffer driver loaded, and /sys/class/backlight/ is empty.

Ori, welcome back.

1) Do you have a successful story using suspend/resume? I'm wonderring if it is a regression or not.
2) Have you tried suspend/resume _without_ X? Can backlight come back on that?

(In reply to comment #10)
> Ori, welcome back.
> 
> 1) Do you have a successful story using suspend/resume? I'm wonderring if it is
> a regression or not.

No, it was always broken for me, starting with the driver that I had when first
installed (2.2.0)

> 2) Have you tried suspend/resume _without_ X? Can backlight come back on that?
> 

I just did, and it seems to be still broken.

I was also poking around today, and noticed 2 things that are quite interesting:
1) When I hacked my driver to use native backlight mode by default (as opposed to legacy, which it was defaulting to before), killing the X server and restarting it will bring it back. I was running libdrm from git, and jbarnes suggested the VT switch code in it was doing that, but I tested just now with the Debian libdrm (2.3.0), and the behavior persists. I'm 99.99% sure that it didn't do that when it defaulted to the "legacy" mode.

2) The "native" brightness range seems to map from [0, legacy_brightness] instead of [0, max_brightness]. In other words, the value of the maximum brightness that it will show (maximum = 49501)'s brightness seems to change if I change the backlight.

An example of what I mean:
$xrandr --prop
... BACKLIGHT: 49501 ... range(0, 49501)
$xrandr --output LVDS --set BACKLIGHT_CONTROL legacy
$xrandr --prop
... BACKLIGHT 16 ... range(0,255)
$xrandr --output LVDS --set BACKLIGHT_CONTROL 100
 -- the screen gets brighter
$xrandr --prop
... BACKLIGHT 100 ... range(0,255)
$xrandr --output LVDS --set BACKLIGHT_CONTROL native
$xrandr --prop
... BACKLIGHT: 49501 ... range(0, 49501)

However, the native control *does* change the backlight value over the specified min, max.

I'm not sure, but I suspect this might be related.

(In reply to comment #11)
> 
> > 2) Have you tried suspend/resume _without_ X? Can backlight come back on that?
> > 
> 
> I just did, and it seems to be still broken.
> 

Ori, We need to resolve the non-X thing first...

would you please open a bug to bugzilla.kernel.org, choosing acpi as the project, power-suspend-resume as the component? please remember to post:

1) output of acpidump
2) dmesg
3) lspci -vvxxx

No need to enter X. thanks.

kernel bug is filed at http://bugzilla.kernel.org/show_bug.cgi?id=9827

I've got the similar symptom on a Sony 855GM laptop.
Low/None Backlight after resume.
ACPI backlight I/F doesn't work, Xrandr failed to work either.
(xrandr shows the backlight value is changed successfully but nothing happens)
After resume, I need to do a vbetool post in console mode and switch back to X to see the screen clearly.

Ori, can you try the latest DRM git bits again?  They should let you suspend/resume from the console as well as from X.  I'd rather not restructure the 2D driver to handle suspend/resume (the way X is designed makes it a poor fit) when the kernel can handle it.

Just to chime in, I have the same problem on ThinkPad X61 965GM, xorg git Jan 31 2008, Intel 2.2.0, Linux 2.6.24.  The backlight comes back on after a resume only if I switch VT or kill the X server.  xrandr reports

	BACKLIGHT_CONTROL: kernel
		supported: native       legacy       combination  kernel      

I'll be happy to provide any other information if it will help.

The server doesn't really deal with suspend/resume, so you'll need to run a 2.6.25-rc1 or later kernel.  Can you give that a try and see if the backlight comes back?  As an added bonus, 2.6.25-rc1+ will also bring back your text console so that VT switch will work right.

jwbaker, can you try a 2.6.25-rc1 kernel or the DRM modules from git?  Either should fix your backlight problem...

Sure, I'll build it tonight and let you know.

With kernel 2.6.25-rc1 the display doesn't show anything and the laptop doesn't survive a suspend/resume cycle.  Hard to tell if the backlight works when the entire system is in a broken state.  I will try DRM modules from git with 2.6.24 kernel instead.

With 2.6.24 and git master drm the backlight works fine across a suspend/resume.

We sill need Ori's response for comment# 15.

It's ok if Ori doesn't have time, sounds like jwbaker confirmed what I was thinking (btw, sorry about suggesting 2.6.25-rc1 w/o telling you about the suspend/resume workaround, you need to boot with idle=poll to get it to suspend right).

Ori, if you feel like testing this and find problems, please reopen, but in the meantime I'm confident it's fixed, so I'm going to close it out.

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