https://wiki.archlinux.org/api.php?action=feedcontributions&user=Calestyo&feedformat=atomArchWiki - User contributions [en]2024-03-28T15:11:38ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd/Timers&diff=783783Systemd/Timers2023-07-28T02:03:37Z<p>Calestyo: document how to set OnFailure for ALL units of a giventype</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:System administration]]<br />
[[de:Systemd/Timers]]<br />
[[es:Systemd (Español)/Timers]]<br />
[[fr:Systemd (Français)/Timers]]<br />
[[ja:Systemd/タイマー]]<br />
[[pt:Systemd (Português)/Timers]]<br />
[[ru:Systemd (Русский)/Timers]]<br />
[[zh-hans:Systemd/Timers]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd/User}}<br />
{{Related|systemd FAQ}}<br />
{{Related|cron}}<br />
{{Related articles end}}<br />
<br />
Timers are [[systemd]] unit files whose name ends in ''.timer'' that control ''.service'' files or events. Timers can be used as an alternative to [[cron]] (read [[#As a cron replacement]]). Timers have built-in support for calendar time events, monotonic time events, and can be run asynchronously.<br />
<br />
== Timer units ==<br />
<br />
Timers are ''systemd'' unit files with a suffix of ''.timer''. Timers are like other [[systemd#Writing unit files|unit configuration files]] and are loaded from the same paths but include a {{ic|[Timer]}} section which defines when and how the timer activates. Timers are defined as one of two types:<br />
<br />
* '''Realtime timers''' (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option {{ic|OnCalendar{{=}}}} is used to define them.<br />
* '''Monotonic timers''' activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: {{ic|On''Type''Sec{{=}}}}. Common monotonic timers include {{ic|OnBootSec}} and {{ic|OnUnitActiveSec}}.<br />
<br />
For a full explanation of timer options, see the {{man|5|systemd.timer}}. The argument syntax for calendar events and time spans is defined in {{man|7|systemd.time}}.<br />
<br />
{{Note|''systemd'' offers the target {{ic|timers.target}} which sets up all timers that should be active after boot (see {{man|7|systemd.special}} for details). To use it, add {{ic|WantedBy{{=}}timers.target}} to the {{ic|[Install]}} section of your timer and [[enable]] the timer unit.}}<br />
<br />
== Service units ==<br />
<br />
For each ''.timer'' file, a matching ''.service'' file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}). The ''.timer'' file activates and controls the ''.service'' file. The ''.service'' does not require an {{ic|[Install]}} section as it is the ''timer'' units that are enabled. If necessary, it is possible to control a differently-named unit using the {{ic|Unit{{=}}}} option in the timer's {{ic|[Timer]}} section.<br />
<br />
== Management ==<br />
<br />
To use a ''timer'' unit [[enable]] and [[start]] it like any other unit (remember to add the ''.timer'' suffix). To view all started timers, run:<br />
<br />
{{hc|$ systemctl list-timers|<br />
NEXT LEFT LAST PASSED UNIT ACTIVATES<br />
Thu 2014-07-10 19:37:03 CEST 11h left Wed 2014-07-09 19:37:03 CEST 12h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service<br />
Fri 2014-07-11 00:00:00 CEST 15h left Thu 2014-07-10 00:00:13 CEST 8h ago logrotate.timer logrotate.service<br />
}}<br />
<br />
{{Note|<br />
* To list all timers (including inactive), use {{ic|systemctl list-timers --all}}.<br />
* The status of a service started by a timer will likely be inactive unless it is currently being triggered.<br />
* If a timer gets out of sync, it may help to delete its {{ic|stamp-*}} file in {{ic|/var/lib/systemd/timers}} (or {{ic|~/.local/share/systemd/}} in case of user timers). These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.}}<br />
<br />
== Examples ==<br />
<br />
A service unit file can be scheduled with a timer out-of-the-box. The following examples schedule {{ic|foo.service}} to be run with a corresponding timer called {{ic|foo.timer}}.<br />
<br />
=== Monotonic timer ===<br />
<br />
A timer which will start 15 minutes after boot and again every week while the system is running.<br />
<br />
{{hc|/etc/systemd/system/foo.timer|<nowiki><br />
[Unit]<br />
Description=Run foo weekly and on boot<br />
<br />
[Timer]<br />
OnBootSec=15min<br />
OnUnitActiveSec=1w<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
</nowiki>}}<br />
<br />
=== Realtime timer ===<br />
<br />
A timer which starts once a week (at 12:00am on Monday). When activated, it triggers the service immediately if it missed the last start time (option {{ic|Persistent{{=}}true}}), for example due to the system being powered off:<br />
<br />
{{hc|/etc/systemd/system/foo.timer|2=<br />
[Unit]<br />
Description=Run foo weekly<br />
<br />
[Timer]<br />
OnCalendar=weekly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
}}<br />
<br />
When more specific dates and times are required, {{ic|OnCalendar}} events uses the following format:<br />
<br />
DayOfWeek Year-Month-Day Hour:Minute:Second<br />
<br />
An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by {{ic|..}} indicate a contiguous range.<br />
<br />
In the below example the service is run the first four days of each month at 12:00 PM, but ''only'' if that day is a Monday or a Tuesday.<br />
<br />
OnCalendar=Mon,Tue *-*-01..04 12:00:00<br />
<br />
To run a service on the first Saturday of every month, use:<br />
<br />
OnCalendar=Sat *-*-1..7 18:00:00<br />
<br />
When using the {{ic|DayOfWeek}} part, at least one weekday has to be specified. If you want something to run every day at 4am, use:<br />
<br />
OnCalendar=*-*-* 4:00:00<br />
<br />
To run a service at different times, {{ic|OnCalendar}} may be specified more than once. In the example below, the service runs at 22:30 on weekdays and at 20:00 on weekends.<br />
<br />
OnCalendar=Mon..Fri 22:30<br />
OnCalendar=Sat,Sun 20:00<br />
<br />
More information is available in {{man|7|systemd.time}}.<br />
<br />
{{Tip|<br />
*{{ic|OnCalendar}} time specifications can be tested in order to verify their validity and to calculate the next time the condition would elapse when used on a timer unit file with the {{ic|calendar}} option of the ''systemd-analyze'' utility. For example, one can use {{ic|systemd-analyze calendar weekly}} or {{ic|systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00"}}.<br />
*The {{ic|faketime}} command is especially useful to test various scenarios with the above command; it comes with the {{Pkg|libfaketime}} package.<br />
*Special event expressions like {{ic|daily}} and {{ic|weekly}} refer to ''specific start times'' and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources. The {{ic|RandomizedDelaySec}} option in the {{ic|[Timer]}} section avoids this problem by randomly staggering the start time of each timer. See {{man|5|systemd.timer}}.<br />
*Add the option {{ic|AccuracySec{{=}}1us}} to the {{ic|[Timer]}} section, to avoid the inaccuracy of the ''1m'' default value of {{ic|AccuracySec}}. Also see {{man|5|systemd.timer}}.<br />
}}<br />
<br />
== Transient timer units ==<br />
<br />
One can use {{ic|systemd-run}} to create transient ''.timer'' units. That is, one can set a command to run at a specified time without having a service file. For example the following command touches a file after 30 seconds:<br />
<br />
# systemd-run --on-active=30 /bin/touch /tmp/foo<br />
<br />
One can also specify a pre-existing service file that does not have a timer file. For example, the following starts the systemd unit named {{ic|''someunit''.service}} after 12.5 hours have elapsed:<br />
<br />
# systemd-run --on-active="12h 30m" --unit ''someunit''.service<br />
<br />
See {{man|1|systemd-run}} for more information and examples.<br />
<br />
== As a cron replacement ==<br />
<br />
Although [[cron]] is arguably the most well-known job scheduler, ''systemd'' timers can be an alternative.<br />
<br />
=== Benefits ===<br />
<br />
The main benefits of using timers come from each job having its own ''systemd'' service. Some of these benefits are:<br />
<br />
* Jobs can be easily started independently of their timers. This simplifies debugging.<br />
* Each job can be configured to run in a specific environment (see {{man|5|systemd.exec}}).<br />
* Jobs can be attached to [[cgroups]].<br />
* Jobs can be set up to depend on other ''systemd'' units.<br />
* Jobs are logged in the ''systemd'' journal for easy debugging.<br />
<br />
=== Caveats ===<br />
<br />
Some things that are easy to do with cron are difficult to do with timer units alone:<br />
<br />
* Creation: to set up a timed job with ''systemd'' you need to create two files and run {{ic|systemctl}} commands, compared to adding a single line to a crontab.<br />
* Emails: there is no built-in equivalent to cron's {{ic|MAILTO}} for sending emails on job failure. See the next section for an example of setting up a similar functionality using {{ic|OnFailure{{=}}}}.<br />
<br />
Also note that [[systemd/User|user]] timer units will only run during an active user login session by default. However, [[Systemd/User#Automatic start-up of systemd user instances|lingering]] can enable services to run at boot even when the user has no active login session.<br />
<br />
=== MAILTO ===<br />
<br />
You can set up systemd to send an e-mail when a unit fails. Cron sends mail to {{ic|MAILTO}} if the job outputs to stdout or stderr, but many jobs are setup to only output on error. First you need two files: an executable for sending the mail and a ''.service'' for starting the executable. For this example, the executable is just a shell script using {{ic|sendmail}}, which is in packages that provide {{ic|smtp-forwarder}}.<br />
<br />
{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/sh<br />
<br />
/usr/bin/sendmail -t <<ERRMAIL<br />
To: $1<br />
From: systemd <root@$HOSTNAME><br />
Subject: $2<br />
Content-Transfer-Encoding: 8bit<br />
Content-Type: text/plain; charset=UTF-8<br />
<br />
$(systemctl status --full "$2")<br />
ERRMAIL</nowiki>}}<br />
<br />
Whatever executable you use, it should probably take at least two arguments as this shell script does: the address to send to and the unit file to get the status of. The ''.service'' we create will pass these arguments:<br />
<br />
{{hc|/etc/systemd/system/status_email_''user''@.service|2=[Unit]<br />
Description=status email for %i to ''user''<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/local/bin/systemd-email ''address'' %i<br />
User=nobody<br />
Group=systemd-journal}}<br />
<br />
Where {{ic|''user''}} is the user being emailed and {{ic|''address''}} is that user's email address. Although the recipient is hard-coded, the unit file to report on is passed as an instance parameter, so this one service can send email for many other units. At this point you can [[start]] {{ic|status_email_''user''@dbus.service}} to verify that you can receive the emails.<br />
<br />
Then simply [[edit]] the service you want emails for and add {{ic|OnFailure{{=}}status_email_''user''@%n.service}} to the {{ic|[Unit]}} section. {{ic|%n}} passes the unit's name to the template.<br />
<br />
{{Note|<br />
* If you set up sSMTP security according to [[sSMTP#Security]] the user {{ic|nobody}} will not have access to {{ic|/etc/ssmtp/ssmtp.conf}}, and the {{ic|systemctl start status_email_''user''@dbus.service}} command will fail. One solution is to use {{ic|root}} as the User in the {{ic|status_email_''user''@.service}} unit.<br />
* If you try to use {{ic|mail -s somelogs ''address''}} in your email script, {{ic|mail}} will fork and systemd will kill the mail process when it sees your script exit. Make the mail non-forking by doing {{ic|mail -Ssendwait -s somelogs ''address''}}.<br />
}}<br />
<br />
Alternatively, for very simple cases, one could also put the shell script that sends the code directly within the unit file like in:<br />
{{hc|/etc/systemd/system/status_email_''user''@.service|2=[Service]<br />
Type=oneshot<br />
ExecStart=@sh %n:sh -c 'systemctl status --full --lines "$1" {{!}} mail -s "$2: systemd unit $1 $(systemctl --value --property=ActiveState show "$1")" root' %n:sh %i %H}}<br />
<br />
Note that systemd also allows to set top level per-type drop-ins, to change some aspect of '''all''' units of a given type (e.g. {{ic|service}}) by creating a file like {{ic|/etc/systemd/system/service.d/someName.conf}}, which could set {{ic|OnFailure}} for e.g. '''all''' services.<br />
<br />
=== Using a crontab ===<br />
<br />
Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers, like {{AUR|systemd-cron}}. It can provide the missing {{ic|MAILTO}} feature.<br />
<br />
Also, like with crontabs, a unified view of all scheduled jobs can be obtained with {{ic|systemctl}}. See [[#Management]].<br />
<br />
=== Manually ===<br />
<br />
Outside of migrating from an existing crontab, using the same periodicity as cron can be desired. To avoid the tedious task of creating a timer for each service to start periodically, use a [[Systemd#Using units|template unit]], for example: <br />
<br />
{{hc|/etc/systemd/system/monthly@.timer|2=<br />
[Unit]<br />
Description=Monthly Timer for %i service<br />
<br />
[Timer]<br />
OnCalendar=*-*-1 02:00:00<br />
AccuracySec=6h<br />
RandomizedDelaySec=1h<br />
Persistent=true<br />
Unit=%i.service<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|See {{man|5|systemd.timer|OPTIONS}} for the importance of using {{ic|RandomizedDelaySec}} and not only {{ic|AccuracySec}} to avoid all units started by the timer firing at once.}}<br />
<br />
Then one only needs to [[enable/start]] {{ic|monthly@''unit_name''.timer}}.<br />
<br />
{{Tip|The template units can be nested, e.g. one could [[enable/start]] {{ic|monthly@btrfs-scrub@mnt-$(systemd-escape bbb76c63-e4ac-4e39-8897-a120c5d30686).timer}}.}}<br />
<br />
== Handling "time to live" ==<br />
<br />
Some software will track the time elapsed since they last ran, for example blocking the update of a database if the last download ended less than 24 hours ago. <br />
<br />
By default, timers do not track when the task they launched has ended. To work around this, we can use {{ic|OnUnitInactiveSeconds}}: <br />
<br />
{{hc|/etc/systemd/system/daily-inactive@.timer|2=<br />
[Unit]<br />
Description=Launch %i service 24hours after it deactivated<br />
<br />
[Timer]<br />
'''OnUnitInactiveSec=1day1sec'''<br />
Unit=%i.service<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Tip|With {{ic|1=Restart=on-failure}} along with {{ic|RestartSec}}, it is possible<br />
to have a unit rerun after failure and success according to different schedules, see {{man|5|systemd.service|OPTIONS}}.}}<br />
<br />
== See also ==<br />
<br />
* {{man|5|systemd.timer}}<br />
* [[Fedora:Features/SystemdCalendarTimers]]<br />
* [[Gentoo:Systemd#Timer services]]<br />
* {{App|systemd-cron|provides systemd units to run cron scripts; using ''systemd-crontab-generator'' to convert crontabs|https://github.com/systemd-cron/systemd-cron|{{AUR|systemd-cron}}}}<br />
* [https://fedoramagazine.org/systemd-timers-for-scheduling-tasks/ Systemd Timers for Scheduling Tasks]</div>Calestyohttps://wiki.archlinux.org/index.php?title=Systemd/Timers&diff=783781Systemd/Timers2023-07-28T01:43:26Z<p>Calestyo: added alternative unit that doesn't need an extra file</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:System administration]]<br />
[[de:Systemd/Timers]]<br />
[[es:Systemd (Español)/Timers]]<br />
[[fr:Systemd (Français)/Timers]]<br />
[[ja:Systemd/タイマー]]<br />
[[pt:Systemd (Português)/Timers]]<br />
[[ru:Systemd (Русский)/Timers]]<br />
[[zh-hans:Systemd/Timers]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd/User}}<br />
{{Related|systemd FAQ}}<br />
{{Related|cron}}<br />
{{Related articles end}}<br />
<br />
Timers are [[systemd]] unit files whose name ends in ''.timer'' that control ''.service'' files or events. Timers can be used as an alternative to [[cron]] (read [[#As a cron replacement]]). Timers have built-in support for calendar time events, monotonic time events, and can be run asynchronously.<br />
<br />
== Timer units ==<br />
<br />
Timers are ''systemd'' unit files with a suffix of ''.timer''. Timers are like other [[systemd#Writing unit files|unit configuration files]] and are loaded from the same paths but include a {{ic|[Timer]}} section which defines when and how the timer activates. Timers are defined as one of two types:<br />
<br />
* '''Realtime timers''' (a.k.a. wallclock timers) activate on a calendar event, the same way that cronjobs do. The option {{ic|OnCalendar{{=}}}} is used to define them.<br />
* '''Monotonic timers''' activate after a time span relative to a varying starting point. They stop if the computer is temporarily suspended or shut down. There are number of different monotonic timers but all have the form: {{ic|On''Type''Sec{{=}}}}. Common monotonic timers include {{ic|OnBootSec}} and {{ic|OnUnitActiveSec}}.<br />
<br />
For a full explanation of timer options, see the {{man|5|systemd.timer}}. The argument syntax for calendar events and time spans is defined in {{man|7|systemd.time}}.<br />
<br />
{{Note|''systemd'' offers the target {{ic|timers.target}} which sets up all timers that should be active after boot (see {{man|7|systemd.special}} for details). To use it, add {{ic|WantedBy{{=}}timers.target}} to the {{ic|[Install]}} section of your timer and [[enable]] the timer unit.}}<br />
<br />
== Service units ==<br />
<br />
For each ''.timer'' file, a matching ''.service'' file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}). The ''.timer'' file activates and controls the ''.service'' file. The ''.service'' does not require an {{ic|[Install]}} section as it is the ''timer'' units that are enabled. If necessary, it is possible to control a differently-named unit using the {{ic|Unit{{=}}}} option in the timer's {{ic|[Timer]}} section.<br />
<br />
== Management ==<br />
<br />
To use a ''timer'' unit [[enable]] and [[start]] it like any other unit (remember to add the ''.timer'' suffix). To view all started timers, run:<br />
<br />
{{hc|$ systemctl list-timers|<br />
NEXT LEFT LAST PASSED UNIT ACTIVATES<br />
Thu 2014-07-10 19:37:03 CEST 11h left Wed 2014-07-09 19:37:03 CEST 12h ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service<br />
Fri 2014-07-11 00:00:00 CEST 15h left Thu 2014-07-10 00:00:13 CEST 8h ago logrotate.timer logrotate.service<br />
}}<br />
<br />
{{Note|<br />
* To list all timers (including inactive), use {{ic|systemctl list-timers --all}}.<br />
* The status of a service started by a timer will likely be inactive unless it is currently being triggered.<br />
* If a timer gets out of sync, it may help to delete its {{ic|stamp-*}} file in {{ic|/var/lib/systemd/timers}} (or {{ic|~/.local/share/systemd/}} in case of user timers). These are zero length files which mark the last time each timer was run. If deleted, they will be reconstructed on the next start of their timer.}}<br />
<br />
== Examples ==<br />
<br />
A service unit file can be scheduled with a timer out-of-the-box. The following examples schedule {{ic|foo.service}} to be run with a corresponding timer called {{ic|foo.timer}}.<br />
<br />
=== Monotonic timer ===<br />
<br />
A timer which will start 15 minutes after boot and again every week while the system is running.<br />
<br />
{{hc|/etc/systemd/system/foo.timer|<nowiki><br />
[Unit]<br />
Description=Run foo weekly and on boot<br />
<br />
[Timer]<br />
OnBootSec=15min<br />
OnUnitActiveSec=1w<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
</nowiki>}}<br />
<br />
=== Realtime timer ===<br />
<br />
A timer which starts once a week (at 12:00am on Monday). When activated, it triggers the service immediately if it missed the last start time (option {{ic|Persistent{{=}}true}}), for example due to the system being powered off:<br />
<br />
{{hc|/etc/systemd/system/foo.timer|2=<br />
[Unit]<br />
Description=Run foo weekly<br />
<br />
[Timer]<br />
OnCalendar=weekly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target<br />
}}<br />
<br />
When more specific dates and times are required, {{ic|OnCalendar}} events uses the following format:<br />
<br />
DayOfWeek Year-Month-Day Hour:Minute:Second<br />
<br />
An asterisk may be used to specify any value and commas may be used to list possible values. Two values separated by {{ic|..}} indicate a contiguous range.<br />
<br />
In the below example the service is run the first four days of each month at 12:00 PM, but ''only'' if that day is a Monday or a Tuesday.<br />
<br />
OnCalendar=Mon,Tue *-*-01..04 12:00:00<br />
<br />
To run a service on the first Saturday of every month, use:<br />
<br />
OnCalendar=Sat *-*-1..7 18:00:00<br />
<br />
When using the {{ic|DayOfWeek}} part, at least one weekday has to be specified. If you want something to run every day at 4am, use:<br />
<br />
OnCalendar=*-*-* 4:00:00<br />
<br />
To run a service at different times, {{ic|OnCalendar}} may be specified more than once. In the example below, the service runs at 22:30 on weekdays and at 20:00 on weekends.<br />
<br />
OnCalendar=Mon..Fri 22:30<br />
OnCalendar=Sat,Sun 20:00<br />
<br />
More information is available in {{man|7|systemd.time}}.<br />
<br />
{{Tip|<br />
*{{ic|OnCalendar}} time specifications can be tested in order to verify their validity and to calculate the next time the condition would elapse when used on a timer unit file with the {{ic|calendar}} option of the ''systemd-analyze'' utility. For example, one can use {{ic|systemd-analyze calendar weekly}} or {{ic|systemd-analyze calendar "Mon,Tue *-*-01..04 12:00:00"}}.<br />
*The {{ic|faketime}} command is especially useful to test various scenarios with the above command; it comes with the {{Pkg|libfaketime}} package.<br />
*Special event expressions like {{ic|daily}} and {{ic|weekly}} refer to ''specific start times'' and thus any timers sharing such calendar events will start simultaneously. Timers sharing start events can cause poor system performance if the timers' services compete for system resources. The {{ic|RandomizedDelaySec}} option in the {{ic|[Timer]}} section avoids this problem by randomly staggering the start time of each timer. See {{man|5|systemd.timer}}.<br />
*Add the option {{ic|AccuracySec{{=}}1us}} to the {{ic|[Timer]}} section, to avoid the inaccuracy of the ''1m'' default value of {{ic|AccuracySec}}. Also see {{man|5|systemd.timer}}.<br />
}}<br />
<br />
== Transient timer units ==<br />
<br />
One can use {{ic|systemd-run}} to create transient ''.timer'' units. That is, one can set a command to run at a specified time without having a service file. For example the following command touches a file after 30 seconds:<br />
<br />
# systemd-run --on-active=30 /bin/touch /tmp/foo<br />
<br />
One can also specify a pre-existing service file that does not have a timer file. For example, the following starts the systemd unit named {{ic|''someunit''.service}} after 12.5 hours have elapsed:<br />
<br />
# systemd-run --on-active="12h 30m" --unit ''someunit''.service<br />
<br />
See {{man|1|systemd-run}} for more information and examples.<br />
<br />
== As a cron replacement ==<br />
<br />
Although [[cron]] is arguably the most well-known job scheduler, ''systemd'' timers can be an alternative.<br />
<br />
=== Benefits ===<br />
<br />
The main benefits of using timers come from each job having its own ''systemd'' service. Some of these benefits are:<br />
<br />
* Jobs can be easily started independently of their timers. This simplifies debugging.<br />
* Each job can be configured to run in a specific environment (see {{man|5|systemd.exec}}).<br />
* Jobs can be attached to [[cgroups]].<br />
* Jobs can be set up to depend on other ''systemd'' units.<br />
* Jobs are logged in the ''systemd'' journal for easy debugging.<br />
<br />
=== Caveats ===<br />
<br />
Some things that are easy to do with cron are difficult to do with timer units alone:<br />
<br />
* Creation: to set up a timed job with ''systemd'' you need to create two files and run {{ic|systemctl}} commands, compared to adding a single line to a crontab.<br />
* Emails: there is no built-in equivalent to cron's {{ic|MAILTO}} for sending emails on job failure. See the next section for an example of setting up a similar functionality using {{ic|OnFailure{{=}}}}.<br />
<br />
Also note that [[systemd/User|user]] timer units will only run during an active user login session by default. However, [[Systemd/User#Automatic start-up of systemd user instances|lingering]] can enable services to run at boot even when the user has no active login session.<br />
<br />
=== MAILTO ===<br />
<br />
You can set up systemd to send an e-mail when a unit fails. Cron sends mail to {{ic|MAILTO}} if the job outputs to stdout or stderr, but many jobs are setup to only output on error. First you need two files: an executable for sending the mail and a ''.service'' for starting the executable. For this example, the executable is just a shell script using {{ic|sendmail}}, which is in packages that provide {{ic|smtp-forwarder}}.<br />
<br />
{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/sh<br />
<br />
/usr/bin/sendmail -t <<ERRMAIL<br />
To: $1<br />
From: systemd <root@$HOSTNAME><br />
Subject: $2<br />
Content-Transfer-Encoding: 8bit<br />
Content-Type: text/plain; charset=UTF-8<br />
<br />
$(systemctl status --full "$2")<br />
ERRMAIL</nowiki>}}<br />
<br />
Whatever executable you use, it should probably take at least two arguments as this shell script does: the address to send to and the unit file to get the status of. The ''.service'' we create will pass these arguments:<br />
<br />
{{hc|/etc/systemd/system/status_email_''user''@.service|2=[Unit]<br />
Description=status email for %i to ''user''<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/local/bin/systemd-email ''address'' %i<br />
User=nobody<br />
Group=systemd-journal}}<br />
<br />
Where {{ic|''user''}} is the user being emailed and {{ic|''address''}} is that user's email address. Although the recipient is hard-coded, the unit file to report on is passed as an instance parameter, so this one service can send email for many other units. At this point you can [[start]] {{ic|status_email_''user''@dbus.service}} to verify that you can receive the emails.<br />
<br />
Then simply [[edit]] the service you want emails for and add {{ic|OnFailure{{=}}status_email_''user''@%n.service}} to the {{ic|[Unit]}} section. {{ic|%n}} passes the unit's name to the template.<br />
<br />
{{Note|<br />
* If you set up sSMTP security according to [[sSMTP#Security]] the user {{ic|nobody}} will not have access to {{ic|/etc/ssmtp/ssmtp.conf}}, and the {{ic|systemctl start status_email_''user''@dbus.service}} command will fail. One solution is to use {{ic|root}} as the User in the {{ic|status_email_''user''@.service}} unit.<br />
* If you try to use {{ic|mail -s somelogs ''address''}} in your email script, {{ic|mail}} will fork and systemd will kill the mail process when it sees your script exit. Make the mail non-forking by doing {{ic|mail -Ssendwait -s somelogs ''address''}}.<br />
}}<br />
<br />
Alternatively, for very simple cases, one could also put the shell script that sends the code directly within the unit file like in:<br />
{{hc|/etc/systemd/system/status_email_''user''@.service|2=[Service]<br />
Type=oneshot<br />
ExecStart=@sh %n:sh -c 'systemctl status --full --lines "$1" {{!}} mail -s "$2: systemd unit $1 $(systemctl --value --property=ActiveState show "$1")" root' %n:sh %i %H}}<br />
<br />
=== Using a crontab ===<br />
<br />
Several of the caveats can be worked around by installing a package that parses a traditional crontab to configure the timers, like {{AUR|systemd-cron}}. It can provide the missing {{ic|MAILTO}} feature.<br />
<br />
Also, like with crontabs, a unified view of all scheduled jobs can be obtained with {{ic|systemctl}}. See [[#Management]].<br />
<br />
=== Manually ===<br />
<br />
Outside of migrating from an existing crontab, using the same periodicity as cron can be desired. To avoid the tedious task of creating a timer for each service to start periodically, use a [[Systemd#Using units|template unit]], for example: <br />
<br />
{{hc|/etc/systemd/system/monthly@.timer|2=<br />
[Unit]<br />
Description=Monthly Timer for %i service<br />
<br />
[Timer]<br />
OnCalendar=*-*-1 02:00:00<br />
AccuracySec=6h<br />
RandomizedDelaySec=1h<br />
Persistent=true<br />
Unit=%i.service<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Note|See {{man|5|systemd.timer|OPTIONS}} for the importance of using {{ic|RandomizedDelaySec}} and not only {{ic|AccuracySec}} to avoid all units started by the timer firing at once.}}<br />
<br />
Then one only needs to [[enable/start]] {{ic|monthly@''unit_name''.timer}}.<br />
<br />
{{Tip|The template units can be nested, e.g. one could [[enable/start]] {{ic|monthly@btrfs-scrub@mnt-$(systemd-escape bbb76c63-e4ac-4e39-8897-a120c5d30686).timer}}.}}<br />
<br />
== Handling "time to live" ==<br />
<br />
Some software will track the time elapsed since they last ran, for example blocking the update of a database if the last download ended less than 24 hours ago. <br />
<br />
By default, timers do not track when the task they launched has ended. To work around this, we can use {{ic|OnUnitInactiveSeconds}}: <br />
<br />
{{hc|/etc/systemd/system/daily-inactive@.timer|2=<br />
[Unit]<br />
Description=Launch %i service 24hours after it deactivated<br />
<br />
[Timer]<br />
'''OnUnitInactiveSec=1day1sec'''<br />
Unit=%i.service<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{Tip|With {{ic|1=Restart=on-failure}} along with {{ic|RestartSec}}, it is possible<br />
to have a unit rerun after failure and success according to different schedules, see {{man|5|systemd.service|OPTIONS}}.}}<br />
<br />
== See also ==<br />
<br />
* {{man|5|systemd.timer}}<br />
* [[Fedora:Features/SystemdCalendarTimers]]<br />
* [[Gentoo:Systemd#Timer services]]<br />
* {{App|systemd-cron|provides systemd units to run cron scripts; using ''systemd-crontab-generator'' to convert crontabs|https://github.com/systemd-cron/systemd-cron|{{AUR|systemd-cron}}}}<br />
* [https://fedoramagazine.org/systemd-timers-for-scheduling-tasks/ Systemd Timers for Scheduling Tasks]</div>Calestyohttps://wiki.archlinux.org/index.php?title=Power_management&diff=774237Power management2023-03-30T11:38:12Z<p>Calestyo: link to the section that describes how to override logind</p>
<hr />
<div>[[Category:Power management]]<br />
[[es:Power management]]<br />
[[ja:電源管理]]<br />
[[ru:Power management]]<br />
[[zh-hans:Power management]]<br />
{{Related articles start}}<br />
{{Related|Power management/Suspend and hibernate}}<br />
{{Related|Power management/Wakeup triggers}}<br />
{{Related|Display Power Management Signaling}}<br />
{{Related|CPU frequency scaling}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Kernel modules}}<br />
{{Related|sysctl}}<br />
{{Related|udev}}<br />
{{Related articles end}}<br />
[[Wikipedia:Power management|Power management]] is a feature that turns off the power or switches system components to a low-power state when inactive.<br />
<br />
In Arch Linux, power management consists of two main parts:<br />
<br />
# Configuration of the Linux kernel, which interacts with the hardware.<br />
#* [[Kernel parameters]]<br />
#* [[Kernel modules]]<br />
#* [[udev]] rules<br />
# Configuration of userspace tools, which interact with the kernel and react to its events. Many userspace tools also allow to modify kernel configuration in a "user-friendly" way. See [[#Userspace tools]] for the options.<br />
<br />
== Userspace tools ==<br />
<br />
Using these tools can replace setting a lot of settings by hand. Only run '''one''' of these tools to avoid possible conflicts as they all work more or less similarly. Have a look at the [[:Category:Power management|power management category]] to get an overview on what power management options exist in Arch Linux.<br />
<br />
These are the more popular scripts and tools designed to help power saving:<br />
<br />
=== Console ===<br />
<br />
* {{App|[[acpid]]| A daemon for delivering ACPI power management events with netlink support.|https://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}<br />
* {{App|[[Laptop Mode Tools]]|Utility to configure laptop power saving settings, considered by many to be the de facto utility for power saving though may take a bit of configuration.|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}<br />
* {{App|libsmbios|Library and tools for interacting with Dell SMBIOS tables.|https://github.com/dell/libsmbios|{{Pkg|libsmbios}}}}<br />
* {{App|[[powertop]]|A tool to diagnose issues with power consumption and power management to help set power saving settings.|https://01.org/powertop/|{{Pkg|powertop}}}}<br />
* {{App|[[systemd]]|A system and service manager.|https://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[TLP]]|Advanced power management for Linux.|https://linrunner.de/tlp|{{Pkg|tlp}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|batsignal|Lightweight battery monitor that uses libnotify to warn of low battery levels.|https://github.com/electrickite/batsignal|{{AUR|batsignal}}}}<br />
* {{App|cbatticon|Lightweight and fast battery icon that sits in your system tray.|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}<br />
* {{App|GNOME Power Statistics|System power information and statistics for GNOME.|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}<br />
* {{App|KDE Power Devil|Power management module for Plasma.|https://invent.kde.org/plasma/powerdevil|{{Pkg|powerdevil}}}}<br />
* {{App|LXQt Power Management|Power management module for LXQt.|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}<br />
* {{App|MATE Power Management|Power management tool for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|MATE Power Statistics|System power information and statistics for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|poweralertd|Daemon for delivering UPower notifications.|https://git.sr.ht/~kennylevinsen/poweralertd|{{AUR|poweralertd}}}}<br />
* {{App|powerkit|Desktop independent power manager.|https://github.com/rodlie/powerkit|{{AUR|powerkit}}}}<br />
* {{App|Xfce Power Manager|Power manager for Xfce.|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}<br />
* {{App|vattery|Battery monitoring application written in Vala that will display the status of a laptop battery in a system tray.|https://www.jezra.net/projects/vattery.html|{{AUR|vattery}}}}<br />
<br />
== Power management ==<br />
<br />
=== ACPI events ===<br />
<br />
''systemd'' handles some power-related [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] events, whose actions can be configured in {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} — see {{man|5|logind.conf}}. On systems with no dedicated power manager, this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
The specified action for each event can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}}, {{ic|suspend-then-hibernate}}, {{ic|lock}} or {{ic|kexec}}. In case of hibernation and suspension, they must be properly [[Power management/Suspend and hibernate|set up]]. If an event is not configured, ''systemd'' will use a default action.<br />
<br />
{| class="wikitable sortable"<br />
!Event handler<br />
!Description<br />
!Default action<br />
|-<br />
|{{ic|HandlePowerKey}}<br />
|Triggered when the power key/button is pressed.<br />
|{{ic|poweroff}}<br />
|-<br />
|{{ic|HandleSuspendKey}}<br />
|Triggered when the suspend key/button is pressed.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleHibernateKey}}<br />
|Triggered when the hibernate key/button is pressed.<br />
|{{ic|hibernate}}<br />
|-<br />
|{{ic|HandleLidSwitch}}<br />
|Triggered when the lid is closed, except in the cases below.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleLidSwitchDocked}}<br />
|Triggered when the lid is closed if the system is inserted in a docking station, or more than one display is connected.<br />
|{{ic|ignore}}<br />
|-<br />
|{{ic|HandleLidSwitchExternalPower}}<br />
|Triggered when the lid is closed if the system is connected to external power.<br />
|action set for {{ic|HandleLidSwitch}}<br />
|}<br />
<br />
To apply any changes, signal {{ic|systemd-logind}} with {{ic|HUP}}:<br />
<br />
# systemctl kill -s HUP systemd-logind<br />
<br />
{{Note|''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.}}<br />
<br />
==== Power managers ====<br />
<br />
Some [[desktop environment]]s include power managers which [https://www.freedesktop.org/wiki/Software/systemd/inhibit/ inhibit] (temporarily turn off) some or all of the ''systemd'' ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager. <br />
<br />
Note that if the power manager does not inhibit ''systemd'' for the appropriate events you can end up with a situation where ''systemd'' suspends your system and then when the system is woken up the other power manager suspends it again. The power managers of [[KDE]], [[GNOME]], [[Xfce]] and [[MATE]] issue the necessary ''inhibited'' commands. If the ''inhibited'' commands are not being issued, such as when using [[acpid]] or others to handle ACPI events, set the {{ic|Handle}} options to {{ic|ignore}}. See also {{man|1|systemd-inhibit}}.<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} subscribes to the systemd-events {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker). ''xss-lock'' also reacts to [[DPMS]] events and runs or kills the locker in response.<br />
<br />
[[Autostart]]ing the following for example:<br />
<br />
$ xss-lock -- i3lock -n -i ''background_image.png'' &<br />
<br />
=== Suspend and hibernate ===<br />
<br />
''systemd'' provides commands to suspend to RAM or hibernate using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.<br />
<br />
{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Suspend and hibernate#Hibernation]].<br />
<br />
There are also two modes combining suspend and hibernate:<br />
<br />
* {{ic|systemctl hybrid-sleep}} suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called [[Power management/Suspend and hibernate|suspend to both]].<br />
* {{ic|systemctl suspend-then-hibernate}} initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}. The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by {{ic|SuspendEstimationSec}} in {{man|5|systemd-sleep.conf}}, at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension). <br />
<br />
{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}<br />
<br />
==== Hybrid-sleep on suspend or hibernation request ====<br />
<br />
It is possible to configure systemd to always do a ''hybrid-sleep'' even on a ''suspend'' or ''hibernation'' request.<br />
<br />
The default ''suspend'' and ''hibernation'' action can be configured in the {{ic|/etc/systemd/sleep.conf}} file. To set both actions to ''hybrid-sleep'':<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
# suspend=hybrid-sleep<br />
SuspendMode=suspend<br />
SuspendState=disk<br />
# hibernate=hybrid-sleep<br />
HibernateMode=suspend<br />
HibernateState=disk<br />
}}<br />
<br />
See the {{man|5|sleep.conf.d}} manual page for details and the [https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation linux kernel documentation on power states].<br />
<br />
==== Disabling suspend ====<br />
<br />
When using a device as e.g a server, suspending might not be needed or it could even be undesired.<br />
Any sleep state can be configured:<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
AllowSuspend=no<br />
AllowHibernation=no<br />
AllowSuspendThenHibernate=no<br />
AllowHybridSleep=no<br />
}}<br />
<br />
<br />
==== Advertise hibernation despite non-active swap area ====<br />
<br />
When using for example [[#On-demand swap for hibernation only|on-demand swap for hibernation only]], desktop environments might now show the option to hibernate and {{ic|systemctl hibernate}} will not work, because these query {{ic|systemd-logind}} for the available power-saving modes and that won’t advertise hibernation unless a swap-area is active.<br />
<br />
This can be circumvented by starting {{ic|systemd-logind}} with the variable {{ic|SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK{{=}}1}} in its environment, for example via a “drop-in” directory configuration like:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/disable-hibernation-swap-check.conf|2=<br />
[Service]<br />
Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"<br />
}}<br />
<br />
=== Sleep hooks ===<br />
<br />
==== Suspend/resume service files ====<br />
<br />
Service files can be hooked into ''suspend.target'', ''hibernate.target'', ''sleep.target'', ''hybrid-sleep.target'' and ''suspend-then-hibernate.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. [[Enable]] the {{ic|suspend@''user''}} and {{ic|resume@''user''}} services to have them started at boot. Examples:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop<br />
ExecStart=/usr/bin/sflock<br />
ExecStartPost=/usr/bin/sleep 1<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStart=/usr/local/bin/ssh-connect.sh<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Note|As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via {{ic|1=ExecStartPost=/usr/bin/sleep 1}} helps prevent this.}}<br />
<br />
For root/system actions ([[enable]] the {{ic|root-resume}} and {{ic|root-suspend}} services to have them started at boot):<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Tip|A couple of handy hints about these service files (more in {{man|5|systemd.service}}):<br />
<br />
* If {{ic|1=Type=oneshot}} then you can use multiple {{ic|1=ExecStart=}} lines. Otherwise only one {{ic|ExecStart}} line is allowed. You can add more commands with either {{ic|ExecStartPre}} or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are ''required'').<br />
* A command prefixed with {{ic|-}} will cause a non-zero exit status to be ignored and treated as a successful command. <br />
* The best place to find errors when troubleshooting these service files is of course with [[journalctl]].<br />
}}<br />
<br />
==== Combined suspend/resume service file ====<br />
<br />
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Example and explanation:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
* {{ic|1=RemainAfterExit=yes}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=StopWhenUnneeded=yes}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after ''sleep.target'' is stopped.<br />
* Because ''sleep.target'' is pulled in by ''suspend.target'', ''hibernate.target'' and ''hybrid-sleep.target'' and because ''sleep.target'' itself is a ''StopWhenUnneeded'' service, the hook is guaranteed to start/stop properly for different tasks.<br />
<br />
===== Generic service template =====<br />
<br />
In this example, we create a [http://0pointer.net/blog/projects/instances.html template service] which we can then use to hook any existing systemd service to power events:[https://narkive.com/mYzxSIDN.6]<br />
<br />
{{hc|/etc/systemd/system/sleep@.service|2=<br />
[Unit]<br />
Description=%I sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/bin/systemctl stop %i<br />
ExecStop=-/usr/bin/systemctl start %i<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
Then [[enable]] an instance of this template by specifying the basename of an existing systemd service after the {{ic|@}}, i.e., {{ic|sleep@'''''service-file-basename'''''.service}}. See {{man|5|systemd.unit|DESCRIPTION}} for more details on templates.<br />
<br />
{{Tip|Templates are not limited to systemd services and can be used with other programs. See [https://fedoramagazine.org/systemd-template-unit-files/] for some examples.}}<br />
<br />
==== On-demand swap for hibernation only ====<br />
<br />
In some setups it might be desired to have the swap area activated only for the hibernation and deactivated again after resume.<br />
<br />
While this could be achieved via the hooks described above, it's also possible to directly use a swap unit configuration (see {{man|5|systemd.swap}}) like the following:<br />
{{hc|/etc/systemd/system/path-to-swap.swap|2=<br />
[Unit]<br />
Before=systemd-hibernate.service<br />
StopWhenUnneeded=true<br />
<br />
[Swap]<br />
What=/path/to/swap<br />
Options=noauto<br />
<br />
[Install]<br />
RequiredBy=systemd-hibernate.service<br />
}}<br />
''Note that the unit filename must correspond to the pathname of the swap device respectively file and that the unit must be enabled to have the {{ic|RequiredBy{{=}}}} take effect.''<br />
<br />
It would also be possible to depend on {{ic|hibernate.target}} rather than {{ic|systemd-hibernate.service}}, but then a direct {{ic|systemctl start systemd-hibernate.service}} would not work.<br />
<br />
See also how to [[#Advertise hibernation despite non-active swap area|override systemd-logind not advertising hibernation]].<br />
<br />
==== Hooks in /usr/lib/systemd/system-sleep ====<br />
<br />
''systemd'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked<br />
<br />
''systemd'' will run these scripts concurrently and not one after another.<br />
<br />
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[journalctl]]:<br />
<br />
# journalctl -b -u systemd-suspend.service<br />
<br />
{{Note|You can also use ''sleep.target'', ''suspend.target'', ''hibernate.target'' or ''hybrid-sleep.target'' to hook units into the sleep state logic instead of using custom scripts.}}<br />
<br />
An example of a custom sleep script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac<br />
}}<br />
<br />
Do not forget to make your script [[executable]].<br />
<br />
See {{man|7|systemd.special}} and {{man|8|systemd-sleep}} for more details.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== Delayed lid switch action ====<br />
<br />
When performing lid switches in short succession, ''logind'' will delay the suspend action for up to 90s to detect possible docks. [https://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] This delay was made configurable with systemd v220:[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba]<br />
<br />
{{hc|/etc/systemd/logind.conf|2=<br />
...<br />
HoldoffTimeoutSec=30s<br />
...<br />
}}<br />
<br />
==== Suspend from corresponding laptop Fn key not working ====<br />
<br />
If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [https://lists.freedesktop.org/archives/systemd-devel/2015-February/028325.html] Do:<br />
<br />
# journalctl --grep="Watching system buttons"<br />
<br />
You might see something like this:<br />
<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)<br />
<br />
Notice no keyboard device. Now obtain ATTRS{name} for the parent keyboard device [https://systemd-devel.freedesktop.narkive.com/Rbi3rjNN/patch-1-2-logind-add-support-for-tps65217-power-button] :<br />
<br />
{{hc|# udevadm info -a /dev/input/by-path/*-kbd|2=<br />
...<br />
KERNEL=="event0"<br />
...<br />
ATTRS{name}=="AT Translated Set 2 keyboard"<br />
}}<br />
<br />
Now write a custom udev rule to add the "power-switch" tag:<br />
<br />
{{hc|/etc/udev/rules.d/70-power-switch-my.rules|2=<br />
ACTION=="remove", GOTO="power_switch_my_end"<br />
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="AT Translated Set 2 keyboard", TAG+="power-switch"<br />
LABEL="power_switch_my_end"<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-udevd.service}}, reload rules by running {{ic|udevadm trigger}} as root, and [[restart]] {{ic|systemd-logind.service}}.<br />
<br />
Now you should see {{ic|Watching system buttons on /dev/input/event0}} in syslog.<br />
<br />
==== PC will not wake from sleep on A520I and B550I motherboards ====<br />
<br />
On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD [[microcode]] package is installed.<br />
<br />
Verify the line starting with {{ic|GPP0}} has the enabled status: <br />
<br />
{{hc|$ cat /proc/acpi/wakeup|<br />
Device S-state Status Sysfs node<br />
GP12 S4 *enabled pci:0000:00:07.1<br />
GP13 S4 *enabled pci:0000:00:08.1<br />
XHC0 S4 *enabled pci:0000:0b:00.3<br />
GP30 S4 *disabled<br />
GP31 S4 *disabled<br />
PS2K S3 *disabled<br />
'''GPP0''' S4 '''*enabled''' pci:0000:00:01.1<br />
GPP8 S4 *enabled pci:0000:00:03.1<br />
PTXH S4 *enabled pci:0000:05:00.0<br />
PT20 S4 *disabled<br />
PT24 S4 *disabled<br />
PT26 S4 *disabled<br />
PT27 S4 *disabled<br />
PT28 S4 *enabled pci:0000:06:08.0<br />
PT29 S4 *enabled pci:0000:06:09.0<br />
}}<br />
<br />
If that is enabled, you can run the following command:<br />
<br />
# echo GPP0 > /proc/acpi/wakeup<br />
<br />
Now test by running {{ic|systemctl suspend}} and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. [[Create]] a systemd [[Systemd#Writing unit files|unit file]]:<br />
<br />
{{hc|/etc/systemd/system/toggle.ggp0.to.fix.suspend.issue.service|2=<br />
[Unit]<br />
Description="Disable GGP0 to fix suspend issue"<br />
<br />
[Service]<br />
ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Do a [[daemon-reload]] and [[start/enable]] the newly created unit.<br />
<br />
== Power saving ==<br />
<br />
{{Note|See [[Laptop#Power management]] for power management specific to laptops, such as battery monitoring. See also pages specific to your CPU and GPU (e.g., [[Ryzen]], [[AMDGPU]]).}}<br />
<br />
This section is a reference for creating custom scripts and power saving settings such as by udev rules. Make sure that the settings are not managed by some [[#Userspace tools|other utility]] to avoid conflicts.<br />
<br />
Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
=== Processors with Intel HWP (Intel Hardware P-state) support ===<br />
<br />
{{Merge|CPU frequency scaling|More context in the main article.}}<br />
<br />
The available energy preferences of a HWP supported processor are {{ic|default}}, {{ic|performance}}, {{ic|balance_performance}}, {{ic|balance_power}}, {{ic|power}}.<br />
<br />
This can be validated by running<br />
<br />
$ cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_available_preferences<br />
<br />
To conserve more energy, you can configuration by creating the following file:<br />
<br />
{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|<br />
w /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference - - - - balance_power<br />
}}<br />
<br />
See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
=== Audio ===<br />
<br />
==== Kernel ====<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the {{ic|power_save}} parameter; a time (in seconds) to go into idle mode. To idle the audio card after one second, create the following file for Intel soundcards.<br />
<br />
{{hc|/etc/modprobe.d/audio_powersave.conf|2=<br />
options snd_hda_intel power_save=1<br />
}}<br />
<br />
Alternatively, use the following for ac97:<br />
<br />
options snd_ac97_codec power_save=1<br />
<br />
{{Note|<br />
* To retrieve the manufacturer and the corresponding kernel driver which is used for your sound card, run {{ic|lspci -k}}.<br />
* Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.<br />
}}<br />
<br />
It is also possible to further reduce the audio power requirements by disabling the HDMI audio output, which can done by [[blacklisting]] the appropriate kernel modules (e.g. {{ic|snd_hda_codec_hdmi}} in case of Intel hardware).<br />
<br />
==== PulseAudio ====<br />
<br />
By default, PulseAudio suspends any audio sources that have become idle for too long. When using an external USB microphone, recordings may start with a pop sound. As a workaround, comment out the following line in {{ic|/etc/pulse/default.pa}}:<br />
<br />
load-module module-suspend-on-idle<br />
<br />
Afterwards, restart PulseAudio with {{ic|systemctl restart --user pulseaudio}}.<br />
<br />
=== Backlight ===<br />
<br />
See [[Backlight]].<br />
<br />
=== Bluetooth ===<br />
<br />
To disable bluetooth completely, [[blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
To turn off bluetooth only temporarily, use ''rfkill'':<br />
<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
<br />
{{hc|/etc/udev/rules.d/50-bluetooth.rules|2=<br />
# disable bluetooth<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
}}<br />
<br />
=== Web camera ===<br />
<br />
If you will not use integrated web camera then [[blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
=== Kernel parameters ===<br />
<br />
This section uses configurations in {{ic|/etc/sysctl.d/}}, which is ''"a drop-in directory for kernel sysctl parameters."'' See [http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] and more specifically {{man|5|sysctl.d}} for more information.<br />
<br />
==== Disabling NMI watchdog ====<br />
<br />
{{Expansion|This or {{ic|nowatchdog}} as can be seen in [[Improving performance#Watchdogs]]}}<br />
<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs that cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage:<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=<br />
kernel.nmi_watchdog = 0<br />
}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} to the [[kernel line]] to disable it completely from early boot.<br />
<br />
==== Writeback Time ====<br />
<br />
Increasing the virtual memory dirty writeback time helps to aggregate disk I/O together, thus reducing spanned disk writes, and increasing power saving. To set the value to 60 seconds (default is 5 seconds):<br />
<br />
{{hc|/etc/sysctl.d/dirty.conf|2=<br />
vm.dirty_writeback_centisecs = 6000<br />
}}<br />
<br />
To do the same for journal commits on supported filesystems (e.g. ext4, btrfs...), use {{ic|1=commit=60}} as a option in [[fstab]].<br />
<br />
Note that this value is modified as a side effect of the Laptop Mode setting below. See also [[sysctl#Virtual memory]] for other parameters affecting I/O performance and power saving.<br />
<br />
==== Laptop Mode ====<br />
<br />
See the [https://docs.kernel.org/admin-guide/laptops/laptop-mode.html kernel documentation] on the laptop mode "knob" - "A sensible value for the knob is 5 seconds".<br />
<br />
{{hc|/etc/sysctl.d/laptop.conf|2=<br />
vm.laptop_mode = 5<br />
}}<br />
<br />
{{Note|This setting is mainly relevant to spinning-disk drives.}}<br />
<br />
=== Network interfaces ===<br />
<br />
[[Wake-on-LAN]] can be a useful feature, but if you are not making use of it then it is simply draining extra power waiting for a magic packet while in suspend. You can adapt the [[Wake-on-LAN#udev]] rule to disable the feature for all ethernet interfaces. To enable powersaving with {{Pkg|iw}} on all wireless interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"<br />
}}<br />
<br />
The name of the configuration file is important. With the use of [[Network configuration#Change interface name|persistent device names]] in systemd, the above network rule, named lexicographically '''after''' {{ic|80-net-setup-link.rules}}, is applied after the device is renamed with a persistent name e.g. {{ic|wlan0}} renamed {{ic|wlp3s0}}. Be aware that the {{ic|RUN}} command is executed after all rules have been processed and must anyway use the persistent name, available in {{ic|$name}} for the matched device.<br />
<br />
==== Intel wireless cards (iwlwifi) ====<br />
<br />
Additional power saving functions of Intel wireless cards with {{ic|iwlwifi}} driver can be enabled by passing the correct parameters to the kernel module. Making them persistent can be achieved by adding the lines below to the {{ic|/etc/modprobe.d/iwlwifi.conf}} file:<br />
<br />
options iwlwifi power_save=1<br />
<br />
This option will probably increase your median latency:<br />
<br />
options iwlwifi uapsd_disable=0<br />
<br />
On kernels < 5.4 you can use this option, but it will probably decrease your maximum throughput:<br />
<br />
options iwlwifi d0i3_disable=0<br />
<br />
Depending on your wireless card one of these two options will apply.<br />
<br />
options iwlmvm power_scheme=3<br />
<br />
options iwldvm force_cam=0<br />
<br />
You can check which one is relevant by checking which of these modules is running using<br />
<br />
# lsmod | grep '^iwl.vm'<br />
<br />
Keep in mind that these power saving options are experimental and can cause an unstable system.<br />
<br />
=== Bus power management ===<br />
<br />
==== Active State Power Management ====<br />
<br />
If the computer is believed not to support [[Wikipedia:Active State Power Management|ASPM]] it will be disabled on boot:<br />
<br />
# lspci -vv | grep 'ASPM.*abled;'<br />
<br />
ASPM is handled by the BIOS, if ASPM is disabled it will be because [https://wireless.wiki.kernel.org/en/users/documentation/ASPM]:<br />
<br />
# The BIOS disabled it for some reason (for conflicts?).<br />
# PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).<br />
# The BIOS might not have been programmed for it.<br />
# The BIOS is buggy.<br />
<br />
If believing the computer has support for ASPM it can be forced on for the kernel to handle with the {{ic|1=pcie_aspm=force}} [[kernel parameter]].<br />
<br />
{{Warning|<br />
* Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it does not work.<br />
* On systems that do not support it forcing on ASPM can even increase power consumption.<br />
* This forces ASPM in kernel while it can still remain disabled in hardware and not work. To check whether this is the case, run {{ic|dmesg {{!}} grep ASPM}} as root. If so, consult the Wiki article specific to your hardware.<br />
}}<br />
<br />
To adjust to {{ic|powersave}} do (the following command will not work unless enabled):<br />
<br />
# echo powersave > /sys/module/pcie_aspm/parameters/policy<br />
<br />
By default it looks like this:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|<br />
[default] performance powersave powersupersave<br />
}}<br />
<br />
==== PCI Runtime Power Management ====<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
}}<br />
<br />
The rule above powers all unused devices down, but some devices will not wake up again. To allow runtime power management only for devices that are known to work, use simple matching against vendor and device IDs (use {{ic|lspci -nn}} to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# whitelist for pci autosuspend<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with PCI runtime power management and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# blacklist for pci runtime power management<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"<br />
<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
LABEL="pci_pm_end"<br />
}}<br />
<br />
==== USB autosuspend ====<br />
<br />
The Linux kernel can automatically suspend USB devices when they are not in use. This can sometimes save quite a bit of power, however some USB devices are not compatible with USB power saving and start to misbehave (common for USB mice/keyboards). [[udev]] rules based on whitelist or blacklist filtering can help to mitigate the problem.<br />
<br />
The most simple and likely useless example is enabling autosuspend for all USB devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
}}<br />
<br />
To allow autosuspend only for devices that are known to work, use simple matching against vendor and product IDs (use ''lsusb'' to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# whitelist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with USB autosuspend and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# blacklist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"<br />
<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
LABEL="power_usb_rules_end"<br />
}}<br />
<br />
The default autosuspend idle delay time is controlled by the {{ic|autosuspend}} parameter of the {{ic|usbcore}} built-in [[kernel module]]. To set the delay to 5 seconds instead of the default 2 seconds, add the following [[kernel parameter]] for your boot loader.<br />
<br />
{{bc|1=usbcore.autosuspend=5}}<br />
<br />
Similarly to {{ic|power/control}}, the delay time can be fine-tuned per device by setting the {{ic|power/autosuspend}} attribute. This means, alternatively, autosuspend can be disabled by setting {{ic|power/autosuspend}} to -1 (i.e., never autosuspend):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"<br />
}}<br />
<br />
See the [https://docs.kernel.org/driver-api/usb/power-management.html Linux kernel documentation] for more information on USB power management.<br />
<br />
==== SATA Active Link Power Management ====<br />
<br />
{{Warning|SATA Active Link Power Management can lead to data loss on some devices. Do not enable this setting unless you have frequent backups.}}<br />
<br />
{{Out of date|Phrases like "new setting" and "will become a default setting" are outdated. Also should be more formal. See [[Help:Style#Language register]].}}<br />
<br />
Since Linux 4.15 there is a [https://hansdegoede.livejournal.com/18412.html new setting] called {{ic|med_power_with_dipm}} that matches the behaviour of Windows IRST driver settings and should not cause data loss with recent SSD/HDD drives. The power saving can be significant, ranging [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b from 1.0 to 1.5 Watts (when idle)]. It will become a default setting for Intel based laptops in Linux 4.16 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b].<br />
<br />
The current setting can be read from {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} as follows:<br />
<br />
$ cat /sys/class/scsi_host/host*/link_power_management_policy<br />
<br />
{| class="wikitable"<br />
|+ Available ALPM settings<br />
! Setting<br />
! Description<br />
! Power saving<br />
|-<br />
| max_performance<br />
| current default<br />
| None<br />
|-<br />
| medium_power<br />
| -<br />
| ~1.0 Watts<br />
|-<br />
| med_power_with_dipm<br />
| recommended setting<br />
| ~1.5 Watts<br />
|-<br />
| min_power<br />
| '''WARNING: possible data loss'''<br />
| ~1.5 Watts<br />
|}<br />
<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"<br />
}}<br />
<br />
{{Note|This adds latency when accessing a drive that has been idle, so it is one of the few settings that may be worth toggling based on whether you are on AC power.}}<br />
<br />
=== Hard disk drive ===<br />
<br />
See [[hdparm#Power management configuration]] for drive parameters that can be set.<br />
<br />
Power saving is not effective when too many programs are frequently writing to the disk. Tracking all programs, and how and when they write to disk is the way to limit disk usage. Use {{Pkg|iotop}} to see which programs use the disk frequently. See [[Improving performance#Storage devices]] for other tips.<br />
<br />
Also little things like setting the [[Fstab#atime options|noatime]] option can help. If enough RAM is available, consider disabling or limiting [[swappiness]] as it has the possibility to limit a good number of disk writes.<br />
<br />
== Tools and scripts ==<br />
<br />
{{Style|Merged from [[Power saving]], needs reorganization to fit into this page.}}<br />
<br />
=== Using a script and an udev rule ===<br />
<br />
{{Merge|Laptop#Power management|Might be a better fit for the laptop-specific page.}}<br />
<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove ''pm-utils'' and [[acpid]]. There is just one thing systemd cannot do (as of systemd-204): power management depending on whether the system is running on AC or battery. To fill this gap, you can create a single [[udev]] rule that runs a script when the AC adapter is plugged and unplugged:<br />
<br />
{{hc|/etc/udev/rules.d/powersave.rules|2=<br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
}}<br />
<br />
{{Note|You can use the same script that ''pm-powersave'' uses. You just have to make it executable and place it somewhere else (for example {{ic|/usr/local/bin/}}).}}<br />
<br />
Examples of powersave scripts:<br />
<br />
* [https://github.com/supplantr/ftw ftw], package: {{AUR|ftw-git}}<br />
* [https://github.com/Unia/powersave powersave]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=180762 throttlectl], from {{AUR|throttlectl}}<br />
<br />
The above udev rule should work as expected, but if your power settings are not updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online {{!}} grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac<br />
exit 0<br />
}}<br />
<br />
Do not forget to make it executable!<br />
<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
=== Print power settings ===<br />
<br />
{{Merge|#Power saving|Might be good as an introduction? Since most of the output of the script can be used by the following sections.}}<br />
<br />
This script prints power settings and a variety of other properties for USB and PCI devices. Note that root permissions are needed to see all settings.<br />
<br />
{{bc|1=<br />
#!/bin/bash<br />
<br />
for i in $(find /sys/devices -name "bMaxPower")<br />
do<br />
busdir=${i%/*}<br />
busnum=$(<$busdir/busnum)<br />
devnum=$(<$busdir/devnum)<br />
title=$(lsusb -s $busnum:$devnum)<br />
<br />
printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"<br />
<br />
for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)<br />
do<br />
v=$(cat $ff 2>/dev/null{{!}}tr -d "\n")<br />
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";<br />
v=;<br />
done {{!}} sort -g;<br />
done;<br />
<br />
printf "\n\n\n+++ %s\n" "Kernel Modules"<br />
for mod in $(lspci -k {{!}} sed -n '/in use:/s,^.*: ,,p' {{!}} sort -u)<br />
do<br />
echo "+ $mod";<br />
systool -v -m $mod 2> /dev/null {{!}} sed -n "/Parameters:/,/^$/p";<br />
done<br />
}}<br />
<br />
== Allow users to shutdown ==<br />
<br />
{{Style|Merged from [[Allow users to shutdown]], needs reorganization to fit into this page.}}<br />
<br />
=== Button and lid events ===<br />
<br />
The suspend, poweroff and hibernate button presses and lid close events are handled by ''logind'' as described in [[#ACPI events]].<br />
<br />
=== Using systemd-logind ===<br />
<br />
If you are using {{Pkg|polkit}}, users with non-remote session can issue power-related commands as long as [[General troubleshooting#Session permissions|the session is not broken]].<br />
<br />
To check if your session is active<br />
$ loginctl show-session $XDG_SESSION_ID --property=Active<br />
<br />
The user can then use ''systemctl'' commands in the command line, or add them to menus:<br />
$ systemctl poweroff<br />
$ systemctl reboot<br />
<br />
Other commands can be used as well, including {{ic|systemctl suspend}} and {{ic|systemctl hibernate}}. See the ''System Commands'' section in {{man|1|systemctl}}.<br />
<br />
=== Using sudo ===<br />
<br />
[[Install]] {{Pkg|sudo}}, and give the user [[sudo|sudo privileges]]. The user will then be able to use the {{ic|sudo systemctl}} commands (e.g. {{ic|sudo systemctl poweroff}}, {{ic|sudo systemctl reboot}}, {{ic|sudo systemctl suspend}} and {{ic|sudo systemctl hibernate}}). See the ''System Commands'' section in {{man|1|systemctl}}<br />
<br />
==== Users without sudo privileges ====<br />
<br />
If users should only be allowed to use shutdown commands, but not have other sudo privileges, then, as root, add the following to the end of {{ic|/etc/sudoers}} using the {{ic|visudo}} command. Substitute ''user'' for your username and ''hostname'' for the machine's hostname.<br />
<br />
''user'' ''hostname'' =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot<br />
<br />
Now your user can shutdown with {{ic|sudo systemctl poweroff}}, and reboot with {{ic|sudo systemctl reboot}}. Users wishing to power down a system can also use {{ic|sudo systemctl halt}}. Use the {{ic|NOPASSWD:}} tag only if you do not want to be prompted for your password.<br />
<br />
== See also ==<br />
<br />
* [https://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]<br />
* [https://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]</div>Calestyohttps://wiki.archlinux.org/index.php?title=Power_management&diff=774236Power management2023-03-30T11:36:11Z<p>Calestyo: explain how to override logind's check for whether hibernation is available</p>
<hr />
<div>[[Category:Power management]]<br />
[[es:Power management]]<br />
[[ja:電源管理]]<br />
[[ru:Power management]]<br />
[[zh-hans:Power management]]<br />
{{Related articles start}}<br />
{{Related|Power management/Suspend and hibernate}}<br />
{{Related|Power management/Wakeup triggers}}<br />
{{Related|Display Power Management Signaling}}<br />
{{Related|CPU frequency scaling}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Kernel modules}}<br />
{{Related|sysctl}}<br />
{{Related|udev}}<br />
{{Related articles end}}<br />
[[Wikipedia:Power management|Power management]] is a feature that turns off the power or switches system components to a low-power state when inactive.<br />
<br />
In Arch Linux, power management consists of two main parts:<br />
<br />
# Configuration of the Linux kernel, which interacts with the hardware.<br />
#* [[Kernel parameters]]<br />
#* [[Kernel modules]]<br />
#* [[udev]] rules<br />
# Configuration of userspace tools, which interact with the kernel and react to its events. Many userspace tools also allow to modify kernel configuration in a "user-friendly" way. See [[#Userspace tools]] for the options.<br />
<br />
== Userspace tools ==<br />
<br />
Using these tools can replace setting a lot of settings by hand. Only run '''one''' of these tools to avoid possible conflicts as they all work more or less similarly. Have a look at the [[:Category:Power management|power management category]] to get an overview on what power management options exist in Arch Linux.<br />
<br />
These are the more popular scripts and tools designed to help power saving:<br />
<br />
=== Console ===<br />
<br />
* {{App|[[acpid]]| A daemon for delivering ACPI power management events with netlink support.|https://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}<br />
* {{App|[[Laptop Mode Tools]]|Utility to configure laptop power saving settings, considered by many to be the de facto utility for power saving though may take a bit of configuration.|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}<br />
* {{App|libsmbios|Library and tools for interacting with Dell SMBIOS tables.|https://github.com/dell/libsmbios|{{Pkg|libsmbios}}}}<br />
* {{App|[[powertop]]|A tool to diagnose issues with power consumption and power management to help set power saving settings.|https://01.org/powertop/|{{Pkg|powertop}}}}<br />
* {{App|[[systemd]]|A system and service manager.|https://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[TLP]]|Advanced power management for Linux.|https://linrunner.de/tlp|{{Pkg|tlp}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|batsignal|Lightweight battery monitor that uses libnotify to warn of low battery levels.|https://github.com/electrickite/batsignal|{{AUR|batsignal}}}}<br />
* {{App|cbatticon|Lightweight and fast battery icon that sits in your system tray.|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}<br />
* {{App|GNOME Power Statistics|System power information and statistics for GNOME.|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}<br />
* {{App|KDE Power Devil|Power management module for Plasma.|https://invent.kde.org/plasma/powerdevil|{{Pkg|powerdevil}}}}<br />
* {{App|LXQt Power Management|Power management module for LXQt.|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}<br />
* {{App|MATE Power Management|Power management tool for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|MATE Power Statistics|System power information and statistics for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|poweralertd|Daemon for delivering UPower notifications.|https://git.sr.ht/~kennylevinsen/poweralertd|{{AUR|poweralertd}}}}<br />
* {{App|powerkit|Desktop independent power manager.|https://github.com/rodlie/powerkit|{{AUR|powerkit}}}}<br />
* {{App|Xfce Power Manager|Power manager for Xfce.|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}<br />
* {{App|vattery|Battery monitoring application written in Vala that will display the status of a laptop battery in a system tray.|https://www.jezra.net/projects/vattery.html|{{AUR|vattery}}}}<br />
<br />
== Power management ==<br />
<br />
=== ACPI events ===<br />
<br />
''systemd'' handles some power-related [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] events, whose actions can be configured in {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} — see {{man|5|logind.conf}}. On systems with no dedicated power manager, this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
The specified action for each event can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}}, {{ic|suspend-then-hibernate}}, {{ic|lock}} or {{ic|kexec}}. In case of hibernation and suspension, they must be properly [[Power management/Suspend and hibernate|set up]]. If an event is not configured, ''systemd'' will use a default action.<br />
<br />
{| class="wikitable sortable"<br />
!Event handler<br />
!Description<br />
!Default action<br />
|-<br />
|{{ic|HandlePowerKey}}<br />
|Triggered when the power key/button is pressed.<br />
|{{ic|poweroff}}<br />
|-<br />
|{{ic|HandleSuspendKey}}<br />
|Triggered when the suspend key/button is pressed.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleHibernateKey}}<br />
|Triggered when the hibernate key/button is pressed.<br />
|{{ic|hibernate}}<br />
|-<br />
|{{ic|HandleLidSwitch}}<br />
|Triggered when the lid is closed, except in the cases below.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleLidSwitchDocked}}<br />
|Triggered when the lid is closed if the system is inserted in a docking station, or more than one display is connected.<br />
|{{ic|ignore}}<br />
|-<br />
|{{ic|HandleLidSwitchExternalPower}}<br />
|Triggered when the lid is closed if the system is connected to external power.<br />
|action set for {{ic|HandleLidSwitch}}<br />
|}<br />
<br />
To apply any changes, signal {{ic|systemd-logind}} with {{ic|HUP}}:<br />
<br />
# systemctl kill -s HUP systemd-logind<br />
<br />
{{Note|''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.}}<br />
<br />
==== Power managers ====<br />
<br />
Some [[desktop environment]]s include power managers which [https://www.freedesktop.org/wiki/Software/systemd/inhibit/ inhibit] (temporarily turn off) some or all of the ''systemd'' ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager. <br />
<br />
Note that if the power manager does not inhibit ''systemd'' for the appropriate events you can end up with a situation where ''systemd'' suspends your system and then when the system is woken up the other power manager suspends it again. The power managers of [[KDE]], [[GNOME]], [[Xfce]] and [[MATE]] issue the necessary ''inhibited'' commands. If the ''inhibited'' commands are not being issued, such as when using [[acpid]] or others to handle ACPI events, set the {{ic|Handle}} options to {{ic|ignore}}. See also {{man|1|systemd-inhibit}}.<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} subscribes to the systemd-events {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker). ''xss-lock'' also reacts to [[DPMS]] events and runs or kills the locker in response.<br />
<br />
[[Autostart]]ing the following for example:<br />
<br />
$ xss-lock -- i3lock -n -i ''background_image.png'' &<br />
<br />
=== Suspend and hibernate ===<br />
<br />
''systemd'' provides commands to suspend to RAM or hibernate using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.<br />
<br />
{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Suspend and hibernate#Hibernation]].<br />
<br />
There are also two modes combining suspend and hibernate:<br />
<br />
* {{ic|systemctl hybrid-sleep}} suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called [[Power management/Suspend and hibernate|suspend to both]].<br />
* {{ic|systemctl suspend-then-hibernate}} initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}. The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by {{ic|SuspendEstimationSec}} in {{man|5|systemd-sleep.conf}}, at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension). <br />
<br />
{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}<br />
<br />
==== Hybrid-sleep on suspend or hibernation request ====<br />
<br />
It is possible to configure systemd to always do a ''hybrid-sleep'' even on a ''suspend'' or ''hibernation'' request.<br />
<br />
The default ''suspend'' and ''hibernation'' action can be configured in the {{ic|/etc/systemd/sleep.conf}} file. To set both actions to ''hybrid-sleep'':<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
# suspend=hybrid-sleep<br />
SuspendMode=suspend<br />
SuspendState=disk<br />
# hibernate=hybrid-sleep<br />
HibernateMode=suspend<br />
HibernateState=disk<br />
}}<br />
<br />
See the {{man|5|sleep.conf.d}} manual page for details and the [https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation linux kernel documentation on power states].<br />
<br />
==== Disabling suspend ====<br />
<br />
When using a device as e.g a server, suspending might not be needed or it could even be undesired.<br />
Any sleep state can be configured:<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
AllowSuspend=no<br />
AllowHibernation=no<br />
AllowSuspendThenHibernate=no<br />
AllowHybridSleep=no<br />
}}<br />
<br />
<br />
==== Advertise hibernation despite non-active swap area ====<br />
<br />
When using for example [[#On-demand swap for hibernation only|on-demand swap for hibernation only]], desktop environments might now show the option to hibernate and {{ic|systemctl hibernate}} will not work, because these query {{ic|systemd-logind}} for the available power-saving modes and that won’t advertise hibernation unless a swap-area is active.<br />
<br />
This can be circumvented by starting {{ic|systemd-logind}} with the variable {{ic|SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK{{=}}1}} in its environment, for example via a “drop-in” directory configuration like:<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/disable-hibernation-swap-check.conf|2=<br />
[Service]<br />
Environment="SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1"<br />
}}<br />
<br />
=== Sleep hooks ===<br />
<br />
==== Suspend/resume service files ====<br />
<br />
Service files can be hooked into ''suspend.target'', ''hibernate.target'', ''sleep.target'', ''hybrid-sleep.target'' and ''suspend-then-hibernate.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. [[Enable]] the {{ic|suspend@''user''}} and {{ic|resume@''user''}} services to have them started at boot. Examples:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop<br />
ExecStart=/usr/bin/sflock<br />
ExecStartPost=/usr/bin/sleep 1<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStart=/usr/local/bin/ssh-connect.sh<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Note|As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via {{ic|1=ExecStartPost=/usr/bin/sleep 1}} helps prevent this.}}<br />
<br />
For root/system actions ([[enable]] the {{ic|root-resume}} and {{ic|root-suspend}} services to have them started at boot):<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Tip|A couple of handy hints about these service files (more in {{man|5|systemd.service}}):<br />
<br />
* If {{ic|1=Type=oneshot}} then you can use multiple {{ic|1=ExecStart=}} lines. Otherwise only one {{ic|ExecStart}} line is allowed. You can add more commands with either {{ic|ExecStartPre}} or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are ''required'').<br />
* A command prefixed with {{ic|-}} will cause a non-zero exit status to be ignored and treated as a successful command. <br />
* The best place to find errors when troubleshooting these service files is of course with [[journalctl]].<br />
}}<br />
<br />
==== Combined suspend/resume service file ====<br />
<br />
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Example and explanation:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
* {{ic|1=RemainAfterExit=yes}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=StopWhenUnneeded=yes}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after ''sleep.target'' is stopped.<br />
* Because ''sleep.target'' is pulled in by ''suspend.target'', ''hibernate.target'' and ''hybrid-sleep.target'' and because ''sleep.target'' itself is a ''StopWhenUnneeded'' service, the hook is guaranteed to start/stop properly for different tasks.<br />
<br />
===== Generic service template =====<br />
<br />
In this example, we create a [http://0pointer.net/blog/projects/instances.html template service] which we can then use to hook any existing systemd service to power events:[https://narkive.com/mYzxSIDN.6]<br />
<br />
{{hc|/etc/systemd/system/sleep@.service|2=<br />
[Unit]<br />
Description=%I sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/bin/systemctl stop %i<br />
ExecStop=-/usr/bin/systemctl start %i<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
Then [[enable]] an instance of this template by specifying the basename of an existing systemd service after the {{ic|@}}, i.e., {{ic|sleep@'''''service-file-basename'''''.service}}. See {{man|5|systemd.unit|DESCRIPTION}} for more details on templates.<br />
<br />
{{Tip|Templates are not limited to systemd services and can be used with other programs. See [https://fedoramagazine.org/systemd-template-unit-files/] for some examples.}}<br />
<br />
==== On-demand swap for hibernation only ====<br />
<br />
In some setups it might be desired to have the swap area activated only for the hibernation and deactivated again after resume.<br />
<br />
While this could be achieved via the hooks described above, it's also possible to directly use a swap unit configuration (see {{man|5|systemd.swap}}) like the following:<br />
{{hc|/etc/systemd/system/path-to-swap.swap|2=<br />
[Unit]<br />
Before=systemd-hibernate.service<br />
StopWhenUnneeded=true<br />
<br />
[Swap]<br />
What=/path/to/swap<br />
Options=noauto<br />
<br />
[Install]<br />
RequiredBy=systemd-hibernate.service<br />
}}<br />
''Note that the unit filename must correspond to the pathname of the swap device respectively file and that the unit must be enabled to have the {{ic|RequiredBy{{=}}}} take effect.''<br />
<br />
It would also be possible to depend on {{ic|hibernate.target}} rather than {{ic|systemd-hibernate.service}}, but then a direct {{ic|systemctl start systemd-hibernate.service}} would not work.<br />
<br />
==== Hooks in /usr/lib/systemd/system-sleep ====<br />
<br />
''systemd'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked<br />
<br />
''systemd'' will run these scripts concurrently and not one after another.<br />
<br />
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[journalctl]]:<br />
<br />
# journalctl -b -u systemd-suspend.service<br />
<br />
{{Note|You can also use ''sleep.target'', ''suspend.target'', ''hibernate.target'' or ''hybrid-sleep.target'' to hook units into the sleep state logic instead of using custom scripts.}}<br />
<br />
An example of a custom sleep script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac<br />
}}<br />
<br />
Do not forget to make your script [[executable]].<br />
<br />
See {{man|7|systemd.special}} and {{man|8|systemd-sleep}} for more details.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== Delayed lid switch action ====<br />
<br />
When performing lid switches in short succession, ''logind'' will delay the suspend action for up to 90s to detect possible docks. [https://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] This delay was made configurable with systemd v220:[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba]<br />
<br />
{{hc|/etc/systemd/logind.conf|2=<br />
...<br />
HoldoffTimeoutSec=30s<br />
...<br />
}}<br />
<br />
==== Suspend from corresponding laptop Fn key not working ====<br />
<br />
If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [https://lists.freedesktop.org/archives/systemd-devel/2015-February/028325.html] Do:<br />
<br />
# journalctl --grep="Watching system buttons"<br />
<br />
You might see something like this:<br />
<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)<br />
<br />
Notice no keyboard device. Now obtain ATTRS{name} for the parent keyboard device [https://systemd-devel.freedesktop.narkive.com/Rbi3rjNN/patch-1-2-logind-add-support-for-tps65217-power-button] :<br />
<br />
{{hc|# udevadm info -a /dev/input/by-path/*-kbd|2=<br />
...<br />
KERNEL=="event0"<br />
...<br />
ATTRS{name}=="AT Translated Set 2 keyboard"<br />
}}<br />
<br />
Now write a custom udev rule to add the "power-switch" tag:<br />
<br />
{{hc|/etc/udev/rules.d/70-power-switch-my.rules|2=<br />
ACTION=="remove", GOTO="power_switch_my_end"<br />
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="AT Translated Set 2 keyboard", TAG+="power-switch"<br />
LABEL="power_switch_my_end"<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-udevd.service}}, reload rules by running {{ic|udevadm trigger}} as root, and [[restart]] {{ic|systemd-logind.service}}.<br />
<br />
Now you should see {{ic|Watching system buttons on /dev/input/event0}} in syslog.<br />
<br />
==== PC will not wake from sleep on A520I and B550I motherboards ====<br />
<br />
On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD [[microcode]] package is installed.<br />
<br />
Verify the line starting with {{ic|GPP0}} has the enabled status: <br />
<br />
{{hc|$ cat /proc/acpi/wakeup|<br />
Device S-state Status Sysfs node<br />
GP12 S4 *enabled pci:0000:00:07.1<br />
GP13 S4 *enabled pci:0000:00:08.1<br />
XHC0 S4 *enabled pci:0000:0b:00.3<br />
GP30 S4 *disabled<br />
GP31 S4 *disabled<br />
PS2K S3 *disabled<br />
'''GPP0''' S4 '''*enabled''' pci:0000:00:01.1<br />
GPP8 S4 *enabled pci:0000:00:03.1<br />
PTXH S4 *enabled pci:0000:05:00.0<br />
PT20 S4 *disabled<br />
PT24 S4 *disabled<br />
PT26 S4 *disabled<br />
PT27 S4 *disabled<br />
PT28 S4 *enabled pci:0000:06:08.0<br />
PT29 S4 *enabled pci:0000:06:09.0<br />
}}<br />
<br />
If that is enabled, you can run the following command:<br />
<br />
# echo GPP0 > /proc/acpi/wakeup<br />
<br />
Now test by running {{ic|systemctl suspend}} and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. [[Create]] a systemd [[Systemd#Writing unit files|unit file]]:<br />
<br />
{{hc|/etc/systemd/system/toggle.ggp0.to.fix.suspend.issue.service|2=<br />
[Unit]<br />
Description="Disable GGP0 to fix suspend issue"<br />
<br />
[Service]<br />
ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Do a [[daemon-reload]] and [[start/enable]] the newly created unit.<br />
<br />
== Power saving ==<br />
<br />
{{Note|See [[Laptop#Power management]] for power management specific to laptops, such as battery monitoring. See also pages specific to your CPU and GPU (e.g., [[Ryzen]], [[AMDGPU]]).}}<br />
<br />
This section is a reference for creating custom scripts and power saving settings such as by udev rules. Make sure that the settings are not managed by some [[#Userspace tools|other utility]] to avoid conflicts.<br />
<br />
Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
=== Processors with Intel HWP (Intel Hardware P-state) support ===<br />
<br />
{{Merge|CPU frequency scaling|More context in the main article.}}<br />
<br />
The available energy preferences of a HWP supported processor are {{ic|default}}, {{ic|performance}}, {{ic|balance_performance}}, {{ic|balance_power}}, {{ic|power}}.<br />
<br />
This can be validated by running<br />
<br />
$ cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_available_preferences<br />
<br />
To conserve more energy, you can configuration by creating the following file:<br />
<br />
{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|<br />
w /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference - - - - balance_power<br />
}}<br />
<br />
See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
=== Audio ===<br />
<br />
==== Kernel ====<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the {{ic|power_save}} parameter; a time (in seconds) to go into idle mode. To idle the audio card after one second, create the following file for Intel soundcards.<br />
<br />
{{hc|/etc/modprobe.d/audio_powersave.conf|2=<br />
options snd_hda_intel power_save=1<br />
}}<br />
<br />
Alternatively, use the following for ac97:<br />
<br />
options snd_ac97_codec power_save=1<br />
<br />
{{Note|<br />
* To retrieve the manufacturer and the corresponding kernel driver which is used for your sound card, run {{ic|lspci -k}}.<br />
* Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.<br />
}}<br />
<br />
It is also possible to further reduce the audio power requirements by disabling the HDMI audio output, which can done by [[blacklisting]] the appropriate kernel modules (e.g. {{ic|snd_hda_codec_hdmi}} in case of Intel hardware).<br />
<br />
==== PulseAudio ====<br />
<br />
By default, PulseAudio suspends any audio sources that have become idle for too long. When using an external USB microphone, recordings may start with a pop sound. As a workaround, comment out the following line in {{ic|/etc/pulse/default.pa}}:<br />
<br />
load-module module-suspend-on-idle<br />
<br />
Afterwards, restart PulseAudio with {{ic|systemctl restart --user pulseaudio}}.<br />
<br />
=== Backlight ===<br />
<br />
See [[Backlight]].<br />
<br />
=== Bluetooth ===<br />
<br />
To disable bluetooth completely, [[blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
To turn off bluetooth only temporarily, use ''rfkill'':<br />
<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
<br />
{{hc|/etc/udev/rules.d/50-bluetooth.rules|2=<br />
# disable bluetooth<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
}}<br />
<br />
=== Web camera ===<br />
<br />
If you will not use integrated web camera then [[blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
=== Kernel parameters ===<br />
<br />
This section uses configurations in {{ic|/etc/sysctl.d/}}, which is ''"a drop-in directory for kernel sysctl parameters."'' See [http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] and more specifically {{man|5|sysctl.d}} for more information.<br />
<br />
==== Disabling NMI watchdog ====<br />
<br />
{{Expansion|This or {{ic|nowatchdog}} as can be seen in [[Improving performance#Watchdogs]]}}<br />
<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs that cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage:<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=<br />
kernel.nmi_watchdog = 0<br />
}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} to the [[kernel line]] to disable it completely from early boot.<br />
<br />
==== Writeback Time ====<br />
<br />
Increasing the virtual memory dirty writeback time helps to aggregate disk I/O together, thus reducing spanned disk writes, and increasing power saving. To set the value to 60 seconds (default is 5 seconds):<br />
<br />
{{hc|/etc/sysctl.d/dirty.conf|2=<br />
vm.dirty_writeback_centisecs = 6000<br />
}}<br />
<br />
To do the same for journal commits on supported filesystems (e.g. ext4, btrfs...), use {{ic|1=commit=60}} as a option in [[fstab]].<br />
<br />
Note that this value is modified as a side effect of the Laptop Mode setting below. See also [[sysctl#Virtual memory]] for other parameters affecting I/O performance and power saving.<br />
<br />
==== Laptop Mode ====<br />
<br />
See the [https://docs.kernel.org/admin-guide/laptops/laptop-mode.html kernel documentation] on the laptop mode "knob" - "A sensible value for the knob is 5 seconds".<br />
<br />
{{hc|/etc/sysctl.d/laptop.conf|2=<br />
vm.laptop_mode = 5<br />
}}<br />
<br />
{{Note|This setting is mainly relevant to spinning-disk drives.}}<br />
<br />
=== Network interfaces ===<br />
<br />
[[Wake-on-LAN]] can be a useful feature, but if you are not making use of it then it is simply draining extra power waiting for a magic packet while in suspend. You can adapt the [[Wake-on-LAN#udev]] rule to disable the feature for all ethernet interfaces. To enable powersaving with {{Pkg|iw}} on all wireless interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"<br />
}}<br />
<br />
The name of the configuration file is important. With the use of [[Network configuration#Change interface name|persistent device names]] in systemd, the above network rule, named lexicographically '''after''' {{ic|80-net-setup-link.rules}}, is applied after the device is renamed with a persistent name e.g. {{ic|wlan0}} renamed {{ic|wlp3s0}}. Be aware that the {{ic|RUN}} command is executed after all rules have been processed and must anyway use the persistent name, available in {{ic|$name}} for the matched device.<br />
<br />
==== Intel wireless cards (iwlwifi) ====<br />
<br />
Additional power saving functions of Intel wireless cards with {{ic|iwlwifi}} driver can be enabled by passing the correct parameters to the kernel module. Making them persistent can be achieved by adding the lines below to the {{ic|/etc/modprobe.d/iwlwifi.conf}} file:<br />
<br />
options iwlwifi power_save=1<br />
<br />
This option will probably increase your median latency:<br />
<br />
options iwlwifi uapsd_disable=0<br />
<br />
On kernels < 5.4 you can use this option, but it will probably decrease your maximum throughput:<br />
<br />
options iwlwifi d0i3_disable=0<br />
<br />
Depending on your wireless card one of these two options will apply.<br />
<br />
options iwlmvm power_scheme=3<br />
<br />
options iwldvm force_cam=0<br />
<br />
You can check which one is relevant by checking which of these modules is running using<br />
<br />
# lsmod | grep '^iwl.vm'<br />
<br />
Keep in mind that these power saving options are experimental and can cause an unstable system.<br />
<br />
=== Bus power management ===<br />
<br />
==== Active State Power Management ====<br />
<br />
If the computer is believed not to support [[Wikipedia:Active State Power Management|ASPM]] it will be disabled on boot:<br />
<br />
# lspci -vv | grep 'ASPM.*abled;'<br />
<br />
ASPM is handled by the BIOS, if ASPM is disabled it will be because [https://wireless.wiki.kernel.org/en/users/documentation/ASPM]:<br />
<br />
# The BIOS disabled it for some reason (for conflicts?).<br />
# PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).<br />
# The BIOS might not have been programmed for it.<br />
# The BIOS is buggy.<br />
<br />
If believing the computer has support for ASPM it can be forced on for the kernel to handle with the {{ic|1=pcie_aspm=force}} [[kernel parameter]].<br />
<br />
{{Warning|<br />
* Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it does not work.<br />
* On systems that do not support it forcing on ASPM can even increase power consumption.<br />
* This forces ASPM in kernel while it can still remain disabled in hardware and not work. To check whether this is the case, run {{ic|dmesg {{!}} grep ASPM}} as root. If so, consult the Wiki article specific to your hardware.<br />
}}<br />
<br />
To adjust to {{ic|powersave}} do (the following command will not work unless enabled):<br />
<br />
# echo powersave > /sys/module/pcie_aspm/parameters/policy<br />
<br />
By default it looks like this:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|<br />
[default] performance powersave powersupersave<br />
}}<br />
<br />
==== PCI Runtime Power Management ====<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
}}<br />
<br />
The rule above powers all unused devices down, but some devices will not wake up again. To allow runtime power management only for devices that are known to work, use simple matching against vendor and device IDs (use {{ic|lspci -nn}} to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# whitelist for pci autosuspend<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with PCI runtime power management and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# blacklist for pci runtime power management<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"<br />
<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
LABEL="pci_pm_end"<br />
}}<br />
<br />
==== USB autosuspend ====<br />
<br />
The Linux kernel can automatically suspend USB devices when they are not in use. This can sometimes save quite a bit of power, however some USB devices are not compatible with USB power saving and start to misbehave (common for USB mice/keyboards). [[udev]] rules based on whitelist or blacklist filtering can help to mitigate the problem.<br />
<br />
The most simple and likely useless example is enabling autosuspend for all USB devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
}}<br />
<br />
To allow autosuspend only for devices that are known to work, use simple matching against vendor and product IDs (use ''lsusb'' to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# whitelist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with USB autosuspend and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# blacklist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"<br />
<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
LABEL="power_usb_rules_end"<br />
}}<br />
<br />
The default autosuspend idle delay time is controlled by the {{ic|autosuspend}} parameter of the {{ic|usbcore}} built-in [[kernel module]]. To set the delay to 5 seconds instead of the default 2 seconds, add the following [[kernel parameter]] for your boot loader.<br />
<br />
{{bc|1=usbcore.autosuspend=5}}<br />
<br />
Similarly to {{ic|power/control}}, the delay time can be fine-tuned per device by setting the {{ic|power/autosuspend}} attribute. This means, alternatively, autosuspend can be disabled by setting {{ic|power/autosuspend}} to -1 (i.e., never autosuspend):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"<br />
}}<br />
<br />
See the [https://docs.kernel.org/driver-api/usb/power-management.html Linux kernel documentation] for more information on USB power management.<br />
<br />
==== SATA Active Link Power Management ====<br />
<br />
{{Warning|SATA Active Link Power Management can lead to data loss on some devices. Do not enable this setting unless you have frequent backups.}}<br />
<br />
{{Out of date|Phrases like "new setting" and "will become a default setting" are outdated. Also should be more formal. See [[Help:Style#Language register]].}}<br />
<br />
Since Linux 4.15 there is a [https://hansdegoede.livejournal.com/18412.html new setting] called {{ic|med_power_with_dipm}} that matches the behaviour of Windows IRST driver settings and should not cause data loss with recent SSD/HDD drives. The power saving can be significant, ranging [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b from 1.0 to 1.5 Watts (when idle)]. It will become a default setting for Intel based laptops in Linux 4.16 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b].<br />
<br />
The current setting can be read from {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} as follows:<br />
<br />
$ cat /sys/class/scsi_host/host*/link_power_management_policy<br />
<br />
{| class="wikitable"<br />
|+ Available ALPM settings<br />
! Setting<br />
! Description<br />
! Power saving<br />
|-<br />
| max_performance<br />
| current default<br />
| None<br />
|-<br />
| medium_power<br />
| -<br />
| ~1.0 Watts<br />
|-<br />
| med_power_with_dipm<br />
| recommended setting<br />
| ~1.5 Watts<br />
|-<br />
| min_power<br />
| '''WARNING: possible data loss'''<br />
| ~1.5 Watts<br />
|}<br />
<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"<br />
}}<br />
<br />
{{Note|This adds latency when accessing a drive that has been idle, so it is one of the few settings that may be worth toggling based on whether you are on AC power.}}<br />
<br />
=== Hard disk drive ===<br />
<br />
See [[hdparm#Power management configuration]] for drive parameters that can be set.<br />
<br />
Power saving is not effective when too many programs are frequently writing to the disk. Tracking all programs, and how and when they write to disk is the way to limit disk usage. Use {{Pkg|iotop}} to see which programs use the disk frequently. See [[Improving performance#Storage devices]] for other tips.<br />
<br />
Also little things like setting the [[Fstab#atime options|noatime]] option can help. If enough RAM is available, consider disabling or limiting [[swappiness]] as it has the possibility to limit a good number of disk writes.<br />
<br />
== Tools and scripts ==<br />
<br />
{{Style|Merged from [[Power saving]], needs reorganization to fit into this page.}}<br />
<br />
=== Using a script and an udev rule ===<br />
<br />
{{Merge|Laptop#Power management|Might be a better fit for the laptop-specific page.}}<br />
<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove ''pm-utils'' and [[acpid]]. There is just one thing systemd cannot do (as of systemd-204): power management depending on whether the system is running on AC or battery. To fill this gap, you can create a single [[udev]] rule that runs a script when the AC adapter is plugged and unplugged:<br />
<br />
{{hc|/etc/udev/rules.d/powersave.rules|2=<br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
}}<br />
<br />
{{Note|You can use the same script that ''pm-powersave'' uses. You just have to make it executable and place it somewhere else (for example {{ic|/usr/local/bin/}}).}}<br />
<br />
Examples of powersave scripts:<br />
<br />
* [https://github.com/supplantr/ftw ftw], package: {{AUR|ftw-git}}<br />
* [https://github.com/Unia/powersave powersave]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=180762 throttlectl], from {{AUR|throttlectl}}<br />
<br />
The above udev rule should work as expected, but if your power settings are not updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online {{!}} grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac<br />
exit 0<br />
}}<br />
<br />
Do not forget to make it executable!<br />
<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
=== Print power settings ===<br />
<br />
{{Merge|#Power saving|Might be good as an introduction? Since most of the output of the script can be used by the following sections.}}<br />
<br />
This script prints power settings and a variety of other properties for USB and PCI devices. Note that root permissions are needed to see all settings.<br />
<br />
{{bc|1=<br />
#!/bin/bash<br />
<br />
for i in $(find /sys/devices -name "bMaxPower")<br />
do<br />
busdir=${i%/*}<br />
busnum=$(<$busdir/busnum)<br />
devnum=$(<$busdir/devnum)<br />
title=$(lsusb -s $busnum:$devnum)<br />
<br />
printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"<br />
<br />
for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)<br />
do<br />
v=$(cat $ff 2>/dev/null{{!}}tr -d "\n")<br />
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";<br />
v=;<br />
done {{!}} sort -g;<br />
done;<br />
<br />
printf "\n\n\n+++ %s\n" "Kernel Modules"<br />
for mod in $(lspci -k {{!}} sed -n '/in use:/s,^.*: ,,p' {{!}} sort -u)<br />
do<br />
echo "+ $mod";<br />
systool -v -m $mod 2> /dev/null {{!}} sed -n "/Parameters:/,/^$/p";<br />
done<br />
}}<br />
<br />
== Allow users to shutdown ==<br />
<br />
{{Style|Merged from [[Allow users to shutdown]], needs reorganization to fit into this page.}}<br />
<br />
=== Button and lid events ===<br />
<br />
The suspend, poweroff and hibernate button presses and lid close events are handled by ''logind'' as described in [[#ACPI events]].<br />
<br />
=== Using systemd-logind ===<br />
<br />
If you are using {{Pkg|polkit}}, users with non-remote session can issue power-related commands as long as [[General troubleshooting#Session permissions|the session is not broken]].<br />
<br />
To check if your session is active<br />
$ loginctl show-session $XDG_SESSION_ID --property=Active<br />
<br />
The user can then use ''systemctl'' commands in the command line, or add them to menus:<br />
$ systemctl poweroff<br />
$ systemctl reboot<br />
<br />
Other commands can be used as well, including {{ic|systemctl suspend}} and {{ic|systemctl hibernate}}. See the ''System Commands'' section in {{man|1|systemctl}}.<br />
<br />
=== Using sudo ===<br />
<br />
[[Install]] {{Pkg|sudo}}, and give the user [[sudo|sudo privileges]]. The user will then be able to use the {{ic|sudo systemctl}} commands (e.g. {{ic|sudo systemctl poweroff}}, {{ic|sudo systemctl reboot}}, {{ic|sudo systemctl suspend}} and {{ic|sudo systemctl hibernate}}). See the ''System Commands'' section in {{man|1|systemctl}}<br />
<br />
==== Users without sudo privileges ====<br />
<br />
If users should only be allowed to use shutdown commands, but not have other sudo privileges, then, as root, add the following to the end of {{ic|/etc/sudoers}} using the {{ic|visudo}} command. Substitute ''user'' for your username and ''hostname'' for the machine's hostname.<br />
<br />
''user'' ''hostname'' =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot<br />
<br />
Now your user can shutdown with {{ic|sudo systemctl poweroff}}, and reboot with {{ic|sudo systemctl reboot}}. Users wishing to power down a system can also use {{ic|sudo systemctl halt}}. Use the {{ic|NOPASSWD:}} tag only if you do not want to be prompted for your password.<br />
<br />
== See also ==<br />
<br />
* [https://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]<br />
* [https://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]</div>Calestyohttps://wiki.archlinux.org/index.php?title=Power_management&diff=774235Power management2023-03-30T11:21:10Z<p>Calestyo: describe how to activate swap on demand for hibernation only</p>
<hr />
<div>[[Category:Power management]]<br />
[[es:Power management]]<br />
[[ja:電源管理]]<br />
[[ru:Power management]]<br />
[[zh-hans:Power management]]<br />
{{Related articles start}}<br />
{{Related|Power management/Suspend and hibernate}}<br />
{{Related|Power management/Wakeup triggers}}<br />
{{Related|Display Power Management Signaling}}<br />
{{Related|CPU frequency scaling}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Kernel modules}}<br />
{{Related|sysctl}}<br />
{{Related|udev}}<br />
{{Related articles end}}<br />
[[Wikipedia:Power management|Power management]] is a feature that turns off the power or switches system components to a low-power state when inactive.<br />
<br />
In Arch Linux, power management consists of two main parts:<br />
<br />
# Configuration of the Linux kernel, which interacts with the hardware.<br />
#* [[Kernel parameters]]<br />
#* [[Kernel modules]]<br />
#* [[udev]] rules<br />
# Configuration of userspace tools, which interact with the kernel and react to its events. Many userspace tools also allow to modify kernel configuration in a "user-friendly" way. See [[#Userspace tools]] for the options.<br />
<br />
== Userspace tools ==<br />
<br />
Using these tools can replace setting a lot of settings by hand. Only run '''one''' of these tools to avoid possible conflicts as they all work more or less similarly. Have a look at the [[:Category:Power management|power management category]] to get an overview on what power management options exist in Arch Linux.<br />
<br />
These are the more popular scripts and tools designed to help power saving:<br />
<br />
=== Console ===<br />
<br />
* {{App|[[acpid]]| A daemon for delivering ACPI power management events with netlink support.|https://sourceforge.net/projects/acpid2/|{{Pkg|acpid}}}}<br />
* {{App|[[Laptop Mode Tools]]|Utility to configure laptop power saving settings, considered by many to be the de facto utility for power saving though may take a bit of configuration.|https://github.com/rickysarraf/laptop-mode-tools|{{AUR|laptop-mode-tools}}}}<br />
* {{App|libsmbios|Library and tools for interacting with Dell SMBIOS tables.|https://github.com/dell/libsmbios|{{Pkg|libsmbios}}}}<br />
* {{App|[[powertop]]|A tool to diagnose issues with power consumption and power management to help set power saving settings.|https://01.org/powertop/|{{Pkg|powertop}}}}<br />
* {{App|[[systemd]]|A system and service manager.|https://freedesktop.org/wiki/Software/systemd/|{{Pkg|systemd}}}}<br />
* {{App|[[TLP]]|Advanced power management for Linux.|https://linrunner.de/tlp|{{Pkg|tlp}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|batsignal|Lightweight battery monitor that uses libnotify to warn of low battery levels.|https://github.com/electrickite/batsignal|{{AUR|batsignal}}}}<br />
* {{App|cbatticon|Lightweight and fast battery icon that sits in your system tray.|https://github.com/valr/cbatticon|{{Pkg|cbatticon}}}}<br />
* {{App|GNOME Power Statistics|System power information and statistics for GNOME.|https://gitlab.gnome.org/GNOME/gnome-power-manager|{{Pkg|gnome-power-manager}}}}<br />
* {{App|KDE Power Devil|Power management module for Plasma.|https://invent.kde.org/plasma/powerdevil|{{Pkg|powerdevil}}}}<br />
* {{App|LXQt Power Management|Power management module for LXQt.|https://github.com/lxqt/lxqt-powermanagement|{{Pkg|lxqt-powermanagement}}}}<br />
* {{App|MATE Power Management|Power management tool for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|MATE Power Statistics|System power information and statistics for MATE.|https://github.com/mate-desktop/mate-power-manager|{{Pkg|mate-power-manager}}}}<br />
* {{App|poweralertd|Daemon for delivering UPower notifications.|https://git.sr.ht/~kennylevinsen/poweralertd|{{AUR|poweralertd}}}}<br />
* {{App|powerkit|Desktop independent power manager.|https://github.com/rodlie/powerkit|{{AUR|powerkit}}}}<br />
* {{App|Xfce Power Manager|Power manager for Xfce.|https://docs.xfce.org/xfce/xfce4-power-manager/start|{{Pkg|xfce4-power-manager}}}}<br />
* {{App|vattery|Battery monitoring application written in Vala that will display the status of a laptop battery in a system tray.|https://www.jezra.net/projects/vattery.html|{{AUR|vattery}}}}<br />
<br />
== Power management ==<br />
<br />
=== ACPI events ===<br />
<br />
''systemd'' handles some power-related [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] events, whose actions can be configured in {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} — see {{man|5|logind.conf}}. On systems with no dedicated power manager, this may replace the [[acpid]] daemon which is usually used to react to these ACPI events.<br />
<br />
The specified action for each event can be one of {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}}, {{ic|hybrid-sleep}}, {{ic|suspend-then-hibernate}}, {{ic|lock}} or {{ic|kexec}}. In case of hibernation and suspension, they must be properly [[Power management/Suspend and hibernate|set up]]. If an event is not configured, ''systemd'' will use a default action.<br />
<br />
{| class="wikitable sortable"<br />
!Event handler<br />
!Description<br />
!Default action<br />
|-<br />
|{{ic|HandlePowerKey}}<br />
|Triggered when the power key/button is pressed.<br />
|{{ic|poweroff}}<br />
|-<br />
|{{ic|HandleSuspendKey}}<br />
|Triggered when the suspend key/button is pressed.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleHibernateKey}}<br />
|Triggered when the hibernate key/button is pressed.<br />
|{{ic|hibernate}}<br />
|-<br />
|{{ic|HandleLidSwitch}}<br />
|Triggered when the lid is closed, except in the cases below.<br />
|{{ic|suspend}}<br />
|-<br />
|{{ic|HandleLidSwitchDocked}}<br />
|Triggered when the lid is closed if the system is inserted in a docking station, or more than one display is connected.<br />
|{{ic|ignore}}<br />
|-<br />
|{{ic|HandleLidSwitchExternalPower}}<br />
|Triggered when the lid is closed if the system is connected to external power.<br />
|action set for {{ic|HandleLidSwitch}}<br />
|}<br />
<br />
To apply any changes, signal {{ic|systemd-logind}} with {{ic|HUP}}:<br />
<br />
# systemctl kill -s HUP systemd-logind<br />
<br />
{{Note|''systemd'' cannot handle AC and Battery ACPI events, so if you use [[Laptop Mode Tools]] or other similar tools [[acpid]] is still required.}}<br />
<br />
==== Power managers ====<br />
<br />
Some [[desktop environment]]s include power managers which [https://www.freedesktop.org/wiki/Software/systemd/inhibit/ inhibit] (temporarily turn off) some or all of the ''systemd'' ACPI settings. If such a power manager is running, then the actions for ACPI events can be configured in the power manager alone. Changes to {{ic|/etc/systemd/logind.conf}} or {{ic|/etc/systemd/logind.conf.d/*.conf}} need be made only if you wish to configure behaviour for a particular event that is not inhibited by the power manager. <br />
<br />
Note that if the power manager does not inhibit ''systemd'' for the appropriate events you can end up with a situation where ''systemd'' suspends your system and then when the system is woken up the other power manager suspends it again. The power managers of [[KDE]], [[GNOME]], [[Xfce]] and [[MATE]] issue the necessary ''inhibited'' commands. If the ''inhibited'' commands are not being issued, such as when using [[acpid]] or others to handle ACPI events, set the {{ic|Handle}} options to {{ic|ignore}}. See also {{man|1|systemd-inhibit}}.<br />
<br />
==== xss-lock ====<br />
<br />
{{pkg|xss-lock}} subscribes to the systemd-events {{ic|suspend}}, {{ic|hibernate}}, {{ic|lock-session}}, and {{ic|unlock-session}} with appropriate actions (run locker and wait for user to unlock or kill locker). ''xss-lock'' also reacts to [[DPMS]] events and runs or kills the locker in response.<br />
<br />
[[Autostart]]ing the following for example:<br />
<br />
$ xss-lock -- i3lock -n -i ''background_image.png'' &<br />
<br />
=== Suspend and hibernate ===<br />
<br />
''systemd'' provides commands to suspend to RAM or hibernate using the kernel's native suspend/resume functionality. There are also mechanisms to add hooks to customize pre- and post-suspend actions.<br />
<br />
{{ic|systemctl suspend}} should work out of the box, for {{ic|systemctl hibernate}} to work on your system you need to follow the instructions at [[Suspend and hibernate#Hibernation]].<br />
<br />
There are also two modes combining suspend and hibernate:<br />
<br />
* {{ic|systemctl hybrid-sleep}} suspends the system both to RAM and disk, so a complete power loss does not result in lost data. This mode is also called [[Power management/Suspend and hibernate|suspend to both]].<br />
* {{ic|systemctl suspend-then-hibernate}} initially suspends the system to RAM as long as possible, then wakes it with an RTC alarm and hibernates. The RTC alarm is set with {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}. The default value is set by estimating the battery discharge rate to keep the system with 5% of battery, or two hours without one. Said estimation is obtained from the change in battery level after the time specified by {{ic|SuspendEstimationSec}} in {{man|5|systemd-sleep.conf}}, at which the system will briefly wake up to do the measurement (a measure is also made if the system is manually woken up from suspension). <br />
<br />
{{Note|''systemd'' can also use other suspend backends (such as [[Uswsusp]]), in addition to the default ''kernel'' backend, in order to put the computer to sleep or hibernate. See [[Uswsusp#With systemd]] for an example.}}<br />
<br />
==== Hybrid-sleep on suspend or hibernation request ====<br />
<br />
It is possible to configure systemd to always do a ''hybrid-sleep'' even on a ''suspend'' or ''hibernation'' request.<br />
<br />
The default ''suspend'' and ''hibernation'' action can be configured in the {{ic|/etc/systemd/sleep.conf}} file. To set both actions to ''hybrid-sleep'':<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
# suspend=hybrid-sleep<br />
SuspendMode=suspend<br />
SuspendState=disk<br />
# hibernate=hybrid-sleep<br />
HibernateMode=suspend<br />
HibernateState=disk<br />
}}<br />
<br />
See the {{man|5|sleep.conf.d}} manual page for details and the [https://docs.kernel.org/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation linux kernel documentation on power states].<br />
<br />
==== Disabling suspend ====<br />
<br />
When using a device as e.g a server, suspending might not be needed or it could even be undesired.<br />
Any sleep state can be configured:<br />
<br />
{{hc|/etc/systemd/sleep.conf|2=<br />
[Sleep]<br />
AllowSuspend=no<br />
AllowHibernation=no<br />
AllowSuspendThenHibernate=no<br />
AllowHybridSleep=no<br />
}}<br />
<br />
=== Sleep hooks ===<br />
<br />
==== Suspend/resume service files ====<br />
<br />
Service files can be hooked into ''suspend.target'', ''hibernate.target'', ''sleep.target'', ''hybrid-sleep.target'' and ''suspend-then-hibernate.target'' to execute actions before or after suspend/hibernate. Separate files should be created for user actions and root/system actions. [[Enable]] the {{ic|suspend@''user''}} and {{ic|resume@''user''}} services to have them started at boot. Examples:<br />
<br />
{{hc|/etc/systemd/system/suspend@.service|2=<br />
[Unit]<br />
Description=User suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
User=%I<br />
Type=forking<br />
Environment=DISPLAY=:0<br />
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop<br />
ExecStart=/usr/bin/sflock<br />
ExecStartPost=/usr/bin/sleep 1<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<br />
[Unit]<br />
Description=User resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=simple<br />
ExecStart=/usr/local/bin/ssh-connect.sh<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Note|As screen lockers may return before the screen is "locked", the screen may flash on resuming from suspend. Adding a small delay via {{ic|1=ExecStartPost=/usr/bin/sleep 1}} helps prevent this.}}<br />
<br />
For root/system actions ([[enable]] the {{ic|root-resume}} and {{ic|root-suspend}} services to have them started at boot):<br />
<br />
{{hc|/etc/systemd/system/root-suspend.service|2=<br />
[Unit]<br />
Description=Local system suspend actions<br />
Before=sleep.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=-/usr/bin/pkill sshfs<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<br />
[Unit]<br />
Description=Local system resume actions<br />
After=suspend.target<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemctl restart mnt-media.automount<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
}}<br />
<br />
{{Tip|A couple of handy hints about these service files (more in {{man|5|systemd.service}}):<br />
<br />
* If {{ic|1=Type=oneshot}} then you can use multiple {{ic|1=ExecStart=}} lines. Otherwise only one {{ic|ExecStart}} line is allowed. You can add more commands with either {{ic|ExecStartPre}} or by separating commands with a semicolon (see the first example above; note the spaces before and after the semicolon, as they are ''required'').<br />
* A command prefixed with {{ic|-}} will cause a non-zero exit status to be ignored and treated as a successful command. <br />
* The best place to find errors when troubleshooting these service files is of course with [[journalctl]].<br />
}}<br />
<br />
==== Combined suspend/resume service file ====<br />
<br />
With the combined suspend/resume service file, a single hook does all the work for different phases (sleep/resume) and for different targets (suspend/hibernate/hybrid-sleep).<br />
<br />
Example and explanation:<br />
<br />
{{hc|/etc/systemd/system/wicd-sleep.service|2=<br />
[Unit]<br />
Description=Wicd sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/share/wicd/daemon/suspend.py<br />
ExecStop=-/usr/share/wicd/daemon/autoconnect.py<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
* {{ic|1=RemainAfterExit=yes}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=StopWhenUnneeded=yes}}: When active, the service will be stopped if no other active service requires it. In this specific example, it will be stopped after ''sleep.target'' is stopped.<br />
* Because ''sleep.target'' is pulled in by ''suspend.target'', ''hibernate.target'' and ''hybrid-sleep.target'' and because ''sleep.target'' itself is a ''StopWhenUnneeded'' service, the hook is guaranteed to start/stop properly for different tasks.<br />
<br />
===== Generic service template =====<br />
<br />
In this example, we create a [http://0pointer.net/blog/projects/instances.html template service] which we can then use to hook any existing systemd service to power events:[https://narkive.com/mYzxSIDN.6]<br />
<br />
{{hc|/etc/systemd/system/sleep@.service|2=<br />
[Unit]<br />
Description=%I sleep hook<br />
Before=sleep.target<br />
StopWhenUnneeded=yes<br />
<br />
[Service]<br />
Type=oneshot<br />
RemainAfterExit=yes<br />
ExecStart=-/usr/bin/systemctl stop %i<br />
ExecStop=-/usr/bin/systemctl start %i<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
Then [[enable]] an instance of this template by specifying the basename of an existing systemd service after the {{ic|@}}, i.e., {{ic|sleep@'''''service-file-basename'''''.service}}. See {{man|5|systemd.unit|DESCRIPTION}} for more details on templates.<br />
<br />
{{Tip|Templates are not limited to systemd services and can be used with other programs. See [https://fedoramagazine.org/systemd-template-unit-files/] for some examples.}}<br />
<br />
==== On-demand swap for hibernation only ====<br />
<br />
In some setups it might be desired to have the swap area activated only for the hibernation and deactivated again after resume.<br />
<br />
While this could be achieved via the hooks described above, it's also possible to directly use a swap unit configuration (see {{man|5|systemd.swap}}) like the following:<br />
{{hc|/etc/systemd/system/path-to-swap.swap|2=<br />
[Unit]<br />
Before=systemd-hibernate.service<br />
StopWhenUnneeded=true<br />
<br />
[Swap]<br />
What=/path/to/swap<br />
Options=noauto<br />
<br />
[Install]<br />
RequiredBy=systemd-hibernate.service<br />
}}<br />
''Note that the unit filename must correspond to the pathname of the swap device respectively file and that the unit must be enabled to have the {{ic|RequiredBy{{=}}}} take effect.''<br />
<br />
It would also be possible to depend on {{ic|hibernate.target}} rather than {{ic|systemd-hibernate.service}}, but then a direct {{ic|systemctl start systemd-hibernate.service}} would not work.<br />
<br />
==== Hooks in /usr/lib/systemd/system-sleep ====<br />
<br />
''systemd'' runs all executables in {{ic|/usr/lib/systemd/system-sleep/}}, passing two arguments to each of them:<br />
<br />
* Argument 1: either {{ic|pre}} or {{ic|post}}, depending on whether the machine is going to sleep or waking up<br />
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} or {{ic|hybrid-sleep}}, depending on which is being invoked<br />
<br />
''systemd'' will run these scripts concurrently and not one after another.<br />
<br />
The output of any custom script will be logged by ''systemd-suspend.service'', ''systemd-hibernate.service'' or ''systemd-hybrid-sleep.service''. You can see its output in ''systemd''<nowiki>'</nowiki>s [[journalctl]]:<br />
<br />
# journalctl -b -u systemd-suspend.service<br />
<br />
{{Note|You can also use ''sleep.target'', ''suspend.target'', ''hibernate.target'' or ''hybrid-sleep.target'' to hook units into the sleep state logic instead of using custom scripts.}}<br />
<br />
An example of a custom sleep script:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/example.sh|<br />
#!/bin/sh<br />
case $1/$2 in<br />
pre/*)<br />
echo "Going to $2..."<br />
;;<br />
post/*)<br />
echo "Waking up from $2..."<br />
;;<br />
esac<br />
}}<br />
<br />
Do not forget to make your script [[executable]].<br />
<br />
See {{man|7|systemd.special}} and {{man|8|systemd-sleep}} for more details.<br />
<br />
=== Troubleshooting ===<br />
<br />
==== Delayed lid switch action ====<br />
<br />
When performing lid switches in short succession, ''logind'' will delay the suspend action for up to 90s to detect possible docks. [https://lists.freedesktop.org/archives/systemd-devel/2015-January/027131.html] This delay was made configurable with systemd v220:[https://github.com/systemd/systemd/commit/9d10cbee89ca7f82d29b9cb27bef11e23e3803ba]<br />
<br />
{{hc|/etc/systemd/logind.conf|2=<br />
...<br />
HoldoffTimeoutSec=30s<br />
...<br />
}}<br />
<br />
==== Suspend from corresponding laptop Fn key not working ====<br />
<br />
If, regardless of the setting in logind.conf, the sleep button does not work (pressing it does not even produce a message in syslog), then logind is probably not watching the keyboard device. [https://lists.freedesktop.org/archives/systemd-devel/2015-February/028325.html] Do:<br />
<br />
# journalctl --grep="Watching system buttons"<br />
<br />
You might see something like this:<br />
<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event2 (Power Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event3 (Sleep Button)<br />
May 25 21:28:19 vmarch.lan systemd-logind[210]: Watching system buttons on /dev/input/event4 (Video Bus)<br />
<br />
Notice no keyboard device. Now obtain ATTRS{name} for the parent keyboard device [https://systemd-devel.freedesktop.narkive.com/Rbi3rjNN/patch-1-2-logind-add-support-for-tps65217-power-button] :<br />
<br />
{{hc|# udevadm info -a /dev/input/by-path/*-kbd|2=<br />
...<br />
KERNEL=="event0"<br />
...<br />
ATTRS{name}=="AT Translated Set 2 keyboard"<br />
}}<br />
<br />
Now write a custom udev rule to add the "power-switch" tag:<br />
<br />
{{hc|/etc/udev/rules.d/70-power-switch-my.rules|2=<br />
ACTION=="remove", GOTO="power_switch_my_end"<br />
SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="AT Translated Set 2 keyboard", TAG+="power-switch"<br />
LABEL="power_switch_my_end"<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-udevd.service}}, reload rules by running {{ic|udevadm trigger}} as root, and [[restart]] {{ic|systemd-logind.service}}.<br />
<br />
Now you should see {{ic|Watching system buttons on /dev/input/event0}} in syslog.<br />
<br />
==== PC will not wake from sleep on A520I and B550I motherboards ====<br />
<br />
On some motherboards with A520i and B550i chipsets, the system will not completely enter the sleep state or come out of it. Symptoms include the system entering sleep and the monitor turning off while internal LEDs on the motherboard or the power LED stay on. Subsequently, the system will not come back from this state and require a hard power off. If you have similar issues with AMD, first make sure your system is fully updated and check whether the AMD [[microcode]] package is installed.<br />
<br />
Verify the line starting with {{ic|GPP0}} has the enabled status: <br />
<br />
{{hc|$ cat /proc/acpi/wakeup|<br />
Device S-state Status Sysfs node<br />
GP12 S4 *enabled pci:0000:00:07.1<br />
GP13 S4 *enabled pci:0000:00:08.1<br />
XHC0 S4 *enabled pci:0000:0b:00.3<br />
GP30 S4 *disabled<br />
GP31 S4 *disabled<br />
PS2K S3 *disabled<br />
'''GPP0''' S4 '''*enabled''' pci:0000:00:01.1<br />
GPP8 S4 *enabled pci:0000:00:03.1<br />
PTXH S4 *enabled pci:0000:05:00.0<br />
PT20 S4 *disabled<br />
PT24 S4 *disabled<br />
PT26 S4 *disabled<br />
PT27 S4 *disabled<br />
PT28 S4 *enabled pci:0000:06:08.0<br />
PT29 S4 *enabled pci:0000:06:09.0<br />
}}<br />
<br />
If that is enabled, you can run the following command:<br />
<br />
# echo GPP0 > /proc/acpi/wakeup<br />
<br />
Now test by running {{ic|systemctl suspend}} and let the system go to sleep. Then try to wake the system after a few seconds. If it works, you can make the workaround permanent. [[Create]] a systemd [[Systemd#Writing unit files|unit file]]:<br />
<br />
{{hc|/etc/systemd/system/toggle.ggp0.to.fix.suspend.issue.service|2=<br />
[Unit]<br />
Description="Disable GGP0 to fix suspend issue"<br />
<br />
[Service]<br />
ExecStart=/bin/sh -c "/bin/echo GPP0 > /proc/acpi/wakeup"<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Do a [[daemon-reload]] and [[start/enable]] the newly created unit.<br />
<br />
== Power saving ==<br />
<br />
{{Note|See [[Laptop#Power management]] for power management specific to laptops, such as battery monitoring. See also pages specific to your CPU and GPU (e.g., [[Ryzen]], [[AMDGPU]]).}}<br />
<br />
This section is a reference for creating custom scripts and power saving settings such as by udev rules. Make sure that the settings are not managed by some [[#Userspace tools|other utility]] to avoid conflicts.<br />
<br />
Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
=== Processors with Intel HWP (Intel Hardware P-state) support ===<br />
<br />
{{Merge|CPU frequency scaling|More context in the main article.}}<br />
<br />
The available energy preferences of a HWP supported processor are {{ic|default}}, {{ic|performance}}, {{ic|balance_performance}}, {{ic|balance_power}}, {{ic|power}}.<br />
<br />
This can be validated by running<br />
<br />
$ cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_available_preferences<br />
<br />
To conserve more energy, you can configuration by creating the following file:<br />
<br />
{{hc|/etc/tmpfiles.d/energy_performance_preference.conf|<br />
w /sys/devices/system/cpu/cpufreq/policy?/energy_performance_preference - - - - balance_power<br />
}}<br />
<br />
See the {{man|8|systemd-tmpfiles}} and {{man|5|tmpfiles.d}} man pages for details.<br />
<br />
=== Audio ===<br />
<br />
==== Kernel ====<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the {{ic|power_save}} parameter; a time (in seconds) to go into idle mode. To idle the audio card after one second, create the following file for Intel soundcards.<br />
<br />
{{hc|/etc/modprobe.d/audio_powersave.conf|2=<br />
options snd_hda_intel power_save=1<br />
}}<br />
<br />
Alternatively, use the following for ac97:<br />
<br />
options snd_ac97_codec power_save=1<br />
<br />
{{Note|<br />
* To retrieve the manufacturer and the corresponding kernel driver which is used for your sound card, run {{ic|lspci -k}}.<br />
* Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.<br />
}}<br />
<br />
It is also possible to further reduce the audio power requirements by disabling the HDMI audio output, which can done by [[blacklisting]] the appropriate kernel modules (e.g. {{ic|snd_hda_codec_hdmi}} in case of Intel hardware).<br />
<br />
==== PulseAudio ====<br />
<br />
By default, PulseAudio suspends any audio sources that have become idle for too long. When using an external USB microphone, recordings may start with a pop sound. As a workaround, comment out the following line in {{ic|/etc/pulse/default.pa}}:<br />
<br />
load-module module-suspend-on-idle<br />
<br />
Afterwards, restart PulseAudio with {{ic|systemctl restart --user pulseaudio}}.<br />
<br />
=== Backlight ===<br />
<br />
See [[Backlight]].<br />
<br />
=== Bluetooth ===<br />
<br />
To disable bluetooth completely, [[blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
To turn off bluetooth only temporarily, use ''rfkill'':<br />
<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
<br />
{{hc|/etc/udev/rules.d/50-bluetooth.rules|2=<br />
# disable bluetooth<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
}}<br />
<br />
=== Web camera ===<br />
<br />
If you will not use integrated web camera then [[blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
=== Kernel parameters ===<br />
<br />
This section uses configurations in {{ic|/etc/sysctl.d/}}, which is ''"a drop-in directory for kernel sysctl parameters."'' See [http://0pointer.de/blog/projects/the-new-configuration-files The New Configuration Files] and more specifically {{man|5|sysctl.d}} for more information.<br />
<br />
==== Disabling NMI watchdog ====<br />
<br />
{{Expansion|This or {{ic|nowatchdog}} as can be seen in [[Improving performance#Watchdogs]]}}<br />
<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs that cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage:<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=<br />
kernel.nmi_watchdog = 0<br />
}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} to the [[kernel line]] to disable it completely from early boot.<br />
<br />
==== Writeback Time ====<br />
<br />
Increasing the virtual memory dirty writeback time helps to aggregate disk I/O together, thus reducing spanned disk writes, and increasing power saving. To set the value to 60 seconds (default is 5 seconds):<br />
<br />
{{hc|/etc/sysctl.d/dirty.conf|2=<br />
vm.dirty_writeback_centisecs = 6000<br />
}}<br />
<br />
To do the same for journal commits on supported filesystems (e.g. ext4, btrfs...), use {{ic|1=commit=60}} as a option in [[fstab]].<br />
<br />
Note that this value is modified as a side effect of the Laptop Mode setting below. See also [[sysctl#Virtual memory]] for other parameters affecting I/O performance and power saving.<br />
<br />
==== Laptop Mode ====<br />
<br />
See the [https://docs.kernel.org/admin-guide/laptops/laptop-mode.html kernel documentation] on the laptop mode "knob" - "A sensible value for the knob is 5 seconds".<br />
<br />
{{hc|/etc/sysctl.d/laptop.conf|2=<br />
vm.laptop_mode = 5<br />
}}<br />
<br />
{{Note|This setting is mainly relevant to spinning-disk drives.}}<br />
<br />
=== Network interfaces ===<br />
<br />
[[Wake-on-LAN]] can be a useful feature, but if you are not making use of it then it is simply draining extra power waiting for a magic packet while in suspend. You can adapt the [[Wake-on-LAN#udev]] rule to disable the feature for all ethernet interfaces. To enable powersaving with {{Pkg|iw}} on all wireless interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/'''81'''-wifi-powersave.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wl*", RUN+="/usr/bin/iw dev $name set power_save on"<br />
}}<br />
<br />
The name of the configuration file is important. With the use of [[Network configuration#Change interface name|persistent device names]] in systemd, the above network rule, named lexicographically '''after''' {{ic|80-net-setup-link.rules}}, is applied after the device is renamed with a persistent name e.g. {{ic|wlan0}} renamed {{ic|wlp3s0}}. Be aware that the {{ic|RUN}} command is executed after all rules have been processed and must anyway use the persistent name, available in {{ic|$name}} for the matched device.<br />
<br />
==== Intel wireless cards (iwlwifi) ====<br />
<br />
Additional power saving functions of Intel wireless cards with {{ic|iwlwifi}} driver can be enabled by passing the correct parameters to the kernel module. Making them persistent can be achieved by adding the lines below to the {{ic|/etc/modprobe.d/iwlwifi.conf}} file:<br />
<br />
options iwlwifi power_save=1<br />
<br />
This option will probably increase your median latency:<br />
<br />
options iwlwifi uapsd_disable=0<br />
<br />
On kernels < 5.4 you can use this option, but it will probably decrease your maximum throughput:<br />
<br />
options iwlwifi d0i3_disable=0<br />
<br />
Depending on your wireless card one of these two options will apply.<br />
<br />
options iwlmvm power_scheme=3<br />
<br />
options iwldvm force_cam=0<br />
<br />
You can check which one is relevant by checking which of these modules is running using<br />
<br />
# lsmod | grep '^iwl.vm'<br />
<br />
Keep in mind that these power saving options are experimental and can cause an unstable system.<br />
<br />
=== Bus power management ===<br />
<br />
==== Active State Power Management ====<br />
<br />
If the computer is believed not to support [[Wikipedia:Active State Power Management|ASPM]] it will be disabled on boot:<br />
<br />
# lspci -vv | grep 'ASPM.*abled;'<br />
<br />
ASPM is handled by the BIOS, if ASPM is disabled it will be because [https://wireless.wiki.kernel.org/en/users/documentation/ASPM]:<br />
<br />
# The BIOS disabled it for some reason (for conflicts?).<br />
# PCIE requires ASPM but L0s are optional (so L0s might be disabled and only L1 enabled).<br />
# The BIOS might not have been programmed for it.<br />
# The BIOS is buggy.<br />
<br />
If believing the computer has support for ASPM it can be forced on for the kernel to handle with the {{ic|1=pcie_aspm=force}} [[kernel parameter]].<br />
<br />
{{Warning|<br />
* Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it does not work.<br />
* On systems that do not support it forcing on ASPM can even increase power consumption.<br />
* This forces ASPM in kernel while it can still remain disabled in hardware and not work. To check whether this is the case, run {{ic|dmesg {{!}} grep ASPM}} as root. If so, consult the Wiki article specific to your hardware.<br />
}}<br />
<br />
To adjust to {{ic|powersave}} do (the following command will not work unless enabled):<br />
<br />
# echo powersave > /sys/module/pcie_aspm/parameters/policy<br />
<br />
By default it looks like this:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|<br />
[default] performance powersave powersupersave<br />
}}<br />
<br />
==== PCI Runtime Power Management ====<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
}}<br />
<br />
The rule above powers all unused devices down, but some devices will not wake up again. To allow runtime power management only for devices that are known to work, use simple matching against vendor and device IDs (use {{ic|lspci -nn}} to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# whitelist for pci autosuspend<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with PCI runtime power management and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=<br />
# blacklist for pci runtime power management<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="on", GOTO="pci_pm_end"<br />
<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
LABEL="pci_pm_end"<br />
}}<br />
<br />
==== USB autosuspend ====<br />
<br />
The Linux kernel can automatically suspend USB devices when they are not in use. This can sometimes save quite a bit of power, however some USB devices are not compatible with USB power saving and start to misbehave (common for USB mice/keyboards). [[udev]] rules based on whitelist or blacklist filtering can help to mitigate the problem.<br />
<br />
The most simple and likely useless example is enabling autosuspend for all USB devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
}}<br />
<br />
To allow autosuspend only for devices that are known to work, use simple matching against vendor and product IDs (use ''lsusb'' to get these values):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# whitelist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"<br />
}}<br />
<br />
Alternatively, to blacklist devices that are not working with USB autosuspend and enable it for all other devices:<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
# blacklist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", GOTO="power_usb_rules_end"<br />
<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
LABEL="power_usb_rules_end"<br />
}}<br />
<br />
The default autosuspend idle delay time is controlled by the {{ic|autosuspend}} parameter of the {{ic|usbcore}} built-in [[kernel module]]. To set the delay to 5 seconds instead of the default 2 seconds, add the following [[kernel parameter]] for your boot loader.<br />
<br />
{{bc|1=usbcore.autosuspend=5}}<br />
<br />
Similarly to {{ic|power/control}}, the delay time can be fine-tuned per device by setting the {{ic|power/autosuspend}} attribute. This means, alternatively, autosuspend can be disabled by setting {{ic|power/autosuspend}} to -1 (i.e., never autosuspend):<br />
<br />
{{hc|/etc/udev/rules.d/50-usb_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"<br />
}}<br />
<br />
See the [https://docs.kernel.org/driver-api/usb/power-management.html Linux kernel documentation] for more information on USB power management.<br />
<br />
==== SATA Active Link Power Management ====<br />
<br />
{{Warning|SATA Active Link Power Management can lead to data loss on some devices. Do not enable this setting unless you have frequent backups.}}<br />
<br />
{{Out of date|Phrases like "new setting" and "will become a default setting" are outdated. Also should be more formal. See [[Help:Style#Language register]].}}<br />
<br />
Since Linux 4.15 there is a [https://hansdegoede.livejournal.com/18412.html new setting] called {{ic|med_power_with_dipm}} that matches the behaviour of Windows IRST driver settings and should not cause data loss with recent SSD/HDD drives. The power saving can be significant, ranging [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b from 1.0 to 1.5 Watts (when idle)]. It will become a default setting for Intel based laptops in Linux 4.16 [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ebb82e3c79d2a956366d0848304a53648bd6350b].<br />
<br />
The current setting can be read from {{ic|/sys/class/scsi_host/host*/link_power_management_policy}} as follows:<br />
<br />
$ cat /sys/class/scsi_host/host*/link_power_management_policy<br />
<br />
{| class="wikitable"<br />
|+ Available ALPM settings<br />
! Setting<br />
! Description<br />
! Power saving<br />
|-<br />
| max_performance<br />
| current default<br />
| None<br />
|-<br />
| medium_power<br />
| -<br />
| ~1.0 Watts<br />
|-<br />
| med_power_with_dipm<br />
| recommended setting<br />
| ~1.5 Watts<br />
|-<br />
| min_power<br />
| '''WARNING: possible data loss'''<br />
| ~1.5 Watts<br />
|}<br />
<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=<br />
ACTION=="add", SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="med_power_with_dipm"<br />
}}<br />
<br />
{{Note|This adds latency when accessing a drive that has been idle, so it is one of the few settings that may be worth toggling based on whether you are on AC power.}}<br />
<br />
=== Hard disk drive ===<br />
<br />
See [[hdparm#Power management configuration]] for drive parameters that can be set.<br />
<br />
Power saving is not effective when too many programs are frequently writing to the disk. Tracking all programs, and how and when they write to disk is the way to limit disk usage. Use {{Pkg|iotop}} to see which programs use the disk frequently. See [[Improving performance#Storage devices]] for other tips.<br />
<br />
Also little things like setting the [[Fstab#atime options|noatime]] option can help. If enough RAM is available, consider disabling or limiting [[swappiness]] as it has the possibility to limit a good number of disk writes.<br />
<br />
== Tools and scripts ==<br />
<br />
{{Style|Merged from [[Power saving]], needs reorganization to fit into this page.}}<br />
<br />
=== Using a script and an udev rule ===<br />
<br />
{{Merge|Laptop#Power management|Might be a better fit for the laptop-specific page.}}<br />
<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove ''pm-utils'' and [[acpid]]. There is just one thing systemd cannot do (as of systemd-204): power management depending on whether the system is running on AC or battery. To fill this gap, you can create a single [[udev]] rule that runs a script when the AC adapter is plugged and unplugged:<br />
<br />
{{hc|/etc/udev/rules.d/powersave.rules|2=<br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
}}<br />
<br />
{{Note|You can use the same script that ''pm-powersave'' uses. You just have to make it executable and place it somewhere else (for example {{ic|/usr/local/bin/}}).}}<br />
<br />
Examples of powersave scripts:<br />
<br />
* [https://github.com/supplantr/ftw ftw], package: {{AUR|ftw-git}}<br />
* [https://github.com/Unia/powersave powersave]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=180762 throttlectl], from {{AUR|throttlectl}}<br />
<br />
The above udev rule should work as expected, but if your power settings are not updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online {{!}} grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac<br />
exit 0<br />
}}<br />
<br />
Do not forget to make it executable!<br />
<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
=== Print power settings ===<br />
<br />
{{Merge|#Power saving|Might be good as an introduction? Since most of the output of the script can be used by the following sections.}}<br />
<br />
This script prints power settings and a variety of other properties for USB and PCI devices. Note that root permissions are needed to see all settings.<br />
<br />
{{bc|1=<br />
#!/bin/bash<br />
<br />
for i in $(find /sys/devices -name "bMaxPower")<br />
do<br />
busdir=${i%/*}<br />
busnum=$(<$busdir/busnum)<br />
devnum=$(<$busdir/devnum)<br />
title=$(lsusb -s $busnum:$devnum)<br />
<br />
printf "\n\n+++ %s\n -%s\n" "$title" "$busdir"<br />
<br />
for ff in $(find $busdir/power -type f ! -empty 2>/dev/null)<br />
do<br />
v=$(cat $ff 2>/dev/null{{!}}tr -d "\n")<br />
[[ ${#v} -gt 0 ]] && echo -e " ${ff##*/}=$v";<br />
v=;<br />
done {{!}} sort -g;<br />
done;<br />
<br />
printf "\n\n\n+++ %s\n" "Kernel Modules"<br />
for mod in $(lspci -k {{!}} sed -n '/in use:/s,^.*: ,,p' {{!}} sort -u)<br />
do<br />
echo "+ $mod";<br />
systool -v -m $mod 2> /dev/null {{!}} sed -n "/Parameters:/,/^$/p";<br />
done<br />
}}<br />
<br />
== Allow users to shutdown ==<br />
<br />
{{Style|Merged from [[Allow users to shutdown]], needs reorganization to fit into this page.}}<br />
<br />
=== Button and lid events ===<br />
<br />
The suspend, poweroff and hibernate button presses and lid close events are handled by ''logind'' as described in [[#ACPI events]].<br />
<br />
=== Using systemd-logind ===<br />
<br />
If you are using {{Pkg|polkit}}, users with non-remote session can issue power-related commands as long as [[General troubleshooting#Session permissions|the session is not broken]].<br />
<br />
To check if your session is active<br />
$ loginctl show-session $XDG_SESSION_ID --property=Active<br />
<br />
The user can then use ''systemctl'' commands in the command line, or add them to menus:<br />
$ systemctl poweroff<br />
$ systemctl reboot<br />
<br />
Other commands can be used as well, including {{ic|systemctl suspend}} and {{ic|systemctl hibernate}}. See the ''System Commands'' section in {{man|1|systemctl}}.<br />
<br />
=== Using sudo ===<br />
<br />
[[Install]] {{Pkg|sudo}}, and give the user [[sudo|sudo privileges]]. The user will then be able to use the {{ic|sudo systemctl}} commands (e.g. {{ic|sudo systemctl poweroff}}, {{ic|sudo systemctl reboot}}, {{ic|sudo systemctl suspend}} and {{ic|sudo systemctl hibernate}}). See the ''System Commands'' section in {{man|1|systemctl}}<br />
<br />
==== Users without sudo privileges ====<br />
<br />
If users should only be allowed to use shutdown commands, but not have other sudo privileges, then, as root, add the following to the end of {{ic|/etc/sudoers}} using the {{ic|visudo}} command. Substitute ''user'' for your username and ''hostname'' for the machine's hostname.<br />
<br />
''user'' ''hostname'' =NOPASSWD: /usr/bin/systemctl poweroff,/usr/bin/systemctl halt,/usr/bin/systemctl reboot<br />
<br />
Now your user can shutdown with {{ic|sudo systemctl poweroff}}, and reboot with {{ic|sudo systemctl reboot}}. Users wishing to power down a system can also use {{ic|sudo systemctl halt}}. Use the {{ic|NOPASSWD:}} tag only if you do not want to be prompted for your password.<br />
<br />
== See also ==<br />
<br />
* [https://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]<br />
* [https://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]</div>Calestyohttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=756451Intel graphics2022-11-10T02:51:42Z<p>Calestyo: fix typo</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[ru:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related|GPGPU}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]] and [[Gentoo:Intel#Feature support]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the [[wikipedia:Direct_Rendering_Infrastructure|DRI]] driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the [[wikipedia:X.Org_Server#DDX|DDX]] driver which provides 2D acceleration in [[Xorg]], install the {{Pkg|xf86-video-intel}} package. Beside this functionality, this package is generally not recommended, see note below.<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for Gen4 and newer GPUs (GMA 3000 from 2006 and newer). See [https://web.archive.org/web/20160714232204/https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [https://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://gitlab.freedesktop.org/xorg/xserver/-/issues/1364 screen tearing and mouse jittering on XFCE], [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 artifacts when switching virtual desktops in Chromium], and [https://gitlab.freedesktop.org/xorg/xserver/-/issues/928 vsync jitter/video stutter in mpv]. }}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Accuracy|Despite Intel's documentation, Tiger Lake and Rocket Lake GPUs may actually support {{ic|1=enable_guc=3}}, and have a default of {{ic|1=enable_guc=1}}.|Talk:Intel graphics#TGL/RKL GuC Submission}}<br />
<br />
Starting with Gen9 (Skylake and onwards), Intel GPUs include a ''Graphics micro (μ) Controller'' (GuC) which provides the following functionality [https://01.org/linuxgraphics/downloads/firmware]:<br />
* Offloading some media decoding functionality from the CPU to the ''HEVC/H.265 micro (µ) Controller'' (HuC). Only applicable if using {{Pkg|intel-media-driver}} for [[hardware video acceleration]]. Introduced with Gen9.<br />
* Using the GuC for scheduling, context submission, and power management. Introduced with Alder Lake-P (Mobile), within Gen12.<br />
<br />
To use this functionality, the GuC firmware must be loaded. With regards to HuC support, some video features (e.g. CBR rate control on SKL low-power encoding mode) require loading the HuC firmware as well [https://github.com/intel/media-driver#known-issues-and-limitations]. The GuC and HuC firmware files are both provided by {{Pkg|linux-firmware}}.<br />
<br />
GuC functionality is controlled by the {{ic|1=i915.enable_guc}} [[kernel parameter]]. Its usage is as follows:<br />
<br />
{| class="wikitable"<br />
! enable_guc value !! GuC Submission !! HuC Firmware Loading !! Default for platforms !! Supported on platforms<br />
|-<br />
|0 || {{No}} || {{No}} || Tiger Lake, Rocket Lake, and Pre-Gen12 [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L26-L36] || All<br />
|-<br />
|1 || {{Yes}} || {{No}} || {{-}} || Alder Lake-P (Mobile) and newer<br />
|-<br />
|2 || {{No}} || {{Yes}} || Alder Lake-S (Desktop) [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L38-L42] [https://lore.kernel.org/all/87ee6wit2r.fsf@intel.com/T/] || Gen9 and newer<br />
|-<br />
|3 || {{Yes}} || {{Yes}} || colspan="2" {{C|Alder Lake-P (Mobile) and newer}}<br />
|}<br />
<br />
If GuC submission or HuC firmware loading is not enabled by default for your GPU, you can manually enable it.<br />
<br />
{{Warning|1=Manually enabling GuC / HuC firmware loading taints the kernel [https://bugs.freedesktop.org/show_bug.cgi?id=111918 even when the feature is not supported]. Moreover, enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).}}<br />
<br />
Firstly, ensure that {{Pkg|linux-firmware}} is [[install]]ed.<br />
<br />
If your system is configured for late KMS start (default), you can manually enable these features by setting {{ic|1=i915.enable_guc}} as described in [[Kernel parameters]].<br />
<br />
Otherwise, if you have added the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]) to [[initramfs]], then you must instead set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=2<br />
}}<br />
<br />
And then [[Mkinitcpio#Manual generation|rebuild your initramfs]].<br />
<br />
On next boot you can verify both GuC and HuC are enabled by using [[dmesg]]:<br />
<br />
{{hc|# dmesg|2=<br />
[30130.586970] i915 0000:00:02.0: [drm] GuC firmware i915/icl_guc_33.0.0.bin version 33.0 submission:disabled<br />
[30130.586973] i915 0000:00:02.0: [drm] HuC firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes<br />
}}<br />
<br />
If they are not supported by your graphics adapter you will see:<br />
<br />
{{hc|# dmesg|2=<br />
[ 0.571339] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - GuC is not supported!<br />
[ 0.571340] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - HuC is not supported!<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/gt/uc/guc_info<br />
# cat /sys/kernel/debug/dri/0/gt/uc/huc_info<br />
<br />
{{Note|1=Using [[Intel GVT-g|GVT-g graphics virtualization]] by setting {{ic|1=enable_gvt=1}} is not supported as of linux 4.20.11 when GuC/HuC is also enabled. The i915 module would fail to initialize as shown in system journal.<br />
<br />
{{hc|# journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)<br />
}}<br />
<br />
Note that the related warning is not fatal, as explained in [https://github.com/intel/gvt-linux/issues/77#issuecomment-707541069]:<br />
<br />
{{hc|# journalctl -b |<br />
... kernel: i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x5916_rid_0x02.golden_hw_state failed with error -2<br />
}}<br />
}}<br />
<br />
== Xorg configuration ==<br />
<br />
{{Note|The following requires {{Pkg|xf86-video-intel}}.}}<br />
<br />
There may be no need for any configuration to run [[Xorg]].<br />
<br />
However, if [[Xorg]] does not start, and to take advantage of some driver options, you can create an Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection<br />
}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
=== AccelMethod ===<br />
<br />
You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, the classical options are {{ic|UXA}}, {{ic|SNA}} (default) and {{ic|BLT}}.<br />
<br />
If you experience issues with default {{ic|SNA}} (e.g. pixelated graphics, corrupt text, etc.), try using {{ic|UXA}} instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "AccelMethod" "uxa"<br />
<br />
See the "AccelMethod" option under {{man|4|intel|CONFIGURATION DETAILS}}.<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Note|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe.d/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_fbc=1<br />
}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|# dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [https://web.archive.org/web/20200228230053/https://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
{{Note|1=This parameter is enabled by default for Skylake and newer[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d6535cbed4a4b029602ff83efb2adec7cb8d28b] as well as Bay- and Cherry-Trail (VLV/CHV)[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7360c9f6b857e22a48e545f4e99c79630994e932] since Linux 5.1.[https://kernelnewbies.org/Linux_5.1#Graphics]}}<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started.[https://lists.freedesktop.org/archives/intel-gfx/2012-May/017653.html][https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc]<br />
<br />
To force enable fastboot on platforms where it is not the default already, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe.d/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 fastboot=1<br />
}}<br />
<br />
=== Intel GVT-g graphics virtualization support ===<br />
<br />
See [[Intel GVT-g]] for details.<br />
<br />
=== Enable performance support ===<br />
<br />
{{Expansion|What does Mesa actually do using the performance counters? What's the effect of this? Some report drastic performance increases on Intel Tiger Lake, attributing it to a support for Dynamic Tuning [https://www.reddit.com/r/linux/comments/u7zxa0/psa_for_intel_tiger_lake_dynamic_tuning_laptops/].|section=Potential performance gains via Observation Architecture}}<br />
<br />
Starting with Gen6 (Sandy Bridge and onwards), Intel GPUs provide performance counters used for exposing internal performance data to drivers. The drivers and hardware registers refer to this infrastructure as the ''Observation Architecture'' (internally "OA") [https://www.phoronix.com/scan.php?page=news_item&px=Intel-HSW-Observation-Arch], but Intel's documentation also more generally refers to this functionality as providing ''Observability Performance Counters'' [https://01.org/sites/default/files/documentation/observability_performance_counters_haswell.pdf] [https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol14-observability.pdf].<br />
<br />
By default, only programs running with the [https://lwn.net/Articles/486306/ CAP_SYS_ADMIN] (equivalent to root) or [https://lwn.net/Articles/812719/ CAP_PERFMON] [[capabilities]] can utilize the observation architecture [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L267] [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L3481-L3484]. Most applications will be running without either of these, resulting in the following warning:<br />
<br />
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0<br />
<br />
To enable performance support without using the capabilities (or root), set the kernel parameter as described in [[sysctl]].<br />
<br />
{{Warning|The restrictive defaults of the {{ic|perf_event_paranoid}} family of options exists because there is risk associated with allowing applications to access performance data [https://docs.kernel.org/admin-guide/perf-security.html]. With this being said, {{ic|dev.i915.perf_stream_paranoid}} only influences access to GPU performance counters, which carry less risk than e.g. CPU architectural execution context registers.}}<br />
<br />
If setting the value to 0 in a {{ic|/etc/sysctl.d/*.conf}} file results in the following error at boot:<br />
<br />
sysctl: cannot stat /proc/sys/dev/i915/perf_stream_paranoid: No such file or directory<br />
<br />
you should load the {{ic|i915}} module [[#Enable early KMS|early with KMS]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding – and not H.264 decoding – for some GMA 4500 series GPUs. To check whether that affects your particular GPU, install both that driver and the {{Pkg|libva-utils}} package, then check the output of the {{ic|vainfo}} tool for the presence of entries that start with {{ic|VAProfileH264}}.<br />
<br />
The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note, however, that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [https://web.archive.org/web/20160325142959/http://www.emmolution.org/?p=192&cpage=1#comment-12292]. Setting the preallocated video ram size higher in BIOS results in much better hardware decoded playback. Even 1080p h264 works well if this is done[https://lists.libreplanet.org/archive/html/guix-patches/2019-11/msg00652.html]. Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Send to MPV player"[https://addons.mozilla.org/firefox/addon/send-to-mpv-player/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Old OpenGL driver (i965) ===<br />
<br />
In Mesa 20.0, a new OpenGL driver, Iris, is promoted to be the default for Gen8+. Certain applications run faster with it. You may disable it and revert to use the old i965 driver by setting the {{ic|1=MESA_LOADER_DRIVER_OVERRIDE=i965}} [[environment variable]] before starting any OpenGL application. This setting does not affect Vulkan applications.<br />
<br />
{{Note|1=Report bugs and regressions regarding the Iris driver [https://gitlab.freedesktop.org/mesa/mesa/issues here].}}<br />
<br />
=== Overriding reported OpenGL version ===<br />
<br />
The {{ic|MESA_GL_VERSION_OVERRIDE}} [[environment variable]] can be used to override the reported OpenGL version to any application. For example, setting {{ic|1=MESA_GL_VERSION_OVERRIDE=4.5}} will report OpenGL 4.5.<br />
<br />
{{Note|You can use this variable to report any known OpenGL version, even if it is not supported by the GPU. Some applications might no longer crash, some may start crashing - you probably do not want to set this variable globally.}}<br />
<br />
=== Monitoring ===<br />
<br />
{{Merge|Hardware video acceleration#Verification|This overlaps the content at the previously linked page and would probably be a better fit in a generic page instead of this one dedicated to Intel GPUs. Otherwise, [[Hardware video acceleration#Verification]] should be modified to link to each dedicated page instead of duplicating content.}}<br />
<br />
* {{App|intel_gpu_top|A top-like task monitor for Intel GPUs (requires root permissions).|https://gitlab.freedesktop.org/drm/igt-gpu-tools|{{Pkg|intel-gpu-tools}}}}<br />
* {{App|nvtop|GPUs process monitoring for AMD, Intel and NVIDIA (currently has very basic support for Intel GPUs).|https://github.com/Syllo/nvtop|{{Pkg|nvtop}}}}<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Tearing ===<br />
<br />
The SNA acceleration method causes tearing on some machines. To fix this, enable the {{ic|TearFree}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki/><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increase memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
* For Intel UHD 620 or 630 you will need to add {{ic|Option "TripleBuffer" "true"}} in order for {{ic|TearFree}} to work.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
<br />
Useful when:<br />
<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [https://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization; this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|2=<br />
<device screen="0" driver="dri2"><br />
<application name="Default"><br />
<option name="vblank_mode" value="0"/><br />
</application><br />
</device><br />
}}<br />
<br />
{{Note|Do not use {{AUR|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
<br />
Option "DRI" "False"<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Backlight is not adjustable ===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
Also make sure you are not using fastboot mode ({{ic|i915.fastboot}} kernel parameter), it is [https://www.phoronix.com/forums/forum/software/mobile-linux/1066447-arch-linux-users-with-intel-graphics-can-begin-enjoying-a-flicker-free-boot known] for breaking backlight controls.<br />
<br />
=== Corruption or unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox some possible solutions are:<br />
<br />
* [[#AccelMethod|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
* [[#Tearing|Enable the TearFree option]]<br />
* Disable "DRI" and acceleration method (tested on Intel Iris 10th generation): {{bc|<nowiki><br />
Option "NoAccel" "True"<br />
Option "DRI" "False"<br />
</nowiki>}}<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and [[journalctl]] will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [https://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
<br />
{{Note|The reason of this step back was Chromium and other applications' bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== No sound through HDMI on a Haswell CPU ===<br />
<br />
According to a [https://bugzilla.kernel.org/show_bug.cgi?id=60769 Linux kernel issue], sound will not be output through HDMI if {{ic|1=intel_iommu=on}}. To fix this problem, use the following [[kernel parameter]]:<br />
<br />
intel_iommu=on,igfx_off<br />
<br />
Or alternatively, disable IOMMU:<br />
<br />
intel_iommu=off<br />
<br />
=== Crash/freeze on low power Intel CPUs ===<br />
<br />
Low-powered Intel processors and/or laptop processors have a tendency to randomly hang or crash due to the problems with the power management features found in low-power Intel chips. If such a crash happens, you will not see any logs reporting this problem. Adding the following [[Kernel parameters]] may help to resolve the problem.<br />
<br />
{{Note|It is not advised to use all three of the below kernel parameters together.}}<br />
<br />
intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1<br />
<br />
{{ic|1=ahci.mobile_lpm_policy=1}} fixes a hang on several Lenovo laptops and some Acer notebooks due to problematic SATA controller power management. That workaround is strictly not related to Intel graphics but it does solve related issues. Adding this kernel parameter sets the ''l''ink ''p''ower ''m''anagement from firmware default to maximum performance and will also solve hangs when you change display brightness on certain Lenovo machines but increases idle power consumption by 1-1.5 W on modern ultrabooks. For further information, especially about the other states, see the [https://lore.kernel.org/lkml/20171211165216.5604-1-hdegoede@redhat.com/ Linux kernel mailing list] and [https://access.redhat.com/documentation/en-en/red_hat_enterprise_linux/6/html/power_management_guide/alpm Red Hat documentation].<br />
<br />
{{ic|1=i915.enable_dc=0}} disables GPU power management. This does solve random hangs on certain Intel systems, notably Goldmount and Kaby Lake Refresh chips. Using this parameter does result in higher power use and shorter battery life on laptops/notebooks.<br />
<br />
{{ic|1=intel_idle.max_cstate=1}} limits the processors sleep states, it prevents the processor from going into deep sleep states. That is absolutely not ideal and does result in higher power use and lower battery life. However, it does solve random hangs on many Intel systems. Use this if you have a Intel Baytrail or a Kaby Lake Refresh chip. Intel "Baytrail" chips are known to randomly hang without this kernel parameter due to a hardware flaw[https://bugzilla.kernel.org/show_bug.cgi?id=109051#c752].<br />
More information about the max_cstate parameter can be found in the [https://docs.kernel.org/admin-guide/pm/intel_idle.html#kernel-command-line-options-and-module-parameters kernel documentation] and about the cstates in general on a [https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 writeup on GitHub].<br />
<br />
If you try adding {{ic|1=intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1}} in the hope of fixing frequent hangs and that solves the issue you should later remove one by one to see which of them actually helped you solve the issue. Running with cstates and display power management disabled is not advisable if the actual problem is related to SATA power management and {{ic|1=ahci.mobile_lpm_policy=1}} is the one that actually solves it.<br />
<br />
Check [https://linuxreviews.org/Intel_graphics#Kernel_Parameters Linux Reviews] for more details.<br />
<br />
=== Add support for 165Hz monitor ===<br />
<br />
{{Merge|Kernel mode setting#Forcing modes and EDID|This technique does not appear to be specific to i915. Before merging, one should verify that the install script is necessary, and that there is not an easier way to add the EDID BIN to the initramfs.}}<br />
<br />
For some 165Hz monitors, ''xrandr'' might not display the 165Hz option, and the fix in [[#Adding undetected resolutions]] does not solve this. In this case, see [https://unix.stackexchange.com/questions/680356/i915-driver-stuck-at-40hz-on-165hz-screen i915-driver-stuck-at-40hz-on-165hz-screen].<br />
<br />
{{Note|Other than creating {{ic|/etc/initramfs-tools/hooks/edid}}, a [[mkinitcpio]] hook should be made:<br />
<br />
{{hc|/etc/initcpio/install/edid|<br />
#!/bin/bash<br />
<br />
build() {<br />
add_file /lib/firmware/edid/edid.bin<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook add support for 165Hz<br />
HELPEOF<br />
}<br />
}}<br />
<br />
Then append ''edid'' in HOOKS of {{ic|/etc/mkinitcpio.conf}}, Just like this:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
HOOKS=(... fsck edid)<br />
}}<br />
<br />
Then [[regenerate the initramfs]]. <br />
}}<br />
<br />
=== Freeze after wake from sleep/suspend with Alder Lake-P ===<br />
<br />
{{Expansion|What does "recent firmware" mean? See [[Help:Style#Language register]].}}<br />
{{Note|As of 25-Sep-2022, this has been fixed with a recent firmware update from [[fwupd]]. For others with no BIOS-fix, there is likely an [https://gitlab.freedesktop.org/drm/intel/-/issues/7402 upcoming fix in the kernel].<br />
}}<br />
<br />
Users with Alder Lake-P 12th gen mobile processor laptops from various vendors experienced freeze and black-screen after waking up from suspending. It is because many laptop vendors ship an incorrect VBT (Video BIOS Table) that wrongly describe the actual ports connected to the iGPU. Considering most vendors will not publish a BIOS update for a laptop with a properly working Windows OS, Linux users could only address the issue on the kernel side. You can mitigate the issue by patching and rebuilding the kernel as a temporary remedy:<br />
<br />
{{hc|drivers/gpu/drm/i915/display/intel_display.c.patch|<nowiki><br />
--- a/drivers/gpu/drm/i915/display/intel_display.c<br />
+++ b/drivers/gpu/drm/i915/display/intel_display.c<br />
@@ -8835,7 +8835,7 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv)<br />
intel_ddi_init(dev_priv, PORT_TC1);<br />
} else if (IS_ALDERLAKE_P(dev_priv)) {<br />
intel_ddi_init(dev_priv, PORT_A);<br />
- intel_ddi_init(dev_priv, PORT_B);<br />
+ // intel_ddi_init(dev_priv, PORT_B);<br />
intel_ddi_init(dev_priv, PORT_TC1);<br />
intel_ddi_init(dev_priv, PORT_TC2);<br />
intel_ddi_init(dev_priv, PORT_TC3);<br />
<br />
</nowiki>}}<br />
<br />
as described in freedesktop issues [https://gitlab.freedesktop.org/drm/intel/-/issues/5531 5531] [https://gitlab.freedesktop.org/drm/intel/-/issues/6401 6401] which have not been solved for months.<br />
<br />
=== Issues with selecting Qt elements within Plasma Desktop on Alder Lake/UHD 770 ===<br />
<br />
{{Accuracy|Is this limited to the UHD770 alone? Is this limited to the Plasma Desktop or does it also happen on every Qt application regardless of the environment? Should we not recommend uninstalling {{Pkg|xf86-video-intel}} instead? Is this bug reported somewhere?}}<br />
<br />
Users with newer ~12th gen IGP's may see issues where plasma desktop is almost unusable. It appears to be an issue with accelerated items. Running ''glxgears'' will report a high frame rate, but the animation will not be updated.<br />
A possible solution here is to change the driver under X.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "modesetting"<br />
EndSection<br />
}}<br />
<br />
=== Arc GPU kernel support ===<br />
<br />
As kernels 6.0 and below do not officially support the Arc GPU family yet, the driver needs to be forced to load.<br />
<br />
In your boot loader, use the following [[kernel parameter]]:<br />
<br />
i915.force_probe=''pci_id''<br />
<br />
The PCI ID is the output of: <br />
<br />
$ <nowiki>lspci -nn | grep VGA | sed -n "s/^.\+\[8086:\([[:alnum:]]\{4\}\)\].\+$/\1/p"</nowiki><br />
<br />
You will also need to set your driver in {{ic|xorg.conf}} as follows:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "modesetting"<br />
EndSection<br />
}}<br />
<br />
The "fbdev" driver willl also work.<br />
<br />
Without full driver support, 3D rendering is not available.<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Calestyohttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=756450Intel graphics2022-11-10T02:51:17Z<p>Calestyo: adding pointer to a likely upstream fix.</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[ru:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related|GPGPU}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]] and [[Gentoo:Intel#Feature support]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the [[wikipedia:Direct_Rendering_Infrastructure|DRI]] driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the [[wikipedia:X.Org_Server#DDX|DDX]] driver which provides 2D acceleration in [[Xorg]], install the {{Pkg|xf86-video-intel}} package. Beside this functionality, this package is generally not recommended, see note below.<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [https://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for Gen4 and newer GPUs (GMA 3000 from 2006 and newer). See [https://web.archive.org/web/20160714232204/https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [https://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://gitlab.freedesktop.org/xorg/xserver/-/issues/1364 screen tearing and mouse jittering on XFCE], [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 artifacts when switching virtual desktops in Chromium], and [https://gitlab.freedesktop.org/xorg/xserver/-/issues/928 vsync jitter/video stutter in mpv]. }}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Accuracy|Despite Intel's documentation, Tiger Lake and Rocket Lake GPUs may actually support {{ic|1=enable_guc=3}}, and have a default of {{ic|1=enable_guc=1}}.|Talk:Intel graphics#TGL/RKL GuC Submission}}<br />
<br />
Starting with Gen9 (Skylake and onwards), Intel GPUs include a ''Graphics micro (μ) Controller'' (GuC) which provides the following functionality [https://01.org/linuxgraphics/downloads/firmware]:<br />
* Offloading some media decoding functionality from the CPU to the ''HEVC/H.265 micro (µ) Controller'' (HuC). Only applicable if using {{Pkg|intel-media-driver}} for [[hardware video acceleration]]. Introduced with Gen9.<br />
* Using the GuC for scheduling, context submission, and power management. Introduced with Alder Lake-P (Mobile), within Gen12.<br />
<br />
To use this functionality, the GuC firmware must be loaded. With regards to HuC support, some video features (e.g. CBR rate control on SKL low-power encoding mode) require loading the HuC firmware as well [https://github.com/intel/media-driver#known-issues-and-limitations]. The GuC and HuC firmware files are both provided by {{Pkg|linux-firmware}}.<br />
<br />
GuC functionality is controlled by the {{ic|1=i915.enable_guc}} [[kernel parameter]]. Its usage is as follows:<br />
<br />
{| class="wikitable"<br />
! enable_guc value !! GuC Submission !! HuC Firmware Loading !! Default for platforms !! Supported on platforms<br />
|-<br />
|0 || {{No}} || {{No}} || Tiger Lake, Rocket Lake, and Pre-Gen12 [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L26-L36] || All<br />
|-<br />
|1 || {{Yes}} || {{No}} || {{-}} || Alder Lake-P (Mobile) and newer<br />
|-<br />
|2 || {{No}} || {{Yes}} || Alder Lake-S (Desktop) [https://github.com/torvalds/linux/blob/b3454ce0b2c8a56e760e6baa88ed10278585072b/drivers/gpu/drm/i915/gt/uc/intel_uc.c#L38-L42] [https://lore.kernel.org/all/87ee6wit2r.fsf@intel.com/T/] || Gen9 and newer<br />
|-<br />
|3 || {{Yes}} || {{Yes}} || colspan="2" {{C|Alder Lake-P (Mobile) and newer}}<br />
|}<br />
<br />
If GuC submission or HuC firmware loading is not enabled by default for your GPU, you can manually enable it.<br />
<br />
{{Warning|1=Manually enabling GuC / HuC firmware loading taints the kernel [https://bugs.freedesktop.org/show_bug.cgi?id=111918 even when the feature is not supported]. Moreover, enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).}}<br />
<br />
Firstly, ensure that {{Pkg|linux-firmware}} is [[install]]ed.<br />
<br />
If your system is configured for late KMS start (default), you can manually enable these features by setting {{ic|1=i915.enable_guc}} as described in [[Kernel parameters]].<br />
<br />
Otherwise, if you have added the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]) to [[initramfs]], then you must instead set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=2<br />
}}<br />
<br />
And then [[Mkinitcpio#Manual generation|rebuild your initramfs]].<br />
<br />
On next boot you can verify both GuC and HuC are enabled by using [[dmesg]]:<br />
<br />
{{hc|# dmesg|2=<br />
[30130.586970] i915 0000:00:02.0: [drm] GuC firmware i915/icl_guc_33.0.0.bin version 33.0 submission:disabled<br />
[30130.586973] i915 0000:00:02.0: [drm] HuC firmware i915/icl_huc_9.0.0.bin version 9.0 authenticated:yes<br />
}}<br />
<br />
If they are not supported by your graphics adapter you will see:<br />
<br />
{{hc|# dmesg|2=<br />
[ 0.571339] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - GuC is not supported!<br />
[ 0.571340] i915 0000:00:02.0: [drm] Incompatible option enable_guc=2 - HuC is not supported!<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/gt/uc/guc_info<br />
# cat /sys/kernel/debug/dri/0/gt/uc/huc_info<br />
<br />
{{Note|1=Using [[Intel GVT-g|GVT-g graphics virtualization]] by setting {{ic|1=enable_gvt=1}} is not supported as of linux 4.20.11 when GuC/HuC is also enabled. The i915 module would fail to initialize as shown in system journal.<br />
<br />
{{hc|# journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)<br />
}}<br />
<br />
Note that the related warning is not fatal, as explained in [https://github.com/intel/gvt-linux/issues/77#issuecomment-707541069]:<br />
<br />
{{hc|# journalctl -b |<br />
... kernel: i915 0000:00:02.0: Direct firmware load for i915/gvt/vid_0x8086_did_0x5916_rid_0x02.golden_hw_state failed with error -2<br />
}}<br />
}}<br />
<br />
== Xorg configuration ==<br />
<br />
{{Note|The following requires {{Pkg|xf86-video-intel}}.}}<br />
<br />
There may be no need for any configuration to run [[Xorg]].<br />
<br />
However, if [[Xorg]] does not start, and to take advantage of some driver options, you can create an Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection<br />
}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
=== AccelMethod ===<br />
<br />
You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, the classical options are {{ic|UXA}}, {{ic|SNA}} (default) and {{ic|BLT}}.<br />
<br />
If you experience issues with default {{ic|SNA}} (e.g. pixelated graphics, corrupt text, etc.), try using {{ic|UXA}} instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "AccelMethod" "uxa"<br />
<br />
See the "AccelMethod" option under {{man|4|intel|CONFIGURATION DETAILS}}.<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Note|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe.d/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_fbc=1<br />
}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|# dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [https://web.archive.org/web/20200228230053/https://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
{{Note|1=This parameter is enabled by default for Skylake and newer[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3d6535cbed4a4b029602ff83efb2adec7cb8d28b] as well as Bay- and Cherry-Trail (VLV/CHV)[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7360c9f6b857e22a48e545f4e99c79630994e932] since Linux 5.1.[https://kernelnewbies.org/Linux_5.1#Graphics]}}<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started.[https://lists.freedesktop.org/archives/intel-gfx/2012-May/017653.html][https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc]<br />
<br />
To force enable fastboot on platforms where it is not the default already, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe.d/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 fastboot=1<br />
}}<br />
<br />
=== Intel GVT-g graphics virtualization support ===<br />
<br />
See [[Intel GVT-g]] for details.<br />
<br />
=== Enable performance support ===<br />
<br />
{{Expansion|What does Mesa actually do using the performance counters? What's the effect of this? Some report drastic performance increases on Intel Tiger Lake, attributing it to a support for Dynamic Tuning [https://www.reddit.com/r/linux/comments/u7zxa0/psa_for_intel_tiger_lake_dynamic_tuning_laptops/].|section=Potential performance gains via Observation Architecture}}<br />
<br />
Starting with Gen6 (Sandy Bridge and onwards), Intel GPUs provide performance counters used for exposing internal performance data to drivers. The drivers and hardware registers refer to this infrastructure as the ''Observation Architecture'' (internally "OA") [https://www.phoronix.com/scan.php?page=news_item&px=Intel-HSW-Observation-Arch], but Intel's documentation also more generally refers to this functionality as providing ''Observability Performance Counters'' [https://01.org/sites/default/files/documentation/observability_performance_counters_haswell.pdf] [https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol14-observability.pdf].<br />
<br />
By default, only programs running with the [https://lwn.net/Articles/486306/ CAP_SYS_ADMIN] (equivalent to root) or [https://lwn.net/Articles/812719/ CAP_PERFMON] [[capabilities]] can utilize the observation architecture [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L267] [https://github.com/torvalds/linux/blob/b14ffae378aa1db993e62b01392e70d1e585fb23/drivers/gpu/drm/i915/i915_perf.c#L3481-L3484]. Most applications will be running without either of these, resulting in the following warning:<br />
<br />
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0<br />
<br />
To enable performance support without using the capabilities (or root), set the kernel parameter as described in [[sysctl]].<br />
<br />
{{Warning|The restrictive defaults of the {{ic|perf_event_paranoid}} family of options exists because there is risk associated with allowing applications to access performance data [https://docs.kernel.org/admin-guide/perf-security.html]. With this being said, {{ic|dev.i915.perf_stream_paranoid}} only influences access to GPU performance counters, which carry less risk than e.g. CPU architectural execution context registers.}}<br />
<br />
If setting the value to 0 in a {{ic|/etc/sysctl.d/*.conf}} file results in the following error at boot:<br />
<br />
sysctl: cannot stat /proc/sys/dev/i915/perf_stream_paranoid: No such file or directory<br />
<br />
you should load the {{ic|i915}} module [[#Enable early KMS|early with KMS]].<br />
<br />
== Tips and tricks ==<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding – and not H.264 decoding – for some GMA 4500 series GPUs. To check whether that affects your particular GPU, install both that driver and the {{Pkg|libva-utils}} package, then check the output of the {{ic|vainfo}} tool for the presence of entries that start with {{ic|VAProfileH264}}.<br />
<br />
The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note, however, that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [https://web.archive.org/web/20160325142959/http://www.emmolution.org/?p=192&cpage=1#comment-12292]. Setting the preallocated video ram size higher in BIOS results in much better hardware decoded playback. Even 1080p h264 works well if this is done[https://lists.libreplanet.org/archive/html/guix-patches/2019-11/msg00652.html]. Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Send to MPV player"[https://addons.mozilla.org/firefox/addon/send-to-mpv-player/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Old OpenGL driver (i965) ===<br />
<br />
In Mesa 20.0, a new OpenGL driver, Iris, is promoted to be the default for Gen8+. Certain applications run faster with it. You may disable it and revert to use the old i965 driver by setting the {{ic|1=MESA_LOADER_DRIVER_OVERRIDE=i965}} [[environment variable]] before starting any OpenGL application. This setting does not affect Vulkan applications.<br />
<br />
{{Note|1=Report bugs and regressions regarding the Iris driver [https://gitlab.freedesktop.org/mesa/mesa/issues here].}}<br />
<br />
=== Overriding reported OpenGL version ===<br />
<br />
The {{ic|MESA_GL_VERSION_OVERRIDE}} [[environment variable]] can be used to override the reported OpenGL version to any application. For example, setting {{ic|1=MESA_GL_VERSION_OVERRIDE=4.5}} will report OpenGL 4.5.<br />
<br />
{{Note|You can use this variable to report any known OpenGL version, even if it is not supported by the GPU. Some applications might no longer crash, some may start crashing - you probably do not want to set this variable globally.}}<br />
<br />
=== Monitoring ===<br />
<br />
{{Merge|Hardware video acceleration#Verification|This overlaps the content at the previously linked page and would probably be a better fit in a generic page instead of this one dedicated to Intel GPUs. Otherwise, [[Hardware video acceleration#Verification]] should be modified to link to each dedicated page instead of duplicating content.}}<br />
<br />
* {{App|intel_gpu_top|A top-like task monitor for Intel GPUs (requires root permissions).|https://gitlab.freedesktop.org/drm/igt-gpu-tools|{{Pkg|intel-gpu-tools}}}}<br />
* {{App|nvtop|GPUs process monitoring for AMD, Intel and NVIDIA (currently has very basic support for Intel GPUs).|https://github.com/Syllo/nvtop|{{Pkg|nvtop}}}}<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Tearing ===<br />
<br />
The SNA acceleration method causes tearing on some machines. To fix this, enable the {{ic|TearFree}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki/><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increase memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
* For Intel UHD 620 or 630 you will need to add {{ic|Option "TripleBuffer" "true"}} in order for {{ic|TearFree}} to work.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
<br />
Useful when:<br />
<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [https://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization; this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|2=<br />
<device screen="0" driver="dri2"><br />
<application name="Default"><br />
<option name="vblank_mode" value="0"/><br />
</application><br />
</device><br />
}}<br />
<br />
{{Note|Do not use {{AUR|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
<br />
Option "DRI" "False"<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Backlight is not adjustable ===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
Also make sure you are not using fastboot mode ({{ic|i915.fastboot}} kernel parameter), it is [https://www.phoronix.com/forums/forum/software/mobile-linux/1066447-arch-linux-users-with-intel-graphics-can-begin-enjoying-a-flicker-free-boot known] for breaking backlight controls.<br />
<br />
=== Corruption or unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox some possible solutions are:<br />
<br />
* [[#AccelMethod|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
* [[#Tearing|Enable the TearFree option]]<br />
* Disable "DRI" and acceleration method (tested on Intel Iris 10th generation): {{bc|<nowiki><br />
Option "NoAccel" "True"<br />
Option "DRI" "False"<br />
</nowiki>}}<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and [[journalctl]] will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [https://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
<br />
{{Note|The reason of this step back was Chromium and other applications' bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== No sound through HDMI on a Haswell CPU ===<br />
<br />
According to a [https://bugzilla.kernel.org/show_bug.cgi?id=60769 Linux kernel issue], sound will not be output through HDMI if {{ic|1=intel_iommu=on}}. To fix this problem, use the following [[kernel parameter]]:<br />
<br />
intel_iommu=on,igfx_off<br />
<br />
Or alternatively, disable IOMMU:<br />
<br />
intel_iommu=off<br />
<br />
=== Crash/freeze on low power Intel CPUs ===<br />
<br />
Low-powered Intel processors and/or laptop processors have a tendency to randomly hang or crash due to the problems with the power management features found in low-power Intel chips. If such a crash happens, you will not see any logs reporting this problem. Adding the following [[Kernel parameters]] may help to resolve the problem.<br />
<br />
{{Note|It is not advised to use all three of the below kernel parameters together.}}<br />
<br />
intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1<br />
<br />
{{ic|1=ahci.mobile_lpm_policy=1}} fixes a hang on several Lenovo laptops and some Acer notebooks due to problematic SATA controller power management. That workaround is strictly not related to Intel graphics but it does solve related issues. Adding this kernel parameter sets the ''l''ink ''p''ower ''m''anagement from firmware default to maximum performance and will also solve hangs when you change display brightness on certain Lenovo machines but increases idle power consumption by 1-1.5 W on modern ultrabooks. For further information, especially about the other states, see the [https://lore.kernel.org/lkml/20171211165216.5604-1-hdegoede@redhat.com/ Linux kernel mailing list] and [https://access.redhat.com/documentation/en-en/red_hat_enterprise_linux/6/html/power_management_guide/alpm Red Hat documentation].<br />
<br />
{{ic|1=i915.enable_dc=0}} disables GPU power management. This does solve random hangs on certain Intel systems, notably Goldmount and Kaby Lake Refresh chips. Using this parameter does result in higher power use and shorter battery life on laptops/notebooks.<br />
<br />
{{ic|1=intel_idle.max_cstate=1}} limits the processors sleep states, it prevents the processor from going into deep sleep states. That is absolutely not ideal and does result in higher power use and lower battery life. However, it does solve random hangs on many Intel systems. Use this if you have a Intel Baytrail or a Kaby Lake Refresh chip. Intel "Baytrail" chips are known to randomly hang without this kernel parameter due to a hardware flaw[https://bugzilla.kernel.org/show_bug.cgi?id=109051#c752].<br />
More information about the max_cstate parameter can be found in the [https://docs.kernel.org/admin-guide/pm/intel_idle.html#kernel-command-line-options-and-module-parameters kernel documentation] and about the cstates in general on a [https://gist.github.com/wmealing/2dd2b543c4d3cff6cab7 writeup on GitHub].<br />
<br />
If you try adding {{ic|1=intel_idle.max_cstate=1 i915.enable_dc=0 ahci.mobile_lpm_policy=1}} in the hope of fixing frequent hangs and that solves the issue you should later remove one by one to see which of them actually helped you solve the issue. Running with cstates and display power management disabled is not advisable if the actual problem is related to SATA power management and {{ic|1=ahci.mobile_lpm_policy=1}} is the one that actually solves it.<br />
<br />
Check [https://linuxreviews.org/Intel_graphics#Kernel_Parameters Linux Reviews] for more details.<br />
<br />
=== Add support for 165Hz monitor ===<br />
<br />
{{Merge|Kernel mode setting#Forcing modes and EDID|This technique does not appear to be specific to i915. Before merging, one should verify that the install script is necessary, and that there is not an easier way to add the EDID BIN to the initramfs.}}<br />
<br />
For some 165Hz monitors, ''xrandr'' might not display the 165Hz option, and the fix in [[#Adding undetected resolutions]] does not solve this. In this case, see [https://unix.stackexchange.com/questions/680356/i915-driver-stuck-at-40hz-on-165hz-screen i915-driver-stuck-at-40hz-on-165hz-screen].<br />
<br />
{{Note|Other than creating {{ic|/etc/initramfs-tools/hooks/edid}}, a [[mkinitcpio]] hook should be made:<br />
<br />
{{hc|/etc/initcpio/install/edid|<br />
#!/bin/bash<br />
<br />
build() {<br />
add_file /lib/firmware/edid/edid.bin<br />
}<br />
<br />
help() {<br />
cat <<HELPEOF<br />
This hook add support for 165Hz<br />
HELPEOF<br />
}<br />
}}<br />
<br />
Then append ''edid'' in HOOKS of {{ic|/etc/mkinitcpio.conf}}, Just like this:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
HOOKS=(... fsck edid)<br />
}}<br />
<br />
Then [[regenerate the initramfs]]. <br />
}}<br />
<br />
=== Freeze after wake from sleep/suspend with Alder Lake-P ===<br />
<br />
{{Expansion|What does "recent firmware" mean? See [[Help:Style#Language register]].}}<br />
{{Note|As of 25-Sep-2022, this has been fixed with a recent firmware update from [[fwupd]]. For others with not BIOS-fix, there is likely an [https://gitlab.freedesktop.org/drm/intel/-/issues/7402 upcoming fix in the kernel].<br />
}}<br />
<br />
Users with Alder Lake-P 12th gen mobile processor laptops from various vendors experienced freeze and black-screen after waking up from suspending. It is because many laptop vendors ship an incorrect VBT (Video BIOS Table) that wrongly describe the actual ports connected to the iGPU. Considering most vendors will not publish a BIOS update for a laptop with a properly working Windows OS, Linux users could only address the issue on the kernel side. You can mitigate the issue by patching and rebuilding the kernel as a temporary remedy:<br />
<br />
{{hc|drivers/gpu/drm/i915/display/intel_display.c.patch|<nowiki><br />
--- a/drivers/gpu/drm/i915/display/intel_display.c<br />
+++ b/drivers/gpu/drm/i915/display/intel_display.c<br />
@@ -8835,7 +8835,7 @@ static void intel_setup_outputs(struct drm_i915_private *dev_priv)<br />
intel_ddi_init(dev_priv, PORT_TC1);<br />
} else if (IS_ALDERLAKE_P(dev_priv)) {<br />
intel_ddi_init(dev_priv, PORT_A);<br />
- intel_ddi_init(dev_priv, PORT_B);<br />
+ // intel_ddi_init(dev_priv, PORT_B);<br />
intel_ddi_init(dev_priv, PORT_TC1);<br />
intel_ddi_init(dev_priv, PORT_TC2);<br />
intel_ddi_init(dev_priv, PORT_TC3);<br />
<br />
</nowiki>}}<br />
<br />
as described in freedesktop issues [https://gitlab.freedesktop.org/drm/intel/-/issues/5531 5531] [https://gitlab.freedesktop.org/drm/intel/-/issues/6401 6401] which have not been solved for months.<br />
<br />
=== Issues with selecting Qt elements within Plasma Desktop on Alder Lake/UHD 770 ===<br />
<br />
{{Accuracy|Is this limited to the UHD770 alone? Is this limited to the Plasma Desktop or does it also happen on every Qt application regardless of the environment? Should we not recommend uninstalling {{Pkg|xf86-video-intel}} instead? Is this bug reported somewhere?}}<br />
<br />
Users with newer ~12th gen IGP's may see issues where plasma desktop is almost unusable. It appears to be an issue with accelerated items. Running ''glxgears'' will report a high frame rate, but the animation will not be updated.<br />
A possible solution here is to change the driver under X.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "modesetting"<br />
EndSection<br />
}}<br />
<br />
=== Arc GPU kernel support ===<br />
<br />
As kernels 6.0 and below do not officially support the Arc GPU family yet, the driver needs to be forced to load.<br />
<br />
In your boot loader, use the following [[kernel parameter]]:<br />
<br />
i915.force_probe=''pci_id''<br />
<br />
The PCI ID is the output of: <br />
<br />
$ <nowiki>lspci -nn | grep VGA | sed -n "s/^.\+\[8086:\([[:alnum:]]\{4\}\)\].\+$/\1/p"</nowiki><br />
<br />
You will also need to set your driver in {{ic|xorg.conf}} as follows:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "modesetting"<br />
EndSection<br />
}}<br />
<br />
The "fbdev" driver willl also work.<br />
<br />
Without full driver support, 3D rendering is not available.<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Calestyohttps://wiki.archlinux.org/index.php?title=Talk:Unified_Extensible_Firmware_Interface&diff=264797Talk:Unified Extensible Firmware Interface2013-06-30T23:35:42Z<p>Calestyo: /* >=512 MiB for the UEFISYS partition? */</p>
<hr />
<div>== ESP mount point /boot <-> /boot/efi ==<br />
I think we should decide on a standard here. This article (and others) always use /boot/efi/, but:<br />
* the gummiboot setup tool expects it to be mounted to /boot by default (this is only available in the [testing] package atm). Considering that the setup tool is called in post_install/post_upgrade, this will simply not work for people using /boot/efi.<br />
* the next systemd version has a nice feature, as it will automatically create an automount unit to mount the ESP partition to /boot (it knows the ESP from the bootloader, see http://freedesktop.org/wiki/Software/systemd/BootLoaderInterface )<br />
* Does using /boot/efi actually provide any kind of benefit? The boot partition has always been mounted to /boot and I don't see any reason to change that.<br />
<br />
Other opinions? If there are no objections, I would change the paths to /boot in the corresponding articles.<br />
[[User:65kid|65kid]] ([[User talk:65kid|talk]]) 15:41, 2 March 2013 (UTC)<br />
<br />
:This sounds like a sensible approach. Would it be worth adding a section on migrating; just to ease the pain?<br />
:[[User:Jasonwryan|Jasonwryan]] ([[User talk:Jasonwryan|talk]]) 19:58, 5 March 2013 (UTC)<br />
<br />
:For reference, there is still a long discussion about this here: https://bbs.archlinux.org/viewtopic.php?pid=1241590<br />
:[[User:65kid|65kid]] ([[User talk:65kid|talk]]) 19:02, 8 March 2013 (UTC)<br />
<br />
== >=512 MiB for the UEFISYS partition? ==<br />
<br />
I was never told to make it 512 MiB or more, and right now it's 47.86 MiB and it works fine. Are there any other particular reasons for making it that relatively big? [[User:SansNumbers|///]] ([[User talk:SansNumbers|t]]) 18:27, 26 July 2012 (UTC)<br />
<br />
Microsoft Documentation mentions the minimum partition size for FAT32 to be 512 MiB. UEFI Spec. in some places mentions just FAT but in some places specifically mentions FAT32. Combining both the cases, having a >=512 MiB FAT32 (not FAT16/FAT12) partition UEFISYS is the best bet for all fimrwares out there, some of which may not support <512 MiB and/or FAT16 partition. -- [[User:The.ridikulus.rat|Keshav P R]] ([[User talk:The.ridikulus.rat|talk]]) 16:18, 20 October 2012 (UTC)<br />
<br />
Where do you have this information from? See my [https://lists.debian.org/debian-boot/2013/06/msg00244.html post], where I give links to the only resources that I found which give a minimum size for FAT32 (and which is much smaller). --[[User:Calestyo|Calestyo]] ([[User talk:Calestyo|talk]]) 23:35, 30 June 2013 (UTC)<br />
<br />
==Questionable edits==<br />
<br />
Buhman has totally changed the steps to create a bootable UEFI USB. Persaonlly, I find the new steps to be much more comples than before, and to a pretty terrible job helping the user understand what is actually being achieved. Buhman's first edit says that he "excommunicated the 7z crap" or something like that. Wouldn't it be better to leave a perfectly usable option and make note of alternate methods rather than "excommunicating" what is there? I vote that these instructions should be reverted, or at the very least (heavily) commented. Thoughts anyone? -- [[User:WonderWoofy|Curtis]] ([[User talk:WonderWoofy|talk]]) 20:00, 16 Dec 2012 (UTC)<br />
<br />
:I'm sorry I don't really have the time to revise those edits now, but the policy on the ArchWiki is to always let the end user choose which method to use in order to do something, never hiding anything, so if you really feel that the previous procedure was better, please add it back in a separate section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 12:03, 18 December 2012 (UTC)<br />
<br />
:I think that the line in the Bootable UEFI USB section that says "Install refind-efi" is ambiguous. Does this mean chroot to the filesystem and then install it? The reason I'm trying to setup the bootable USB is because I don't have an arch install running. Or, should I boot the media using some other means and then install the package? A list of commands would be more helpful. -- [[User:Framps|Framps]] ([[User talk:Framps|talk]]) 23:09, 17 January 2013 (UTC)</div>Calestyo