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

[Michael Biebl]

2008/10/7 Victor Lowther <victor.lowther at gmail.com>:
> On Mon, 2008-10-06 at 18:30 +0200, Michael Biebl wrote:
>> 2008/10/6 Stefan Seyfried <seife at suse.de>:
>> > Michael Biebl wrote:
>> >> 2008/10/4 Victor Lowther <victor.lowther at gmail.com>:
>> >
>> >> I also wonder, if we shouldn't  always reset acpi_flags to 0.
>> >
>> > IMHO yes, you should. s2ram is doing this for quite some time now after I was
>> > chasing some strange bug reports. This also gets rid of people still using
>> > "acpi_sleep=s3_bios,s3_mode" on the kernel command line and then telling you
>> > "My machine does not need any quirks!!!11!"
>> >
>>
>> Cool, so we basically all agree on that in general.
>>
>> Victor already committed a proposed fix [1].
>>
>> It uses a different approach then s2ram.
>>
>> - s2ram *always* set acpi_flags to 0 *before* suspend, unless you pass
>> custom acpi flags to s2ram
>>
>> - 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? ;)
>
> 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.
>
>> 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.
>

Ok, should we use the following then? (this would basically be what s2ram does):

diff --git a/pm/sleep.d/99video b/pm/sleep.d/99video
index 0beb360..1fe54c2 100755
--- a/pm/sleep.d/99video
+++ b/pm/sleep.d/99video
@@ -144,7 +144,7 @@ suspend_video()
        local acpi_flag=0
        quirk "${QUIRK_S3_BIOS}" &&             acpi_flag=$(($acpi_flag + 1))
        quirk "${QUIRK_S3_MODE}" &&             acpi_flag=$(($acpi_flag + 2))
-       [ 0 -ne $acpi_flag ] && sysctl -w kernel.acpi_video_flags=$acpi_flag
+       sysctl -w kernel.acpi_video_flags=$acpi_flag

        quirk "${QUIRK_NOFB}" &&                die_if_framebuffer
        quirk "${QUIRK_VBESTATE_RESTORE}" &&    vbe_savestate
@@ -166,8 +166,6 @@ resume_video()
        quirk "${QUIRK_RADEON_OFF}" &&          radeon_on
        quirk "${QUIRK_DPMS_ON}" &&             vbe dpms on
        quirk "${QUIRK_RESET_BRIGHTNESS}" &&    reset_brightness
-       # always reset acpi_video_flag -- makes quirk testing more reliable.
-       sysctl -w kernel.acpi_video_flags=0
        return 0  # avoid spurious hook exit failure message.
 }


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?