[Pm-utils] pm-utils 1.2.1 and 1.1.2.5 released

[Stefan Seyfried]

Victor Lowther wrote:
> On Mon, 2008-10-06 at 18:30 +0200, Michael Biebl wrote:

>> - pm-utils does not set acpi_flags on suspend, unless you pass
>> --quirk-s3* to pm-suspend. On resume it always sets acpi_flags to 0.
>> This can have weird effects. If e.g. you use the kernel option
>> acpi_sleep, acpi_flags would be != 0 on first suspend and 0 on the
>> second suspend.
> 
> I totally was not thinking about kernel commandline options.  Do people
> still use those things? ;)

Yes. I still get reports "echo mem > /sys/power/state works, but s2ram -f
doesn't". When I investigate them, it usually turns out that they gave
acpi_sleep=... on the kernel command line ;-)

> My choice of resetting acpi_video_flags after the fact was completly
> arbitrary and did not reflect any deep logic or special insight -- I was
> just thinking in terms of resetting it after suspend and not of always
> setting it before suspend.
> 
>> But shouldn't we restore the acpi_flags that were set before suspend?
> 
> I don't really see why -- IIRC, the video acpi flags are only used for
> suspend/resume, otherwise they are irrelavent.

Exactly. And it is good to have them in a defined state, to avoid getting
false quirk reports.

>> Basically it would be like that
>>
>> suspend
>> 1.) Store current kernel.acpi_video_flags
>> 2.) Set kernel.acpi_video_flag to 0 unless you pass custom acpi flags to s2ram
>> resume
>> 3.) restore the value from 1.)
> 
> Eh, taking kernel commandline options into account I would just always
> set the acpi_video_flag on suspend, even if we are just setting it to
> zero.  The value it has after resuming does not matter until we are
> ready to suspend again.

I agree.
-- 
Stefan Seyfried
R&D Team Mobile Devices            |              "Any ideas, John?"
SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out."

This footer brought to you by insane German lawmakers:
SUSE Linux Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)