Op Thu, 28 Sep 2006 00:00:28 +0100 schreef Stephen Gran <[EMAIL PROTECTED]>:
> Not that I actually object to the package, but why can't HAL let acpid > manage acpi events? I am continually confused by the profusion of > packages that offer to work around acpid in order to provide the > functionality it could and should be providing. Note that this package is not really related to acpid, but I'll try to answer anyway. Acpid is just another deamon listening to /proc/acpi/event. It doesn't have a good way of communicating with a user. HAL is also able to listen to acpi events (by listening to /proc/acpi/event or acpid). The advantage HAL has over acpid, is that it is very well integrated in to the users (kde or gnome) session. That way it is able to notify the user (he, your battery is low!) get user feedback (should I suspend to ram, to disk?) and act on user configuration (suspend to ram when closing the lid, but only when on AC, else suspend to disk). Now acpid has technically nothing to do with bringing the machine in a sleep state. For that to work you have basically three options: 1) Patch your kernel with suspend2 2) Use swsusp build in kernel 3) Use uswsusp which is partly in kernel, partly user space. I think that with the profusion of packages you talk about are the packages (like pm-utils) the try to work around bugs in drivers and offer functionality before and after the actual sleep. Things like syncing the clock, stopping services, networks, fixing the state of the graphics card. I hope this clears it up a bit grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
