Hi STeve,
Steve Langasek wrote:
On Sun, Mar 16, 2008 at 02:47:34PM +0100, Bart Samwel wrote:
doing the same for Ubuntu. I think we're all agreed that the resume/suspend
code should come out of acpi-support, it's just a question of doing the work
to make it go away gracefully.
[Adding Matthew to the CC list.]
Migrating the quirks might be a bitch. And of course there's the fact
that pretty much all of acpi-support is configuration files, so it's
pretty easy to break *someone's* system when you remove the suspend
support. :-/
but I'll then adapt that so that it translates them into pm-utils calls or
some such.
Sorry, what do you mean? Currently, /etc/acpi/hibernatebtn.sh just
generates 'acpi_fakekey $KEY_SUSPEND' - surely that's appropriately generic
for all purposes, and doing anything that's more directly tied to pm-utils
would be a regression?
Yeah, it should be "some such" rather than "pm-utils calls". :-) I find
it interesting that this generates a suspend button and not a hibernate
button. Maybe the key code is a misnomer? Hmmm.... I'm not at my own PC
so I can't check it right now.
I would suggest at least to remove hibernate from the equation.
acpi-support provides hibernation and suspend itself, and maps the
hibernate/suspend keys to its own hibernate and suspend support. It does
not use hibernate. Well, unless you tell it to -- but that option is only
available in version 0.105-1, which is pending upload.
Ok, on closer look I do see that /etc/acpi/events/sleepbtn points at
/etc/acpi/sleep.sh, unlike the various "hibernate" buttons which just
generate a keypress... I'm not sure why that inconsistency exists in the
first place?
Matthew can probably tell you more about this, but I guess this is so
that suspend works always, and not only when you're not running
gnome-power-manager or a similar power management daemon. In these
situations, acpi-support usually takes the approach of generating a key
press if gnome-power-manager or klaptopdaemon are running, and DIY if
they aren't. It's probably wrong if it doesn't do that in this
particular case -- but there may have been some reason. Matthew?
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
