AcpiSupportDeprecation
Launchpad Entry: foo
Created: 2009-02-09
Contributors: MartinPitt
Packages affected: acpi-support, pm-utils
Summary
acpi-support is a Debian/Ubuntu specific package which duplicates a lot of functionality from hal, hal-info, and pm-utils. We evaluate its current status and provide a migration path.
This specification specifically ignores hotkey handling, which is already covered in ubuntu-hotkey-madness.
Release Note
(TBD when this starts to get implemented)
Rationale
hal-info and pm-utils are used in many other distributions, and thus are better maintained and cover much more hardware. Also, there are cases where the same event gets handled twice (once through hal and once through acpi-support), which potentially (and actually) causes bugs.
Design
As of version 0.119, the following functionality is still present in acpi-support:
ACPI event handling
Handling in acpi-support
An ACPI event, such as "hotkey ATKD 0000009b", is matched against patterns in /etc/acpi/events/*; if an "event=" pattern matches, the "action=" script is called, which runs the necessary scripts, etc. to handle this event properly.
The scripts are in /etc/acpi/*.sh.
Handling upstream
This is not currently handled in hal (or anywhere else) at all.
Migration
hal-addon-acpi currently only handles a very limited set of ACPI events (button, ac_adapter, battery).
For now we should keep this portion of acpi-support, and start discussing the long-term approach on the upstream hal mailing list. We could integrate the acpid functionality into hal-addon-acpi to save an extra daemon, but that should happen with upstream's consent. Also, hal itself is in maintenance mode and will eventually be deprecated by DeviceKit and its various modules.
acpid
This is a dependency of acpi-support, not shipped by it. acpid is a multiplexer for /proc/acpi/event: it matches ACPI events against the rules in /etc/acpi/events/, and replicates them to /var/run/acpid.socket, where hal etc. can read them from.
We need acpid as long as acpi-support still ships scripts in /etc/acpi/events/ and there isn't anything else (such as an improved hal-addon-acpi) which calls those scripts.
VBE state save/restore
Handling in acpi-support
/etc/init.d/vbesave uses vbetool to save the video bios state at boot, and resume.d/17-video-restore.sh restores it again on resuming (enabled by default in /etc/default/acpi-support).
acpi-support also supports saving (suspend.d/80-video-pci-state.sh) and restoring (resume.d/17-video-restore.sh) the video PCI state, but this is disabled by default in /etc/default/acpi-support.
Handling upstream
hal-info's laptop quirks has the precise set of quirks which are needed for suspend/resume, which include this functionality. /usr/share/hal/fdi/information/10freedesktop/99-video-quirk-default.fdi sets a set of default quirks (including VBE save/restore) for unknown laptops.
Migration
This functionality should be dropped entirely, since it is already handled in pm-utils and hal-info.
Remove:
- /etc/init.d/vbesave
- /etc/acpi/suspend.d/80-video-pci-state.sh
- /etc/acpi/suspend.d/80-video-vesa-state.sh
- /etc/acpi/resume.d/17-video-restore.sh
Test/Demo Plan
TBD