Portál AbcLinuxu, 2. května 2025 07:21
Aneb vše co jste vždy chtěli od ACPI na notebooku ale byli jste líní si to nastavit.
Pokuď nepoužíváte některou z "user friendly" distribucí, pravděpodobně Váš systém po instalaci neumí mnoho zdánlivě samozřejmých věcí jako přechod do úsporného režimu při odpojení od napájení, zapnutí výstupu na externí monitor nebo uspání po zavření displaye. Následující pojednání je o tom, jak toto napravit a jaké nepříjemnosti Vás při tom můžou potkat.
je standard tvořící rozhraní mezi HW a OS v oblasti power managementu a konfigurace. "Obsluhuje" všelijaké systémové události jako jsou změny stavu konfiguračních tlačítek, napájení nebo odpojení/připojení zařízení na některých vstupech/výstupech počítače.
je démon reagující na ACPI události. Jeho hlavní pracobní náplní je
provádět uživatelem definované akce při různých ACPI událostích. Konfigurace
daemona se provádí pomocí konfiguračních souborů v adresáři
/etc/acpi/events
. Každý soubor v adresáři definuje obvykle akci
pro jeden typ ACPI události a jeho struktura je následující:
event=puvodce_udalosti action=program_pro_obsluhu_udalosti %e
Za puvodce_udalosti
je možné dosadit cokoliv co váš systém
nabízí v adresáři /proc/acpi
a to nejenom absolutně, ale i ve
formě regulárního výrazu. To umožňuje nestarat se o jednotlivé instance
zařízení a provést akci pro celou rodinu zařízení. Pokud tedy chcete reagovat
například na "akci baterie", nemusíte udávat, že chcete baterii C1BB -
batery/C1BB
ale pomocí batery.*
lze reagovat na
události z libovolné systémem sledované baterie.
program_pro_obsluhu_udalosti
pak udává program, většinou shell
script, který se má při dané ACPI události spustit. %e
je ACPI
daemonem nahrazeno za "textový popis události" což v překladu znamená doplňující
informace k události (jedná-li se o vypnutí nebo zapnutí tlačítka, která
konkrétní instance zařízení akci vyvolala atd.). Jaký konkrétní údaj pro
konkrétní akci acpid posílá lze "vykoukat" z jeho logu
(/var/log/acpid
). "Obslužné" programy jsou spouštěny pod uživatelem,
pod kterým běží acpid, což je standardně root.
Všechny níže uvedené příklady jsou napsány konkrétně pro HP nx6310, ale měly by být poměrně univerzální...
/etc/acpi/events/lid
:
event=button/lid action=/etc/acpi/lid.sh %e
/etc/acpi/lid.sh
:
#!/bin/sh # if LID pressed (Display closed) suspend, else exit grep -q open /proc/acpi/button/lid/C238/state && exit # suspend CONSOLE=`fgconsole` chvt 12 echo mem > /sys/power/state # resume vbetool post chvt $CONSOLE
Poznámky: Suspend script kde není, kromě obnovení stavu VGA, nutné při uspávání/probouzení provádět žádná další kouzla. Porovnejte s s2ram či hibernate...
/etc/acpi/events/ac_adapter
:
event=ac_adapter.* action=/etc/acpi/ac_adapter.sh %e
/etc/acpi/ac_adapter.sh
:
#!/bin/sh if [ $4 -eq 0 ]; then cpufreq-set -g conservative else cpufreq-set -g performance fi
Poznámky: Parametr $4 udává zda se jedná o připojení/odpojení.
/etc/acpi/events/video
:
event=video.* action=/etc/acpi/video.sh %e
/etc/acpi/video.sh
:
#!/bin/sh export DISPLAY=:0 XRANDR=`xrandr` if echo "$XRANDR" | grep -E 'VGA connected [0-9]+' > /dev/null ; then # VGA connected and active, turn it off xrandr --output VGA --off elif echo "$XRANDR" | grep -E 'VGA connected' > /dev/null ; then # VGA connected but not active, turn it on xrandr --output VGA --auto --same-as LVDS fi
Poznámky: xrandr
musí být standardně spouštěn pod
vlastníkem displaye, proto je nutné mít ve startovacích scriptech X serveru
(například .xinitrc
) nastaven přístup k displayi pro roota:
xhost +local:root
.
Příklady jsou jak vidno opravdu jednoduché a přímočaré. Jistě by šlo napsat mnohem "univerzálnější" skripty, ale pokuď takové chcete, je nesmyslné mít distribuci, která je již neobsahuje. Používáte-li na svém systému nějaký další zajímavý a použitelný acpid script, podělte se v diskuzi
Tiskni
Sdílej:
radeontool light on
Něco mi říká, že radeontool na grafické kartě od intelu fungovat nebude...
zkusil bych:
xset dpms force off
a když to display vypne (což by mělo), tak bych to "namapoval" na LID tlačítko. Pokuď ti display něco nechtěně opět zapíná, může to bejt třeba špatně fungující myš (nebo lokální zemětřesení )
vbetool
? Na vypnuti by melo fungovat vbetool dpms off
a na opetovne zapnuti vbetool dpms on
.
Dík, já mam zatim za vzor snad kompletní acpid skript, všechno jsem neměl ještě čas ověřovat u sebe. Základ mi maká.
I kdyby nee, máte aspoň mustr, jak by to mohlo vypadat, doplňte si svůj modul a je to?
Pochop, že tohle neni článek pro uživatele OpenSUSE (Ubuntu, Mandrivy, ...). Pokuď se nechci o svůj systém zajímat, nainstaluju si některou takovou distribuci a doufám, že její autoři všechny tyhle "drobnosti" pořešili. Tohle je pro lidi, co chtěj vědět co přesně se v jejich systému děje (který hardware má se suspendem problémy a jak je obejít) a chtějí si to nastavit přesně sobě na míru.
Konec konců s2ram je v zápisku zmíněno jako kanón na vrabce, v případě že máte "do it yourself"® distribuci.
Protože s2ram obsahuje hacky pro všechny myslitelný chyby HW/ovladačů/systému, tedy i ty co se mě vůbec netýkají. A pomáhat projektům jako je s2ram opravdu nemínim, protože to je akorát cesta do pekel. Problémy se MUSÍ řešit v ovladačích zařízení/kernelu, tak aby žádný s2ram nebylo potřeba a k uspání stačilo prosté echo mem > /sys/power/state
.
Problémy se MUSÍ řešit v ovladačích zařízení/kernelu, tak aby žádný s2ram nebylo potřeba a k uspání stačilo prosté echo mem > /sys/power/state
.
Možná bys potom mohl poradit Pavlu Machkovi, jak to MUSÍ dělat. Z tvojí reakce se zdá, že o toho kernelu a problémech spojených s uspáváním moc neví ... Tvé logické pochody jsou vskutu nadmíru zajímavé...
Pavel Machek těžko sám opraví všechny "vadné" drivery, a proto, že v současné době se distribuce jako je SUSE bez něčeho takového neobejde, píše kromě "kernel věcí" i s2ram. Z jeho příspěvků do mailinglistů a přednášek nicméně nemám pocit, že by si myslel, že s2ram je skutečné řešení problému...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.