Ubuntu Wiki

• 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}

Being Worked On

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

Dropped in Karmic

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

Unresolved issues

• Upstream counterpart of /etc/acpi/events/ (see above)

CategorySpec