From freedesktop-pm-utils Tue Oct 07 00:06:45 2008 From: "Michael Biebl" Date: Tue, 07 Oct 2008 00:06:45 +0000 To: freedesktop-pm-utils Subject: Re: [Pm-utils] pm-utils 1.2.1 and 1.1.2.5 released Message-Id: X-MARC-Message: https://marc.info/?l=freedesktop-pm-utils&m=122333801204612 2008/10/7 Victor Lowther : > On Mon, 2008-10-06 at 18:30 +0200, Michael Biebl wrote: >> 2008/10/6 Stefan Seyfried : >> > Michael Biebl wrote: >> >> 2008/10/4 Victor Lowther : >> > >> >> 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? _______________________________________________ Pm-utils mailing list Pm-utils@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pm-utils