AcpiSupportDeprecation
Launchpad Entry: acpi-support-deprecation
Created: 2009-02-09
Contributors: MartinPitt
Packages affected: acpi-support, pm-utils, hal-info, gnome-power-manager
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:
Hardware specific 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).
Eventually, all those ACPI hotkey events need to be converted to input events in the kernel, as it already happens with most keys and laptops today. The remaining missing bits are just about impossible to know without testing, so we should just disable it and send out a call for testing/filing bugs.
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
Dropped in Jaunty
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; some quirks (*.config) enable this mode, though.
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
- VBESTATE, POST_VIDEO, SAVE_VIDEO_PCI_STATE from /etc/default/acpi-support
Suspend quirks
Dropped in Jaunty
/etc/acpi/start.d/10-save-dmidecode.sh reads (and caches) the manufacturer from dmidecode --string system-manufacturer, and sources /usr/share/acpi-support/$manufacturer.config file.
These files define quirks necessary for suspend/resume.
Handling in acpi-support
The .config files define a whitelist of which laptops support sleep (ACPI_SLEEP=true) and some additional quirks (e. g. SAVE_VBE_STATE=true).
Handling upstream
hal-info maintains quirks in /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-*.fdi, also based on system vendor/product/manufacturer (read from hal, which in turn uses dmidecode as well).
There is no general whitelist of models which support suspend/resume.
Migration
gnome-power-manager's postinst script currently checks whether ACPI_SLEEP==true (by some .config script) and sets some default gconf keys to enable suspend by default and disable the suspend warning. However, these gconf keys are long obsolete and are not evaluated at all any more.
ACPI_SLEEP should be dropped in general, since with recent kernels and hal-info, suspend/resume should work on a large number of machines which aren't explicitly mentioned in acpi-support, and gnome-power-manager does not pay attention to acpi-support any more anyway.
The quirks in the .config files need to be translated into hal-info FDIs.
/etc/acpi/{battery,ac.d}
These scripts are run when the AC adapter is pulled out/plugged in.
battery.d/15-anacron.sh and ac.d/85-anacron are redundant: they are already handled by /usr/lib/pm-utils/power.d/anacron, which the anacron package ships itself.
90-hdparm should be translated to a /usr/lib/pm-utils/power.d/ script, and put into the hdparm or pm-utils package.
/etc/acpi/{suspend,resume}.d
These scripts are run on suspend/resume keys if acpi-support handles suspend/resume by itself. Note that this is not the case if GNOME or KDE are running, so on a desktop installation they do not do anything.
The scripts should be reviewed for useful things, and be translated to scripts in /usr/lib/pm-utils/sleep.d/, so that they get handled by pm-utils. Some are obsolete/redundant, e. g. suspend.d/15-anacron.sh is already handled by /usr/lib/pm-utils/sleep.d/95anacron (which the anacron package ships itself).
The new scripts should be added to pm-utils, unless they are package specific, and sent to upstream for adoption.
/etc/init.d/acpi-support
This script currently runs /etc/acpi/battery.d/* or /etc/acpi/ac.d/* (depending on whether an AC adapter is present), and additionally /etc/acpi/start.d/*. The init script can be dropped once all those files get eliminated (by considering them deprecated, or moving their functionality to other parts).
start.d currently has:
10-save-dmidecode.sh: Gets system vendor/product name from dmidecode, caches it, makes it available in the DeviceConfig() function. These values are currently used in *.config (suspend quirks) and one event script (asus-brn-up.sh). This can go once these files go by moving their quirks to hal-info.
- 90-hdparm.sh: This is identical to {battery,ac.d}/90-hdparm.sh. Ensure that hal checks AC state on startup and executes the 10-power-mgmt-policy.fdi rules on startup.
60-asus-wireless-led.sh: Fixes the wireless LED state on Asus laptops. TODO: test whether this is still necessary, find replacement. If not, move this call into the init script directly, to drop the other machinery.
/etc/modprobe.d/toshiba_acpi.modprobe
Dropped in Hardy This sets the option "hotkeys_over_acpi=1" for the "toshiba_acpi" module.
TODO: It is currently unknown what the default value does; if it sends the events as hotkeys, then the file should be dropped, and hal-info's Toshiba keymap rules should be tested/extended if needed. If it does something else, and we need to retain the option, then it should just be made the default in our kernel, or the file could move to module-init-tools.
/etc/default/acpi-support
We have the following settings by default:
SUSPEND_METHODS: Defaults to dbus-pm and dbus-hal, which is what gnome-power-manager, KDE, etc. use as well. Also, this value is not used anywhere in acpid, acpi-support, or any other package, thus it is a dead variable which should just be eliminated.
- Some variables for the legacy built-in suspend support: this mode is already deprecated
So the entire file can just be dropped as soon as acpi-support internal suspend/resume handling should stop being supported.
Common code
These files in /usr/share/acpi-support/ are common code, used by the other scripts:
- device-funcs
- policy-funcs
- power-funcs
- screenblank
- state-funcs
- key-constants
They can be eliminated along with above parts, but are otherwise harmless.
Test/Demo Plan
TBD
AcpiSupportDeprecation (last edited 2009-06-15 08:58:19 by pD9EB7971)