Hello,
The manpage for pm-suspend should mention the
variables {ADD,REMOVE}_PARAMETERS which can
be set in /etc/pm/config.d/*
These variables are mentioned in /usr/lib/pm-utils/default
As far as I can see this is currently the only way
to setup/disable --quirk-* parameters by default.
Regards,
Kapil.
Kapil Hari Paranjape wrote:
Hi
Actually, the preferred way, is to provide the quirks via HAL [1] (and
send them upstream, so everyone can benefit) and not call
pm-suspend/pm-hibernate directly.
For the desktop you have apps like gnome-power-manager or kpowersave,
for the console you e.g. have powersave.
This tools send a request to HAL, which then calls
pm-suspend/pm-hibernate with the correct parameters/quirks.
The {ADD,REMOVE}_PARAMETERS functionality is sort of a hack and quick
workaround, for very special cases. That's why I didn't document that
prominently in the man page.
If those parameters are mentioned in the man page, I should probably
emphasize the usage of hal, what do you think?
Cheers,
Michael
[1] http://people.freedesktop.org/~hughsient/quirk/
Hello,
The following is long but I thought it would be best to clarify the
entire context.
Here is some background.
I had a working suspend/resume with acpi-support <= 0.109-1
based on some local tweaking most of which Bart Samwel had kindly
passed on to the upstream maintainers of acpi-support as well.
When I upgraded to acpi-support 0.109-3 I found that the use of the
scripts in /etc/acpi-support was "deprecated". However, that
suspend/resume continued to work for me.
In order to "keep up with the jones's" I decided to check how well
the new setup would work with my system.
Since it was clear that the new system depended on pm-utils, I
installed that and figured out the "--quirk-*" arguments as mentioned
in the bug report. There was an additional quirk required for my
system (output of lshal is attached for reference) which was that the
"99video" hook had to be disabled and the enclosed "98video" hook had
to be installed /etc/pm/sleep.d. As you can see the differences are
in the order the various "vbetool" commands are called.
It is this that led me to comment:
Following receipt of this email, I installed hal and figured out
that putting suitable data (see the third enclosure) in
/etc/fdi/information/02local/20-20-video-quirk-pm-ibm.fdi. After
restarting "hal" it was possible to resume the system if it was
suspended with:
pm-suspend --quirk-dpms-on
Unfortunately, just "pm-suspend" does not currently work as
documented at the end of the page
(http://people.freedesktop.org/~hughsient/quirk/quirk-suspend-try.html):
If you issue a pm-suspend command without any options then
the fdi quirks will not be used. You still have to use the
--quirk-dpms-on type arguments. There is discussion to add a
new argument --auto to use the hal quirks, but this has not yet
been included upstream.
I next installed powersaved and set
SUSPEND_METHODS="dbus-pm"
as recommended in the file /etc/default/acpi-support. In spite of
playing with various parameters in /etc/powersave/events as suggested
in the documentation of "powersaved" I could not get this to suspend
at all. It looked like this led to the ACPI keys being ignored
entirely.
In the end, I have gone back to the "pm-utils" approach to suspend
and no longer use the "hal" or "dbus" approach. One reason is that
I need to have "ADD_PARAMETERS" in any case because of the bug in
pm-suspend which makes it necessary to have _some_ parameters in
order to use quirk settings from hal.
I do not know how many users there are who have a laptop exactly
like mine but at this point, it looks like such users _must_ use
ADD_PARAMETERS and blacklist/replace the "99video" hook in order to
get a working resume.
I hope this helps in resolving the issue in one way or the other.
Regards,
Kapil.
--
Hello, Actually, the correct "98video" hook is enclosed. The earlier one missed the call to "vbetool vbemode set 3". Regards, Kapil. --
Hello, Sorry for the noise. Here (finally) is the 98video hook to replace the 99video hook in /usr/lib/pm-utils/sleep.d/ Note that the order in which the enclosed script calls vbetool matches that used in the files from the package acpi-support. /etc/acpi/suspend.d/80-video-vesa-state.sh /etc/acpi/resume.d/15-video-post.sh /etc/acpi/resume.d/17-video-restore.sh Regards, Kapil. --
clone 485443 -1 retitle -1 pm-utils: order of calls to vbetools wrong? severity -1 normal thanks Since part of this bug report now deals with the order in which vbetools is called, I am cloning this report with a new title. I do not know if whether the simple fix of calling vbetool in the order suggested in my previous mail will work on all hardware ---- it works on mine! So it may be the case that one of the quirks may be to specify the order! Regards, Kapil. --
Dear submitter, as the package pm-utils has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1058701 The version of this package that was in Debian prior to this removal can still be found using https://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)