this is a known kernel bug. Can you name a kernel version where it last worked?
BTW: editing the delivered scripts is a bad idea, better create your own event script. It's easy and you are a bit safer if we should ship an update.

AFAIK it never worked with backlight tuning off just with such a workaround. I couln't find a user cusomizable way (like a prepare_suspend_to_ram.local for example) and addto add commands run before suspend. Is there a recommended way which survives an update of powersave RPM?

file:///usr/share/doc/packages/powersave/powersave_manual.html#Scripts

Warning: the documentation may be outdated, so looking in one of the provided scripts (log_ac_change is probably a good example) is recommended.

I don't think I want to put playing with radeon's backlight into kernel when it can be one in userspace very well. radeontool light off is indeed right solution... suspend.sf.net package integrates radeontool, but this is too late for 10.1. I think we should just work around this in scripts, or document work around somewhere.

I am now using an X32. If it has the same problem, you can expect it to be fixed in 10.1 ;-) Anyway, the vbetool scripts in /usr/share/doc/packages/powersave/contrib/ are probably a good start, no need to patch the kernel.

i am working on a general solution to this. Unfortunately it is not clear if this will be ready for 10.1.

In the meantime, could you test s2ram from suspend.sf.net's CVS?

i have improved radeontool hugely (no more "lspci" output grepping...), but obviously somebody need to test if it still works (it does for me...)
I'll attach a rpm and a src.rpm to this bug and would appreciate if everyone gives it a try if it still does what you expect it to do ;-)
Starting it with --debug gives a bit more information, it also tells you which device on your PCI bus it identified as a ATI Graphics card.

Lenz, i seem to remember you were once using radeontool, too. If not - just remove yourself from this bug.

If this is successful, the $Subject of this bug will also be fixed for 10.1, so i am hopefully back on-topic ;-)

Created attachment 71741 [details]
radeontool.i586.rpm for 10.1

Created attachment 71742 [details]
radeontool source.rpm

For those who want to know what i am giving them to test ;-)

Created attachment 71745 [details]
statically linked version of radeontool

statically linked radeontool for those of you not running latest 10.1 ;-)
gunzip before use.

Does this mean this is fixed for 10.1?

not yet, i'd need a report from an X31 owner.
Probably the X31 will also work with "s2ram -f -a3 --radeontool", but i need verification. Björn, could you try the procedure described on http://en.opensuse.org/S2ram (if you do not have Beta9 installed, an up-to-date kernel and "suspend" package from factory should be enough for this test)?

Björn? Status?

We are going towards release (RC-phase) and want to know where we are.

Having removed my own radeontool hacks and issuing the command from #13 works nicely here for me on my X31! :-)

If you now would provide the "s2ram -i" output from your machine, it would work out of the box in future releases ;-)

pell:~ # s2ram -i
This machine can be identified by:
    sys_vendor   = "IBM"
    sys_product  = "2672C8G"
    sys_version  = "ThinkPad X31"
    bios_version = "1QET96WW (3.01 )"

Will this now just be just enabled for this specific BIOS release or for previous BIOS releases, too? :-)

It will be enabled for
 "IBM"
 "2672*"
 "*"
 "*"

or do you know of problems with different BIOS releases?
This won't make it into 10.1, but into future products.
For 10.1, just hack the apropriate s2ram call into /usr/lib/powersave/do_acpi_sleep (if you would not need radeontool, you could use the variables in /etc/powersave/sleep, but i noticed right now that i did not implement the radeontool case in powersaved ;-)

I'll close this as fixed - although it will only be fixed after 10.1