Hi Bart, On Sun, Mar 16, 2008 at 02:47:34PM +0100, Bart Samwel wrote:
> I wouldn't mind removing the suspend/hibernate stuff from acpi-support > though, if there is consensus that this should be handled by pm-utils or > some other framework. In that case I'll just rip the whole thing out. What > I'll have to keep is the stuff that handles suspend/hibernate keys, I've just been discussing this with Matthew Garrett this weekend, about 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. > 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? > 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? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
