Difference between revisions of "Talk:Laptop"

From ArchWiki
Jump to: navigation, search
(Suggestions for saving power: Close.)
(RUN+="" won't work reliably)
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== <s> 2.8 Suggestions for saving power </s> ==
+
==Udev Rule to Suspend System==
All of these are applied/can be applied by laptopmode. I added a little note about it, but it's not enough. Some of the values are different from those applied by the default laptopmode config.
+
The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:
Redundant/could create issues. [[User:UNIVAC|UNIVAC]] 23:00, 24 September 2009 (EDT)
+
## SLEEP IF BATTERY IS LOW
 +
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", <s>ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend</s> RUN+="/script/to/poll/battery/and/suspend/system.sh"
 +
There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes). I have not tested this on my own system yet or figured out just how that file works yet. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 23:32, 3 March 2013 (UTC)
  
==Other tweaks ==
+
:Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.
No explanations with these tweaks? What do these do? Is linking to the source enough or should we describe what we're doing in detail? I'm never too comfortable with "do this" type instructions without a "this is why" explanations.--[[User:Multiphrenic|Multiphrenic]] 09:05, 27 April 2011 (EDT)
+
:--[[User:Eruditorum|Eruditorum]] ([[User talk:Eruditorum|talk]]) 06:48, 30 March 2013 (UTC)
  
==<s> Suggestions for saving power </s>==
+
::Hmm... Well, if it works for you, then it must be something peculiar with my specific system.  In which case, yes, polling would be a needless complication. I'll have to give it a look and see what the dillyo is. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 05:58, 16 May 2013 (UTC)
I'd add a a little script for turning off the wlan-Hardware when not connected at startup...if not turned off, the wlan-Hardware will go on searching for an AP to connect to, although there might be no potential AP at all, thus wasting power.  
+
I regularly forgot to disable it when en route, having to save power without any need of my wlan - it may not be too much power to save, but it's also a very simple little script to execute at startup (maybe with a sleep of 60s) to save it:
+
+
#!/bin/bash
+
+
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"
+
if [ "$essid" == "ESSID:off/any" ] ; then
+
sudo iwconfig wlan0 txpower off
+
fi
+
  
--[[User:Wysiwyg|Wysiwyg]] 11:20, 12 June 2011 (EDT)
+
:::On my system, acpi sends only adapter online/offline events, no ''changed-battery-level'', so the only solution is a daemon polling the battery level every minute or so... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:42, 6 June 2013 (UTC)
  
:If it works for you it could be useful also for others, add it under Suggestions for saving power. -- [[User:Kynikos|Kynikos]] 09:29, 13 June 2011 (EDT)
+
== RUN+="<command>" won't work reliably ==
:: Already added. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:12, 20 February 2013 (UTC)
+
  
== <s> BatteryMon requires "hal" wich is unsupported </s> ==
+
In the example:
  
Should it be changed or not?
+
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki>
Are there other suggestion for battery monitor applets?
+
# Suspend the system when battery level drops to 2%
--[[User:Ahel|Ahel]] 10:52, 22 November 2011 (EST)Ahel
+
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"
 +
</nowiki>}}
  
: In fact, the article mentiones "{{AUR|batterymon}} which can be found in the [[Arch User Repository|AUR]]" which seem to no longer exist in the AUR. Perhaps this reference should be removed --[[User:Mloskot|Mloskot]] ([[User talk:Mloskot|talk]]) 23:02, 17 June 2012 (UTC)
+
{{bc|<nowiki>
:: Fixed. Close. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 06:05, 20 February 2013 (UTC)
+
RUN
 +
...
 +
Starting daemons or other long running processes is not appropriate for
 +
udev; the forked processes, detached or not, will be unconditionally killed
 +
after the event handling has finished.
 +
</nowiki>}}
 +
 
 +
There's no garantee that systemctl will finish execution. Its possible to use {{ic|ENV{SYSTEMD_WANTS}&#61;"systemd-suspend.service"}} but I have not personally tested this. All these udev rules should be reworked to trigger one-shot systemd services ideally, which also brings along all the benefits of have systemd units (logging, debugging, etc).
 +
 
 +
-- [[User:Simongmzlj|Simongmzlj]]
 +
 
 +
:First of all, {{ic|1=RUN+=}} is not deprecated. Missing features do not predicate deprecation. I've removed the accuracy note from the page: [https://wiki.archlinux.org/index.php?title=Laptop&diff=276707&oldid=276704].
 +
:The {{ic|1=ENV{SYSTEMD_WANTS}="suspend.target"}} should be used ideally, but it has to be combined with {{ic|1=TAG+="systemd"}}.
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:38, 26 September 2013 (UTC)
 +
 
 +
::Isn't the point that systemctl may not finish executing - certainly may not finish quickly enough for udev's liking? It is a matter of what is suitable in a udev rule due to the nature of udev. --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 01:47, 8 November 2013 (UTC)

Revision as of 01:47, 8 November 2013

Udev Rule to Suspend System

The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:

## SLEEP IF BATTERY IS LOW
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend RUN+="/script/to/poll/battery/and/suspend/system.sh"

There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes). I have not tested this on my own system yet or figured out just how that file works yet. Ego.abyssi (talk) 23:32, 3 March 2013 (UTC)

Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.
--Eruditorum (talk) 06:48, 30 March 2013 (UTC)
Hmm... Well, if it works for you, then it must be something peculiar with my specific system. In which case, yes, polling would be a needless complication. I'll have to give it a look and see what the dillyo is. Ego.abyssi (talk) 05:58, 16 May 2013 (UTC)
On my system, acpi sends only adapter online/offline events, no changed-battery-level, so the only solution is a daemon polling the battery level every minute or so... -- Lahwaacz (talk) 16:42, 6 June 2013 (UTC)

RUN+="<command>" won't work reliably

In the example:

/etc/udev/rules.d/lowbat.rules
# Suspend the system when battery level drops to 2%
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"
RUN
...
Starting daemons or other long running processes is not appropriate for
udev; the forked processes, detached or not, will be unconditionally killed
after the event handling has finished.

There's no garantee that systemctl will finish execution. Its possible to use ENV{SYSTEMD_WANTS}="systemd-suspend.service" but I have not personally tested this. All these udev rules should be reworked to trigger one-shot systemd services ideally, which also brings along all the benefits of have systemd units (logging, debugging, etc).

-- Simongmzlj

First of all, RUN+= is not deprecated. Missing features do not predicate deprecation. I've removed the accuracy note from the page: [1].
The ENV{SYSTEMD_WANTS}="suspend.target" should be used ideally, but it has to be combined with TAG+="systemd".
-- Lahwaacz (talk) 19:38, 26 September 2013 (UTC)
Isn't the point that systemctl may not finish executing - certainly may not finish quickly enough for udev's liking? It is a matter of what is suitable in a udev rule due to the nature of udev. --cfr (talk) 01:47, 8 November 2013 (UTC)