On dim, 2009-03-01 at 07:39 +0000, Sheridan Hutchinson wrote:
> Package: pm-utils
> Version: 1.2.4-2
> Severity: important
> 
> Hello,
> 
> I'm a longtime pm-utils user on my Thinkpad X40.  This laptop reached S3 and 
> S4 
> nirvana a couple of years ago with the minimum of fuss.
> 
> I'm using squeeze and a nice shiny new pm-utils package turned up this week.  
> I 
> installed it and didn't think much of it.  A consequence of this new version 
> is 
> however that my backlight no longer comes back on when I resume from S3 
> (haven't 
> tested S4 yet).  It was working reliably prior to this.
> 
> I do not have uswsusp installed (as I've never needed it) and have been 
> contently using
> the in-kernel suspend mechanism.
> 
> The only thing this laptop previously needed to work was to pass 
> acpi_sleep=s3_bios,s3_mode
> hints to the kernel in the /boot/grub/menu.lst file.  They are still in there.
> 
> What should I do to get my backlight working again?  This is a production 
> machine
> that is very compromised by this bug.  If I hold the screen under intense 
> light
> I can make out images on the screen and it is perfectly possible to kill X
> with an CTRL ALT BACKSPACE however this doesn't bring the backlight back
>on.

I have the same kind of problems. Well, in fact, my backlight is not
correctly switched off when suspending using pm-suspend on my shiny
“new” X31. I tried to debug the /usr/lib/pm-utils/sleep files, and think
I may have found the problem.

In /usr/lib/pm-utils/sleep.d/98smart-kernel-video there's a check to
detect if the system uses KMS, and disable all the quirks if it's the
case.

The test is:

have_kms()
{
    # if we are running with a KMS-enabled video driver, we should not
    # attempt to run any quirks
    [ -d /sys/class/drm/card0/device/graphics/fb0 ] || return 1
    remove_all_video_quirks
    add_parameters --quirk-no-chvt
}


But on the X31 (using a radeon card, and thus not using KMS) I have
the /sys/class/drm/card0/device/graphics/fb0 folder. This folder only
means there's a framebuffer running, I guess, and I think it then breaks
many machines.

Having the function return 1 unconditionnaly fix the problem here, so I
really think it's related to the remove_all_video_quirks stuff.

Cheers,
-- 
Yves-Alexis

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to