https://wiki.archlinux.org/api.php?action=feedcontributions&user=Calinou&feedformat=atomArchWiki - User contributions [en]2024-03-28T20:06:23ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Fish&diff=597672Fish2020-02-16T12:49:40Z<p>Calinou: /* Use liquidprompt */ it's -> its</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Command shells]]<br />
[[de:Fish]]<br />
[[ja:Fish]]<br />
[[ru:Fish]]<br />
[[zh-hans:Fish]]<br />
[[fr:Fish]]<br />
<br />
[https://fishshell.com fish], the '''''f'''riendly '''i'''nteractive '''sh'''ell'', is a [[command-line shell|commandline shell]] intended to be interactive and user-friendly.<br />
<br />
''fish'' is intentionally not fully [[Wikipedia:POSIX|POSIX]] compliant, it aims at addressing POSIX inconsistencies (as perceived by the creators) with a simplified or a different syntax. This means that even simple POSIX compliant scripts may require some significant adaptation or even full rewriting to run with fish.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|fish}} package. For the development version, install the {{AUR|fish-git}} package.<br />
<br />
Once installed, simply type {{ic|fish}} to drop into the fish shell.<br />
<br />
Documentation can be found by typing {{ic|help}} from fish; it will be opened in a web browser. It is recommended to read at least the "Syntax overview" section, since fish's syntax is different from many other shells.<br />
<br />
== System integration ==<br />
<br />
One must decide whether fish is going to be the default user's shell, which means that the user falls directly in fish at login, or whether it is used in interactive terminal mode as a child process of the current default shell, here we will assume the latter is [[Bash]]. To elaborate on these two setups:<br />
<br />
* fish used as the '''default shell''': this mode requires some basic understanding of the fish functioning and its scripting language. The user's current initialization scripts and environment variables need to be migrated to the new fish environment. To configure the system in this mode, follow [[#Setting fish as default shell]].<br />
<br />
* fish used as an '''interactive shell only''': this is the less disruptive mode, all the Bash initialization scripts are run as usual and fish runs on top of Bash in interactive mode connected to a terminal. To setup fish in this mode, follow [[#Setting fish as interactive shell only]].<br />
<br />
=== Setting fish as default shell ===<br />
If you decide to set fish as the default user shell, the first step is to set the shell of this particular user to {{ic|/usr/bin/fish}}. This can be done by following the instructions in [[Command-line shell#Changing your default shell]].<br />
<br />
The next step is to port the current needed actions and configuration performed in the various Bash initialization scripts, namely {{ic|/etc/profile}}, {{ic|~/.bash_profile}}, {{ic|/etc/bash.bashrc}} and {{ic|~/.bashrc}}, into the fish framework.<br />
<br />
In particular, the content of the {{ic|$PATH}} environment variable, once directly logged under fish, should be checked and adjusted to one's need. In fish, {{ic|$PATH}} is defined as a ''global environment variable'': it has a ''global'' scope across all functions, it is lost upon reboot and it is an ''environment variable'' which means it is exported to child processes.<br />
The recommended way of adding permanently additional locations to the path is by assigning them to the {{ic|fish_user_paths}} universal variable. This variable is automatically added to {{ic|$PATH}} and is preserved across restarts of the shell. For example by setting:<br />
<br />
$ set -U fish_user_paths ''/first/path'' ''/second/path'' ''/third/one''<br />
<br />
These three locations will be permanently prepended to the path. This is an easy way to complement the path without the need to add any instruction in scripts.<br />
<br />
=== Setting fish as interactive shell only ===<br />
Not setting fish as system wide or user default allows the current Bash scripts to run on startup. It ensures the current user's environment variables are unchanged and are exported to fish which then runs as a Bash child. Below are several ways of running fish in interactive mode without setting it as the default shell.<br />
<br />
==== Modify .bashrc to drop into fish ====<br />
Keep the default shell as Bash and simply add the line {{ic|exec fish}} to the appropriate [[Bash#Configuration files]], such as {{ic|.bashrc}}. This will allow Bash to properly source {{ic|/etc/profile}} and all files in {{ic|/etc/profile.d}}. Because fish replaces the Bash process, exiting fish will also exit the terminal. Compared to the following options, this is the most universal solution, since it works both on a local machine and on a SSH server.<br />
<br />
{{Tip|<br />
* In this setup, use {{ic|bash --norc}} to manually enter Bash without executing the commands from {{ic|~/.bashrc}} which would run {{ic|exec fish}} and drop back into fish.<br />
* To have commands such as {{ic|bash -c 'echo test'}} run the command in Bash instead of starting fish, you can write {{ic|if [ -z "$BASH_EXECUTION_STRING" ]; then exec fish; fi}} instead.<br />
* Drop in to fish only if the parent process is not fish. This allows to quickly enter in to bash by invoking {{ic|bash}} command without losing {{ic|~/.bashrc}} configuration: {{bc|<nowiki>if [[ $(ps --no-header --pid=$PPID --format=cmd) != "fish" ]]<br />
then<br />
exec fish<br />
fi</nowiki>}}}}<br />
<br />
==== Use terminal emulator options ====<br />
<br />
Another option is to open your terminal emulator with a command line option that executes fish. For most terminals this is the {{ic|-e}} switch, so for example, to open gnome-terminal using fish, change your shortcut to use:<br />
<br />
gnome-terminal -e fish<br />
<br />
With terminal emulators that do not support setting the shell, for example {{aur|lilyterm-git}}, it would look like this:<br />
<br />
SHELL=/usr/bin/fish lilyterm<br />
<br />
Also, depending on the terminal, you may be able to set fish as the default shell in either the terminal configuration or the terminal profile.<br />
<br />
==== Use terminal multiplexer options ====<br />
<br />
To set fish as the shell started in [[tmux]], put this into your {{ic|~/.tmux.conf}}:<br />
<br />
set-option -g default-shell "/usr/bin/fish"<br />
<br />
Whenever you run ''tmux'', you will be dropped into fish.<br />
<br />
== Configuration ==<br />
<br />
The configuration file runs at every login and is located at {{ic|~/.config/fish/config.fish}}. Adding commands or functions to the file will execute/define them when opening a terminal, similar to {{ic|.bashrc}}. Note that whenever a variable needs to be preserved, it should be set as ''universal'' rather than defined in the aforementioned configuration file.<br />
<br />
The user's functions are located in the directory {{ic|~/.config/fish/functions}} under the filenames {{ic|''function_name''.fish}}.<br />
<br />
=== Web interface ===<br />
<br />
The fish terminal colors, prompt, functions, variables, history, bindings and abbreviations can be set with the interactive web interface:<br />
<br />
fish_config<br />
<br />
It may fail to start if IPv6 has been disabled. See [https://github.com/fish-shell/fish-shell/issues/3857#issuecomment-281631629] and [[IPv6#Disable IPv6]].<br />
<br />
=== Command completion ===<br />
<br />
fish can generate autocompletions from man pages. Completions are written to {{ic|~/.local/share/fish/generated_completions/}} and can be generated by calling:<br />
<br />
fish_update_completions<br />
<br />
You can also define your own completions in {{ic|~/.config/fish/completions/}}. See {{ic|/usr/share/fish/completions/}} for a few examples.<br />
<br />
Context-aware completions for Arch Linux-specific commands like ''pacman'', ''pacman-key'', ''makepkg'', ''cower'', ''pbget'', ''pacmatic'' are built into fish, since the policy of the fish development is to include all the existent completions in the upstream tarball. The memory management is clever enough to avoid any negative impact on resources.<br />
<br />
==Tips and tricks==<br />
<br />
===Command substitution===<br />
''fish'' does not implement Bash style history substitution (e.g. {{ic|sudo !!}}), and the developers recommend in the [http://fishshell.com/docs/current/faq.html#faq-history fish faq] to use the interactive history recall interface instead: the {{ic|Up}} arrow recalls whole past lines and {{ic|Alt+Up}} (or {{ic|Alt+.}}) recalls individual arguments.<br />
<br />
However some workarounds are described in the [https://github.com/fish-shell/fish-shell/wiki/Bash-Style-Command-Substitution-and-Chaining-(!!-!$-&&-%7C%7C) fish wiki]: while not providing complete history substitution, some functions replace {{ic|!!}} with the previous command or {{ic|!$}} with the previous last argument.<br />
<br />
===Command chaining===<br />
Command chaining {{ic|&&}} and {{ic|{{!}}{{!}}}} is not implemented in versions older than 3.0 and the recommended syntax to achieve similar results in ''fish'' is respectively {{ic|; and}} and {{ic|; or}}.<br />
Some keybindings can be set for automatic substitution as described in the [https://github.com/fish-shell/fish-shell/wiki/Bash-Style-Command-Substitution-and-Chaining-(!!-!$-&&-%7C%7C)#getting--and- fish wiki].<br />
<br />
===Disable greeting===<br />
<br />
By default, fish prints a greeting message at startup. To disable it, run once:<br />
<br />
$ set -U fish_greeting<br />
<br />
This clears the universal {{ic|fish_greeting}} variable, shared with all fish instances and which is preserved upon restart of the shell.<br />
<br />
=== Make su launch fish ===<br />
<br />
If ''su'' starts with Bash because Bash is the target user's (''root'' if no username is provided) default shell, one can define a function to redirect it to fish whatever the user's shell:<br />
{{hc|~/.config/fish/functions/su.fish|2=<br />
function su<br />
command su --shell=/usr/bin/fish $argv<br />
end}}<br />
<br />
=== Start X at login ===<br />
<br />
Add the following to the bottom of your {{ic|~/.config/fish/config.fish}}.<br />
<br />
{{bc|1=<nowiki><br />
# Start X at login<br />
if status is-login<br />
if test -z "$DISPLAY" -a $XDG_VTNR = 1<br />
exec startx -- -keeptty<br />
end<br />
end<br />
</nowiki>}}<br />
<br />
For those running fish in interactive mode, replace {{ic|status is-login}} with {{ic|status is-interactive}} in the above code.<br />
<br />
=== Use liquidprompt ===<br />
<br />
[https://github.com/nojhan/liquidprompt Liquidprompt] is a popular "full-featured & carefully designed adaptive prompt for Bash & Zsh" and has no plans to make it compatible with fish [https://github.com/nojhan/liquidprompt/pull/230]. The [https://github.com/dolmen/angel-PS1 angel-PS1] project implements its functionality for fish.<br />
<br />
=== Put git status in prompt ===<br />
<br />
If you would like fish to display the branch and dirty status when you are in a git directory, you can define the following {{ic|fish_prompt}} function:<br />
{{hc|~/.config/fish/functions/fish_prompt.fish|<br />
<nowiki>function fish_prompt<br />
set -l last_status $status<br />
<br />
if not set -q __fish_git_prompt_show_informative_status<br />
set -g __fish_git_prompt_show_informative_status 1<br />
end<br />
if not set -q __fish_git_prompt_color_branch<br />
set -g __fish_git_prompt_color_branch brmagenta<br />
end<br />
if not set -q __fish_git_prompt_showupstream<br />
set -g __fish_git_prompt_showupstream "informative"<br />
end<br />
if not set -q __fish_git_prompt_showdirtystate<br />
set -g __fish_git_prompt_showdirtystate "yes"<br />
end<br />
if not set -q __fish_git_prompt_color_stagedstate<br />
set -g __fish_git_prompt_color_stagedstate yellow<br />
end<br />
if not set -q __fish_git_prompt_color_invalidstate<br />
set -g __fish_git_prompt_color_invalidstate red<br />
end<br />
if not set -q __fish_git_prompt_color_cleanstate<br />
set -g __fish_git_prompt_color_cleanstate brgreen<br />
end<br />
<br />
printf '%s%s %s%s%s%s ' (set_color $fish_color_host) (prompt_hostname) (set_color $fish_color_cwd) (prompt_pwd) (set_color normal) (__fish_git_prompt)<br />
<br />
if not test $last_status -eq 0<br />
set_color $fish_color_error<br />
end<br />
echo -n '$ '<br />
set_color normal<br />
end<br />
</nowiki>}}<br />
<br />
However, this is now deprecated, see [https://github.com/fish-shell/fish-shell/blob/master/share/functions/__fish_git_prompt.fish fish-shell git].<br />
Alternatively, the [http://mariuszs.github.io/blog/2013/informative_git_prompt.html Informative Git Prompt] has now been built into fish and can be activated from fish_config if so desired.<br />
<br />
===Color the hostname in the prompt in SSH===<br />
To color the hostname in the prompt dynamically whenever connected through SSH, add the following lines in either the {{ic|fish_prompt}} function or the fish configuration file, here using the red color:<br />
<br />
{{hc|~/.config/fish/functions/fish_prompt.fish|<br />
...<br />
if set -q SSH_TTY<br />
set -g fish_color_host brred<br />
end<br />
...}}<br />
<br />
=== Evaluate ssh-agent ===<br />
<br />
In fish, {{ic|eval (ssh-agent)}} generate errors due to how variables are set. To work around this, use the csh-style option {{ic|-c}}:<br />
<br />
$ eval (ssh-agent -c)<br />
<br />
=== The "command not found" hook ===<br />
<br />
[[pkgfile]] includes a "command not found" hook that will automatically search the official repositories, when entering an unrecognized command. This hook will be run by default if {{Pkg|pkgfile}} is installed.<br />
<br />
=== Remove a process from the list of jobs ===<br />
<br />
''fish'' terminates any jobs put into the background when fish terminates. To keep a job running after fish terminates, first use the {{ic|disown}} builtin. For example, the following starts {{ic|firefox}} in the background and then disowns it:<br />
<br />
$ firefox &<br />
$ disown<br />
<br />
This means firefox will not be closed when the fish process is closed. See {{man|1|disown|url=}} in ''fish'' for more details.<br />
<br />
=== Set a persistent alias ===<br />
<br />
To quickly make a persistent alias, one can simply use the method showed in this example:<br />
$ alias lsl "ls -l"<br />
$ funcsave lsl<br />
<br />
This will create the function:<br />
function lsl<br />
ls -l $argv<br />
end<br />
<br />
and will set the alias as a persistent shell function. To see all functions and/or edit them, one can simply use {{ic|fish_config}} and look into the ''Function'' tab in the web configuration page.<br />
<br />
For more detailed information, refer to [https://fishshell.com/docs/current/commands.html#alias fish - alias].<br />
<br />
== See also ==<br />
<br />
* http://fishshell.com/ - Home page<br />
* http://fishshell.com/docs/current/index.html - Documentation<br />
* http://hyperpolyglot.org/unix-shells - Shell grammar correspondence table<br />
* https://github.com/fish-shell/fish-shell - fish on GitHub</div>Calinouhttps://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=586490PCI passthrough via OVMF2019-10-18T11:14:24Z<p>Calinou: Capitalize Linux/Windows</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:OVMF による PCI パススルー]]<br />
[[zh-hans:PCI passthrough via OVMF]]<br />
{{Related articles start}}<br />
{{Related|Intel GVT-g}}<br />
{{Related articles end}}<br />
<br />
The Open Virtual Machine Firmware ([https://github.com/tianocore/tianocore.github.io/wiki/OVMF OVMF]) is a project to enable UEFI support for virtual machines. Starting with Linux 3.9 and recent versions of [[QEMU]], it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful for graphic-intensive tasks.<br />
<br />
Provided you have a desktop computer with a spare GPU you can dedicate to the host (be it an integrated GPU or an old OEM card, the brands do not even need to match) and that your hardware supports it (see [[#Prerequisites]]), it is possible to have a VM of any OS with its own dedicated GPU and near-native performance. For more information on techniques see the background [https://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf presentation (pdf)]. <br />
<br />
== Prerequisites ==<br />
<br />
A VGA Passthrough relies on a number of technologies that are not ubiquitous as of today and might not be available on your hardware. You will not be able to do this on your machine unless the following requirements are met :<br />
<br />
* Your CPU must support hardware virtualization (for kvm) and IOMMU (for the passthrough itself)<br />
** [https://ark.intel.com/Search/FeatureFilter?productType=873&0_VTD=True List of compatible Intel CPUs (Intel VT-x and Intel VT-d)]<br />
** All AMD CPUs from the Bulldozer generation and up (including Zen) should be compatible.<br />
*** CPUs from the K10 generation (2007) do not have an IOMMU, so you '''need''' to have a motherboard with a [https://support.amd.com/TechDocs/43403.pdf#page=18 890FX] or [https://support.amd.com/TechDocs/48691.pdf#page=21 990FX] chipset to make it work, as those have their own IOMMU.<br />
* Your motherboard must also support IOMMU<br />
** Both the chipset and the BIOS must support it. It is not always easy to tell at a glance whether or not this is the case, but there is a fairly comprehensive list on the matter on the [https://wiki.xen.org/wiki/VTd_HowTo Xen wiki] as well as [[Wikipedia:List of IOMMU-supporting hardware]].<br />
* Your guest GPU ROM must support UEFI.<br />
** If you can find [https://www.techpowerup.com/vgabios/ any ROM in this list] that applies to your specific GPU and is said to support UEFI, you are generally in the clear. All GPUs from 2012 and later should support this, as Microsoft made UEFI a requirement for devices to be marketed as compatible with Windows 8.<br />
<br />
You will probably want to have a spare monitor or one with multiple input ports connected to different GPUs (the passthrough GPU will not display anything if there is no screen plugged in and using a VNC or Spice connection will not help your performance), as well as a mouse and a keyboard you can pass to your VM. If anything goes wrong, you will at least have a way to control your host machine this way.<br />
<br />
== Setting up IOMMU ==<br />
<br />
{{Note|<br />
* IOMMU is a generic name for Intel VT-d and AMD-Vi.<br />
* VT-d stands for ''Intel Virtualization Technology for Directed I/O'' and should not be confused with VT-x ''Intel Virtualization Technology''. VT-x allows one hardware platform to function as multiple “virtual” platforms while VT-d improves security and reliability of the systems and also improves performance of I/O devices in virtualized environments.<br />
}}<br />
<br />
Using IOMMU opens to features like PCI passthrough and memory protection from faulty or malicious devices, see [[Wikipedia:Input-output memory management unit#Advantages]] and [https://www.quora.com/Memory-Management-computer-programming/Could-you-explain-IOMMU-in-plain-English Memory Management (computer programming): Could you explain IOMMU in plain English?].<br />
<br />
=== Enabling IOMMU ===<br />
<br />
Ensure that AMD-Vi/Intel VT-d is supported by the CPU and enabled in the BIOS settings. Both normally show up alongside other CPU features (meaning they could be in an overclocking-related menu) either with their actual names ("VT-d" or "AMD-Vi") or in more ambiguous terms such as "Virtualization technology", which may or may not be explained in the manual.<br />
<br />
Enable IOMMU support by setting the correct [[kernel parameter]] depending on the type of CPU in use:<br />
<br />
* For Intel CPUs (VT-d) set {{ic|1=intel_iommu=on}} <br />
* For AMD CPUs (AMD-Vi) set {{ic|1=amd_iommu=on}}<br />
<br />
You should also append the {{ic|1=iommu=pt}} parameter. This will prevent Linux from touching devices which cannot be passed through.<br />
<br />
After rebooting, check dmesg to confirm that IOMMU has been correctly enabled:<br />
<br />
{{hc|dmesg {{!}} grep -i -e DMAR -e IOMMU|<br />
[ 0.000000] ACPI: DMAR 0x00000000BDCB1CB0 0000B8 (v01 INTEL BDW 00000001 INTL 00000001)<br />
[ 0.000000] Intel-IOMMU: enabled<br />
[ 0.028879] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a<br />
[ 0.028883] dmar: IOMMU 1: reg_base_addr fed91000 ver 1:0 cap d2008c20660462 ecap f010da<br />
[ 0.028950] IOAPIC id 8 under DRHD base 0xfed91000 IOMMU 1<br />
[ 0.536212] DMAR: No ATSR found<br />
[ 0.536229] IOMMU 0 0xfed90000: using Queued invalidation<br />
[ 0.536230] IOMMU 1 0xfed91000: using Queued invalidation<br />
[ 0.536231] IOMMU: Setting RMRR:<br />
[ 0.536241] IOMMU: Setting identity map for device 0000:00:02.0 [0xbf000000 - 0xcf1fffff]<br />
[ 0.537490] IOMMU: Setting identity map for device 0000:00:14.0 [0xbdea8000 - 0xbdeb6fff]<br />
[ 0.537512] IOMMU: Setting identity map for device 0000:00:1a.0 [0xbdea8000 - 0xbdeb6fff]<br />
[ 0.537530] IOMMU: Setting identity map for device 0000:00:1d.0 [0xbdea8000 - 0xbdeb6fff]<br />
[ 0.537543] IOMMU: Prepare 0-16MiB unity mapping for LPC<br />
[ 0.537549] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]<br />
[ 2.182790] [drm] DMAR active, disabling use of stolen memory<br />
}}<br />
<br />
=== Ensuring that the groups are valid ===<br />
<br />
The following script should allow you to see how your various PCI devices are mapped to IOMMU groups. If it does not return anything, you either have not enabled IOMMU support properly or your hardware does not support it.<br />
<br />
#!/bin/bash<br />
shopt -s nullglob<br />
for g in /sys/kernel/iommu_groups/*; do<br />
echo "IOMMU Group ${g##*/}:"<br />
for d in $g/devices/*; do<br />
echo -e "\t$(lspci -nns ${d##*/})"<br />
done;<br />
done;<br />
<br />
Example output:<br />
<br />
IOMMU Group 1:<br />
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)<br />
IOMMU Group 2:<br />
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:0e31] (rev 04)<br />
IOMMU Group 4:<br />
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:0e2d] (rev 04)<br />
IOMMU Group 10:<br />
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:0e26] (rev 04)<br />
IOMMU Group 13:<br />
06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
06:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)<br />
<br />
An IOMMU group is the smallest set of physical devices that can be passed to a virtual machine. For instance, in the example above, both the GPU in 06:00.0 and its audio controller in 6:00.1 belong to IOMMU group 13 and can only be passed together. The frontal USB controller, however, has its own group (group 2) which is separate from both the USB expansion controller (group 10) and the rear USB controller (group 4), meaning that [[#USB controller|any of them could be passed to a VM without affecting the others]].<br />
<br />
=== Gotchas ===<br />
<br />
==== Plugging your guest GPU in an unisolated CPU-based PCIe slot ====<br />
<br />
Not all PCI-E slots are the same. Most motherboards have PCIe slots provided by both the CPU and the PCH. Depending on your CPU, it is possible that your processor-based PCIe slot does not support isolation properly, in which case the PCI slot itself will appear to be grouped with the device that is connected to it.<br />
<br />
IOMMU Group 1:<br />
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)<br />
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)<br />
01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1)<br />
<br />
This is fine so long as only your guest GPU is included in here, such as above. Depending on what is plugged in to your other PCIe slots and whether they are allocated to your CPU or your PCH, you may find yourself with additional devices within the same group, which would force you to pass those as well. If you are ok with passing everything that is in there to your VM, you are free to continue. Otherwise, you will either need to try and plug your GPU in your other PCIe slots (if you have any) and see if those provide isolation from the rest or to install the ACS override patch, which comes with its own drawbacks. See [[#Bypassing the IOMMU groups (ACS override patch)]] for more information.<br />
<br />
{{Note|If they are grouped with other devices in this manner, pci root ports and bridges should neither be bound to vfio at boot, nor be added to the VM.}}<br />
<br />
== Isolating the GPU ==<br />
<br />
In order to assign a device to a virtual machine, this device and all those sharing the same IOMMU group must have their driver replaced by a stub driver or a VFIO driver in order to prevent the host machine from interacting with them. In the case of most devices, this can be done on the fly right before the VM starts.<br />
<br />
However, due to their size and complexity, GPU drivers do not tend to support dynamic rebinding very well, so you cannot just have some GPU you use on the host be transparently passed to a VM without having both drivers conflict with each other. Because of this, it is generally advised to bind those placeholder drivers manually before starting the VM, in order to stop other drivers from attempting to claim it.<br />
<br />
The following section details how to configure a GPU so those placeholder drivers are bound early during the boot process, which makes said device inactive until a VM claims it or the driver is switched back. This is the preferred method, considering it has less caveats than switching drivers once the system is fully online.<br />
<br />
{{Warning|Once you reboot after this procedure, whatever GPU you have configured will no longer be usable on the host until you reverse the manipulation. Make sure the GPU you intend to use on the host is properly configured before doing this - your motherboard should be set to display using the host GPU.}}<br />
<br />
Starting with Linux 4.1, the kernel includes vfio-pci. This is a VFIO driver, meaning it fulfills the same role as pci-stub did, but it can also control devices to an extent, such as by switching them into their D3 state when they are not in use.<br />
<br />
Vfio-pci normally targets PCI devices by ID, meaning you only need to specify the IDs of the devices you intend to passthrough. For the following IOMMU group, you would want to bind vfio-pci with {{ic|10de:13c2}} and {{ic|10de:0fbb}}, which will be used as example values for the rest of this section.<br />
<br />
IOMMU Group 13:<br />
06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
06:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)}}<br />
<br />
{{Note|You cannot specify which device to isolate using vendor-device ID pairs if the host GPU and the guest GPU share the same pair (i.e : if both are the same model). If this is your case, read [[#Using identical guest and host GPUs]] instead.}}<br />
<br />
{{Note|If, as noted in [[#Plugging your guest GPU in an unisolated CPU-based PCIe slot]], your pci root port is part of your IOMMU group, you '''must not''' pass its ID to {{ic|vfio-pci}}, as it needs to remain attached to the host to function properly. Any other device within that group, however, should be left for {{ic|vfio-pci}} to bind with.}}<br />
<br />
=== With vfio-pci loaded as a module ===<br />
<br />
{{Pkg|linux}} kernel does not include vfio-pci as a built-in module and therefore needs to be loaded en configured separately like so. <br />
First, the vendor-device ID pairs must be specified as default parameters passed to vfio-pci whenever it is inserted into the kernel.<br />
<br />
{{hc|/etc/modprobe.d/vfio.conf|2=<br />
options vfio-pci ids=10de:13c2,10de:0fbb<br />
}}<br />
<br />
This, however, does not guarantee that vfio-pci will be loaded before other graphics drivers. To ensure that, we need to statically bind it in the kernel image alongside with its dependencies. That means adding, in this order, {{ic|vfio_pci}}, {{ic|vfio}}, {{ic|vfio_iommu_type1}}, and {{ic|vfio_virqfd}} to [[mkinitcpio]]:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(... vfio_pci vfio vfio_iommu_type1 vfio_virqfd ...)<br />
}}<br />
<br />
{{Note|If you also have another driver loaded this way for [[Kernel mode setting#Early KMS start|early modesetting]] (such as {{ic|nouveau}}, {{ic|radeon}}, {{ic|amdgpu}}, {{ic|i915}}, etc.), all of the aforementioned VFIO modules must precede it.}}<br />
<br />
Also, ensure that the modconf hook is included in the HOOKS list of {{ic|mkinitcpio.conf}}:<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
HOOKS=(... modconf ...)<br />
}}<br />
<br />
Since new modules have been added to the initramfs configuration, you must [[regenerate the initramfs]]. Should you change the IDs of the devices in {{ic|/etc/modprobe.d/vfio.conf}}, you will also have to regenerate it, as those parameters must be specified in the initramfs to be known during the early boot stages.<br />
<br />
=== With vfio-pci built into the kernel ===<br />
<br />
If your kernel comes with the vfio-pci module built in, as opposed to it being a module that needs to be loaded separately. All that should be required to isolate the GPU is to pass the device IDs as [[kernel parameters]] like so:<br />
<br />
vfio-pci.ids=10de:13c2,10de:0fbb<br />
<br />
=== Verifying that the configuration worked ===<br />
<br />
Reboot and verify that vfio-pci has loaded properly and that it is now bound to the right devices.<br />
<br />
{{hc|$ dmesg {{!}} grep -i vfio|<br />
[ 0.329224] VFIO - User Level meta-driver version: 0.3<br />
[ 0.341372] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.354704] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 2.061326] vfio-pci 0000:06:00.0: enabling device (0100 -> 0103)<br />
}}<br />
<br />
It is not necessary for all devices (or even expected device) from {{ic|vfio.conf}} to be in dmesg output. Sometimes a device does not appear in output at boot but actually is able to be visible and operatable in guest VM.<br />
<br />
{{hc|$ lspci -nnk -d 10de:13c2|<br />
06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
Kernel driver in use: vfio-pci<br />
Kernel modules: nouveau nvidia<br />
}}<br />
<br />
{{hc|$ lspci -nnk -d 10de:0fbb|<br />
06:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)<br />
Kernel driver in use: vfio-pci<br />
Kernel modules: snd_hda_intel<br />
}}<br />
<br />
== Setting up an OVMF-based guest VM ==<br />
<br />
OVMF is an open-source UEFI firmware for QEMU virtual machines. While it is possible to use SeaBIOS to get similar results to an actual PCI passthough, the setup process is different and it is generally preferable to use the EFI method if your hardware supports it.<br />
<br />
=== Configuring libvirt ===<br />
<br />
[[Libvirt]] is a wrapper for a number of virtualization utilities that greatly simplifies the configuration and deployment process of virtual machines. In the case of KVM and QEMU, the frontend it provides allows us to avoid dealing with the permissions for QEMU and make it easier to add and remove various devices on a live VM. Its status as a wrapper, however, means that it might not always support all of the latest qemu features, which could end up requiring the use of a wrapper script to provide some extra arguments to QEMU.<br />
<br />
After installing {{Pkg|qemu}}, {{Pkg|libvirt}}, {{Pkg|ovmf}}, and {{Pkg|virt-manager}}, add the path to your OVMF firmware image and runtime variables template to your libvirt config so {{ic|virt-install}} or {{ic|virt-manager}} can find those later on.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|2=<br />
nvram = [<br />
"/usr/share/ovmf/x64/OVMF_CODE.fd:/usr/share/ovmf/x64/OVMF_VARS.fd"<br />
]<br />
}}<br />
<br />
You can now [[enable]] and [[start]] {{ic|libvirtd.service}} and its logging component {{ic|virtlogd.socket}}.<br />
<br />
You may also need to [https://wiki.libvirt.org/page/Networking#NAT_forwarding_.28aka_.22virtual_networks.22.29 activate the default libvirt network].<br />
<br />
=== Setting up the guest OS ===<br />
<br />
The process of setting up a VM using {{ic|virt-manager}} is mostly self-explanatory, as most of the process comes with fairly comprehensive on-screen instructions.<br />
<br />
If using {{ic|virt-manager}}, you have to add your user to the {{ic|libvirt}} [[user group]] to ensure authentication.<br />
<br />
However, you should pay special attention to the following steps :<br />
<br />
* When the VM creation wizard asks you to name your VM (final step before clicking "Finish"), check the "Customize before install" checkbox.<br />
* In the "Overview" section, [https://i.imgur.com/73r2ctM.png set your firmware to "UEFI"]. If the option is grayed out, make sure that:<br />
** You have correctly specified the location of your firmware in {{ic|/etc/libvirt/qemu.conf}} and restart {{ic|libvirtd.service}}.<br />
** Your hypervisor is running as a system session and not a user session. This can be verified [https://i.ibb.co/N1XZCdp/Deepin-Screenshot-select-area-20190125113216.png by clicking, then hovering] over the session in virt-manager. If you are accidentally running it as a user session, you must open a new connection by clicking "File" > "Add Connection..", then select the option from the drop-down menu station "QEMU/KVM" and not "QEMU/KVM user session".<br />
* In the "CPUs" section, change your CPU model to "host-passthrough". If it is not in the list, you will have to type it by hand. This will ensure that your CPU is detected properly, since it causes libvirt to expose your CPU capabilities exactly as they are instead of only those it recognizes (which is the preferred default behavior to make CPU behavior easier to reproduce). Without it, some applications may complain about your CPU being of an unknown model.<br />
* If you want to minimize IO overhead, go into "Add Hardware" and add a Controller for SCSI drives of the "VirtIO SCSI" model. You can then change the default IDE disk for a SCSI disk, which will bind to said controller.<br />
** Windows VMs will not recognize those drives by default, so you need to download the ISO containing the drivers from [https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/ here] and add an IDE (or SATA for Windows 8.1 and newer) CD-ROM storage device linking to said ISO, otherwise you will not be able to get Windows to recognize it during the installation process. When prompted to select a disk to install windows on, load the drivers contained on the CD-ROM under ''vioscsi''.<br />
<br />
The rest of the installation process will take place as normal using a standard QXL video adapter running in a window. At this point, there is no need to install additional drivers for the rest of the virtual devices, since most of them will be removed later on. Once the guest OS is done installing, simply turn off the virtual machine. It is possible you will be dropped into the UEFI menu instead of starting the installation upon powering your VM for the first time. Sometimes the correct ISO file was not automatically detected and you will need to manually specify the drive to boot. By typing exit and navigating to "boot manager" you will enter a menu that allows you to choose between devices.<br />
<br />
=== Attaching the PCI devices ===<br />
<br />
With the installation done, it is now possible to edit the hardware details in libvirt and remove virtual integration devices, such as the spice channel and virtual display, the QXL video adapter, the emulated mouse and keyboard and the USB tablet device. Since that leaves you with no input devices, you may want to bind a few USB host devices to your VM as well, but remember to '''leave at least one mouse and/or keyboard assigned to your host''' in case something goes wrong with the guest. At this point, it also becomes possible to attach the PCI device that was isolated earlier; simply click on "Add Hardware" and select the PCI Host Devices you want to passthrough. If everything went well, the screen plugged into your GPU should show the OVMF splash screen and your VM should start up normally. From there, you can setup the drivers for the rest of your VM.<br />
<br />
=== Passing keyboard/mouse via Evdev ===<br />
<br />
If you do not have a spare mouse or keyboard to dedicate to your guest, and you do not want to suffer from the video overheard of Spice, you can setup evdev to swap control of your mouse and keyboard between the host and guest on the fly.<br />
<br />
First, modify the libvirt configuration<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm' xmlns:qemu<nowiki>='http://libvirt.org/schemas/domain/qemu/1.0'</nowiki>><br />
}}<br />
<br />
Next, find your keyboard and mouse devices in {{ic|/dev/input/by-id/}}. You may find multiple devices associated to your mouse or keyboard, so try {{ic|cat /dev/input/by-id/''device_id''}} and either hit some keys on the keyboard or wiggle your mouse to see if input comes through, if so you have got the right device. Now add those devices to your configuration right before the closing </domain> tag:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<qemu:commandline><br />
<qemu:arg value='-object'/><br />
<qemu:arg value='input-linux,id=mouse1,evdev=/dev/input/by-id/MOUSE_NAME'/><br />
<qemu:arg value='-object'/><br />
<qemu:arg value='input-linux,id=kbd1,evdev=/dev/input/by-id/KEYBOARD_NAME,grab_all=on,repeat=on'/><br />
</qemu:commandline><br />
...<br />
</nowiki>}}<br />
<br />
Replace {{ic|MOUSE_NAME}} and {{ic|KEYBOARD_NAME}} with your device id. You will also need to include these devices in your qemu config, and setting the user and group to one that has access to your input devices:<br />
<br />
{{hc|/etc/libvirt/qemu.conf|<nowiki><br />
...<br />
user = "<your_user>"<br />
group = "kvm"<br />
...<br />
cgroup_device_acl = [<br />
"/dev/kvm",<br />
"/dev/input/by-id/KEYBOARD_NAME",<br />
"/dev/input/by-id/MOUSE_NAME",<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/sev"<br />
]<br />
...<br />
</nowiki>}}<br />
<br />
Then ensure that the user you provided has access to the {{ic|kvm}} and {{ic|input}} [[user group]]s. [[Restart]] {{ic|libvirtd.service}}. Now you can startup the guest OS and test swapping control of your mouse and keyboard between the host and guest by pressing both the left and right control keys at the same time.<br />
<br />
You may also consider switching from PS/2 to Virtio inputs in your configurations:<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<input type='mouse' bus='virtio'><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x0e' function='0x0'/><br />
</input><br />
<input type='keyboard' bus='virtio'><br />
<address type='pci' domain='0x0000' bus='0x00' slot='0x0f' function='0x0'/><br />
</input><br />
<input type='mouse' bus='ps2'/><br />
<input type='keyboard' bus='ps2'/><br />
...<br />
</nowiki>}}<br />
<br />
Next startup the guest OS and install the virtIO drivers for those devices.<br />
<br />
=== Gotchas ===<br />
<br />
==== Using a non-EFI image on an OVMF-based VM ====<br />
<br />
The OVMF firmware does not support booting off non-EFI mediums. If the installation process drops you in a UEFI shell right after booting, you may have an invalid EFI boot media. Try using an alternate Linux/Windows image to determine if you have an invalid media.<br />
<br />
== Performance tuning ==<br />
<br />
Most use cases for PCI passthroughs relate to performance-intensive domains such as video games and GPU-accelerated tasks. While a PCI passthrough on its own is a step towards reaching native performance, there are still a few ajustments on the host and guest to get the most out of your VM.<br />
<br />
=== CPU pinning ===<br />
<br />
The default behavior for KVM guests is to run operations coming from the guest as a number of threads representing virtual processors. Those threads are managed by the Linux scheduler like any other thread and are dispatched to any available CPU cores based on niceness and priority queues. As such, the local CPU cache benefits (L1/L2) are lost each time the host scheduler reschedules the virtual CPU thread on a different physical CPU. This can noticeably harm performance on the guest. CPU pinning aims to resolve this by limiting which physical CPUs the virtual CPUs are allowed to run on. The ideal setup is a one to one mapping such that the virtual CPU cores match physical CPU cores while taking hyperthreading/SMT into account.<br />
<br />
{{Note|For certain users enabling CPU pinning may introduce stuttering and short hangs, especially with the MuQSS scheduler (present in linux-ck and linux-zen kernels). You might want to try disabling pinning first if you experience similar issues, which effectively trades maximum performance for responsiveness at all times.}}<br />
<br />
==== CPU topology ====<br />
<br />
Most modern CPU's support hardware multitasking, also known as hyper-threading on Intel CPU's or SMT on AMD CPU's. Hyper-threading/SMT is simply a very efficient way of running two threads on one CPU core at any given time. You will want to take into consideration that the CPU pinning you choose will greatly depend on what you do with your host while your VM is running.<br />
<br />
To find the topology for your CPU run {{ic|1=lscpu -e}}:<br />
<br />
{{Note|Pay special attention to the 4th column '''"CORE"''' as this shows the association of the Physical/Logical CPU cores}}<br />
<br />
{{ic|lscpu -e}} on a 6c/12t Ryzen 5 1600:<br />
<br />
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ<br />
0 0 0 0 0:0:0:0 yes 3800.0000 1550.0000<br />
1 0 0 0 0:0:0:0 yes 3800.0000 1550.0000<br />
2 0 0 1 1:1:1:0 yes 3800.0000 1550.0000<br />
3 0 0 1 1:1:1:0 yes 3800.0000 1550.0000<br />
4 0 0 2 2:2:2:0 yes 3800.0000 1550.0000<br />
5 0 0 2 2:2:2:0 yes 3800.0000 1550.0000<br />
6 0 0 3 3:3:3:1 yes 3800.0000 1550.0000<br />
7 0 0 3 3:3:3:1 yes 3800.0000 1550.0000<br />
8 0 0 4 4:4:4:1 yes 3800.0000 1550.0000<br />
9 0 0 4 4:4:4:1 yes 3800.0000 1550.0000<br />
10 0 0 5 5:5:5:1 yes 3800.0000 1550.0000<br />
11 0 0 5 5:5:5:1 yes 3800.0000 1550.0000<br />
<br />
{{Note|Ryzen 3000 ComboPi AGESA changes topology to match Intel example, even on prior generation CPUs. Above valid only on older AGESA. }}<br />
<br />
{{ic|lscpu -e}} on a 6c/12t Intel 8700k:<br />
<br />
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ<br />
0 0 0 0 0:0:0:0 yes 4600.0000 800.0000<br />
1 0 0 1 1:1:1:0 yes 4600.0000 800.0000<br />
2 0 0 2 2:2:2:0 yes 4600.0000 800.0000<br />
3 0 0 3 3:3:3:0 yes 4600.0000 800.0000<br />
4 0 0 4 4:4:4:0 yes 4600.0000 800.0000<br />
5 0 0 5 5:5:5:0 yes 4600.0000 800.0000<br />
6 0 0 0 0:0:0:0 yes 4600.0000 800.0000<br />
7 0 0 1 1:1:1:0 yes 4600.0000 800.0000<br />
8 0 0 2 2:2:2:0 yes 4600.0000 800.0000<br />
9 0 0 3 3:3:3:0 yes 4600.0000 800.0000<br />
10 0 0 4 4:4:4:0 yes 4600.0000 800.0000<br />
11 0 0 5 5:5:5:0 yes 4600.0000 800.0000<br />
<br />
As we see above, with AMD '''Core 0''' is sequential with '''CPU 0 & 1''', whereas Intel places '''Core 0''' on '''CPU 0 & 6'''.<br />
<br />
If you do not need all cores for the guest, it would then be preferable to leave at the very least one core for the host. Choosing which cores one to use for the host or guest should be based on the specific hardware characteristics of your CPU, however '''Core 0''' is a good choice for the host in most cases. If any cores are reserved for the host, it is recommended to pin the emulator and iothreads, if used, to the host cores rather than the VCPUs. This may improve performance and reduce latency for the guest since those threads will not pollute the cache or contend for scheduling with the guest VCPU threads. If all cores are passed to the guest, there is no need or benefit to pinning the emulator or iothreads.<br />
<br />
==== XML examples ====<br />
<br />
{{Note|Do not use the '''iothread''' lines from the XML examples shown below if you have not added an '''iothread''' to your disk controller. '''iothread''''s only work on '''virtio-scsi''' or '''virtio-blk''' devices.}}<br />
<br />
===== 4c/1t CPU w/o Hyperthreading Example =====<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='0'/><br />
<vcpupin vcpu='1' cpuset='1'/><br />
<vcpupin vcpu='2' cpuset='2'/><br />
<vcpupin vcpu='3' cpuset='3'/><br />
</cputune><br />
...<br />
</nowiki>}}<br />
<br />
===== 4c/2t Intel CPU pinning example =====<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<vcpu placement='static'>8</vcpu><br />
<iothreads>1</iothreads><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='8'/><br />
<vcpupin vcpu='2' cpuset='3'/><br />
<vcpupin vcpu='3' cpuset='9'/><br />
<vcpupin vcpu='4' cpuset='4'/><br />
<vcpupin vcpu='5' cpuset='10'/><br />
<vcpupin vcpu='6' cpuset='5'/><br />
<vcpupin vcpu='7' cpuset='11'/><br />
<emulatorpin cpuset='0,6'/><br />
<iothreadpin iothread='1' cpuset='0,6'/><br />
</cputune><br />
...<br />
<topology sockets='1' cores='4' threads='2'/><br />
...<br />
</nowiki>}}<br />
<br />
===== 4c/2t AMD CPU example (Before ComboPi AGESA) =====<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<vcpu placement='static'>8</vcpu><br />
<iothreads>1</iothreads><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='3'/><br />
<vcpupin vcpu='2' cpuset='4'/><br />
<vcpupin vcpu='3' cpuset='5'/><br />
<vcpupin vcpu='4' cpuset='6'/><br />
<vcpupin vcpu='5' cpuset='7'/><br />
<vcpupin vcpu='6' cpuset='8'/><br />
<vcpupin vcpu='7' cpuset='9'/><br />
<emulatorpin cpuset='0-1'/><br />
<iothreadpin iothread='1' cpuset='0-1'/><br />
</cputune><br />
...<br />
<topology sockets='1' cores='4' threads='2'/><br />
...<br />
</nowiki>}}<br />
<br />
{{Note|If further CPU isolation is needed, consider using the '''isolcpus''' kernel command-line parameter on the unused physical/logical cores.}}<br />
<br />
If you do not intend to be doing any computation-heavy work on the host (or even anything at all) at the same time as you would on the VM, you may want to pin your VM threads across all of your cores, so that the VM can fully take advantage of the spare CPU time the host has available. Be aware that pinning all physical and logical cores of your CPU could induce latency in the guest VM.<br />
<br />
=== Huge memory pages ===<br />
<br />
When dealing with applications that require large amounts of memory, memory latency can become a problem since the more memory pages are being used, the more likely it is that this application will attempt to access information across multiple memory "pages", which is the base unit for memory allocation. Resolving the actual address of the memory page takes multiple steps, and so CPUs normally cache information on recently used memory pages to make subsequent uses on the same pages faster. Applications using large amounts of memory run into a problem where, for instance, a virtual machine uses 4 GiB of memory divided into 4 KiB pages (which is the default size for normal pages) for a total of 1.04 million pages, meaning that such cache misses can become extremely frequent and greatly increase memory latency. Huge pages exist to mitigate this issue by giving larger individual pages to those applications, increasing the odds that multiple operations will target the same page in succession.<br />
<br />
==== Transparent huge pages ====<br />
<br />
QEMU will use 2MiB sized transparent huge pages automatically without any explicit configuration in QEMU or Libvirt, subject to some important caveats. When using VFIO the pages are locked in at boot time and transparent huge pages are allocated up front when the VM first boots. If the kernel memory is highly fragmented, or the VM is using a majority of the remaining free memory, it is likely that the kernel will not have enough 2MiB pages to fully satisfy the allocation. In such a case, it silently fails by using a mix of 2MiB and 4KiB pages. Since the pages are locked in VFIO mode, the kernel will not be able to convert those 4KiB pages to huge after the VM starts either. The number of available 2MiB huge pages available to THP is the same as via the [[#Dynamic huge pages]] mechanism described in the following sections.<br />
<br />
To check how much memory THP is using globally:<br />
<br />
$ grep AnonHugePages /proc/meminfo<br />
AnonHugePages: 8091648 kB<br />
<br />
To check a specific QEMU instance. QEMU's PID must be substituted in the grep command:<br />
<br />
$ grep -P 'AnonHugePages:\s+(?!0)\d+' /proc/[PID]/smaps<br />
AnonHugePages: 8087552 kB<br />
<br />
In this example, the VM was allocated 8388608KiB of memory, but only 8087552KiB was available via THP. The remaining 301056KiB are allocated as 4KiB pages. Aside from manually checking, there is no indication when partial allocations occur. As such, THP's effectiveness is very much dependent on the host system's memory fragmentation at the time of VM startup. If this trade off is unacceptable or strict guarantees are required, [[#Static huge pages]] is recommended.<br />
<br />
Arch kernels have THP compiled in and enabled by default with {{ic|1=/sys/kernel/mm/transparent_hugepage/enabled}} set to {{ic|1=madvise}} mode.<br />
<br />
==== Static huge pages ====<br />
<br />
While transparent huge pages should work in the vast majority of cases, they can also be allocated statically during boot. This should only be needed to make use 1 GiB hugepages on machines that support it, since transparent huge pages normally only go up to 2 MiB.<br />
<br />
{{Warning|Static huge pages lock down the allocated amount of memory, making it unavailable for applications that are not configured to use them. Allocating 4 GiBs worth of huge pages on a machine with 8 GiB of memory will only leave you with 4 GiB of available memory on the host '''even when the VM is not running'''.}}<br />
<br />
To allocate huge pages at boot, one must simply specify the desired amount on their kernel command line with {{ic|1=hugepages=''x''}}. For instance, reserving 1024 pages with {{ic|1=hugepages=1024}} and the default size of 2048 KiB per huge page creates 2 GiB worth of memory for the virtual machine to use.<br />
<br />
If supported by CPU page size could be set manually. 1 GiB huge page support could be verified by {{ic|grep pdpe1gb /proc/cpuinfo}}. Setting 1 GiB huge page size via kernel parameters : {{ic|1=default_hugepagesz=1G hugepagesz=1G hugepages=X}}.<br />
<br />
Also, since static huge pages can only be used by applications that specifically request it, you must add this section in your libvirt domain configuration to allow kvm to benefit from them :<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<memoryBacking><br />
<hugepages/><br />
</memoryBacking><br />
...<br />
</nowiki>}}<br />
<br />
==== Dynamic huge pages ====<br />
<br />
{{Accuracy|Need futher testing if this variant as effective as static one}}<br />
<br />
Hugepages could be allocated manually via {{ic|vm.nr_overcommit_hugepages}} [[sysctl]] parameter.<br />
<br />
{{hc|/etc/sysctl.d/10-kvm.conf|2=<br />
vm.nr_hugepages = 0<br />
vm.nr_overcommit_hugepages = ''num''<br />
}}<br />
<br />
Where {{ic|''num''}} - is the number of huge pages, which default size if 2 MiB.<br />
Pages will be automatically allocated, and freed after VM stops.<br />
<br />
More manual way:<br />
<br />
# echo ''num'' > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages<br />
# echo ''num'' > /sys/kernel/mm/hugepages/hugepages-1048576kB/nr_hugepages<br />
<br />
For 2 MiB and 1 GiB page size respectively.<br />
And they should be manually freed in the same way.<br />
<br />
It is hardly recommended to drop caches, compact memory and wait couple of seconds before starting VM, as there could be not enough free contiguous memory for required huge pages blocks. Especially after some uptime of the host system.<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# echo 1 > /proc/sys/vm/compact_memory<br />
<br />
Theoretically, 1 GiB pages works as 2 MiB. But practically - no guaranteed way was found to get contiguous 1 GiB memory blocks. Each consequent request of 1 GiB blocks lead to lesser and lesser dynamically allocated count.<br />
<br />
=== CPU frequency governor ===<br />
<br />
Depending on the way your [[CPU frequency scaling|CPU governor]] is configured, the VM threads may not hit the CPU load thresholds for the frequency to ramp up. Indeed, KVM cannot actually change the CPU frequency on its own, which can be a problem if it does not scale up with vCPU usage as it would result in underwhelming performance. An easy way to see if it behaves correctly is to check if the frequency reported by {{ic|watch lscpu}} goes up when running a CPU-intensive task on the guest. If you are indeed experiencing stutter and the frequency does not go up to reach its reported maximum, it may be due to [https://lime-technology.com/forum/index.php?topic=46664.msg447678#msg447678 cpu scaling being controlled by the host OS]. In this case, try setting all cores to maximum frequency to see if this improves performance. Note that if you are using a modern intel chip with the default pstate driver, cpupower commands will be [[CPU frequency scaling#CPU frequency driver|ineffective]], so monitor {{ic|/proc/cpuinfo}} to make sure your cpu is actually at max frequency.<br />
<br />
=== CPU pinning with isolcpus ===<br />
<br />
Alternatively, make sure that you have isolated CPUs properly. In this example, let us assume you are using CPUs 4-7.<br />
Use the [[kernel parameters]] {{ic|isolcpus nohz_full rcu_nocbs}} to completely isolate the CPUs from the kernel. For example:<br />
<br />
isolcpus=4-7 nohz_full=4-7 rcu_nocbs=4-7<br />
<br />
Then, run {{ic|qemu-system-x86_64}} with taskset and chrt:<br />
<br />
# chrt -r 1 taskset -c 4-7 qemu-system-x86_64 ...<br />
<br />
The {{ic|chrt}} command will ensure that the task scheduler will round-robin distribute work (otherwise it will all stay on the first cpu). For {{ic|taskset}}, the CPU numbers can be comma- and/or dash-separated, like "0,1,2,3" or "0-4" or "1,7-8,10" etc.<br />
<br />
See [https://www.removeddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ this Removeddit mirror of a Reddit thread] for more info. ([https://www.reddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ The original thread] is worthless because of deleted comments.)<br />
<br />
=== Improving performance on AMD CPUs ===<br />
<br />
Previously, Nested Page Tables (NPT) had to be disabled on AMD systems running KVM to improve GPU performance because of a [https://sourceforge.net/p/kvm/bugs/230/ very old bug], but the trade off was decreased CPU performance, including stuttering.<br />
<br />
There is a [https://patchwork.kernel.org/patch/10027525/ kernel patch] that resolves this issue, which was accepted into kernel 4.14-stable and 4.9-stable. If you are running the official {{Pkg|linux}} or {{Pkg|linux-lts}} kernel the patch has already been applied (make sure you are on the latest). If you are running another kernel you might need to manually patch yourself.<br />
<br />
{{Note|Several Ryzen users (see [https://www.reddit.com/r/VFIO/comments/78i3jx/possible_fix_for_the_npt_issue_discussed_on_iommu/ this Reddit thread]) have tested the patch, and can confirm that it works, bringing GPU passthrough performance up to near native quality.}}<br />
<br />
Starting with QEMU 3.1 the TOPOEXT cpuid flag is disabled by default. In order to use hyperthreading(SMT) on AMD CPU's you need to manually enable it:<br />
<br />
<cpu mode='host-passthrough' check='none'><br />
<topology sockets='1' cores='4' threads='2'/><br />
<feature policy='require' name='topoext'/><br />
</cpu><br />
<br />
commit: https://git.qemu.org/?p=qemu.git;a=commit;h=7210a02c58572b2686a3a8d610c6628f87864aed<br />
<br />
=== Further tuning ===<br />
<br />
More specialized VM tuning tips are available at [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Virtualization_Tuning_and_Optimization_Guide/index.html Red Hat's Virtualization Tuning and Optimization Guide]. This guide may be especially helpful if you are experiencing:<br />
<br />
* Moderate CPU load on the host during downloads/uploads from within the guest: See ''Bridge Zero Copy Transmit'' for a potential fix.<br />
* Guests capping out at certain network speeds during downloads/uploads despite virtio-net being used: See ''Multi-queue virtio-net'' for a potential fix.<br />
* Guests "stuttering" under high I/O, despite the same workload not affecting hosts to the same degree: See ''Multi-queue virtio-scsi'' for a potential fix.<br />
<br />
== Special procedures ==<br />
<br />
Certain setups require specific configuration tweaks in order to work properly. If you are having problems getting your host or your VM to work properly, see if your system matches one of the cases below and try adjusting your configuration accordingly.<br />
<br />
=== Using identical guest and host GPUs ===<br />
<br />
{{Expansion|A number of users have been having issues with this, it should probably be adressed by the article.|Talk:PCI passthrough via OVMF#Additionnal sections}}<br />
<br />
Due to how vfio-pci uses your vendor and device id pair to identify which device they need to bind to at boot, if you have two GPUs sharing such an ID pair you will not be able to get your passthough driver to bind with just one of them. This sort of setup makes it necessary to use a script, so that whichever driver you are using is instead assigned by pci bus address using the {{ic|driver_override}} mechanism.<br />
<br />
==== Script variants ====<br />
<br />
===== Passthrough all GPUs but the boot GPU =====<br />
<br />
Here, we will make a script to bind vfio-pci to all GPUs but the boot gpu. Create the script {{ic|/usr/bin/vfio-pci-override.sh}}:<br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
<br />
for i in /sys/bus/pci/devices/*/boot_vga; do<br />
if [ $(cat "$i") -eq 0 ]; then<br />
GPU="${i%/boot_vga}"<br />
AUDIO="$(echo "$GPU" | sed -e "s/0$/1/")"<br />
echo "vfio-pci" > "$GPU/driver_override"<br />
if [ -d "$AUDIO" ]; then<br />
echo "vfio-pci" > "$AUDIO/driver_override"<br />
fi<br />
fi<br />
done<br />
<br />
modprobe -i vfio-pci<br />
</nowiki>}}<br />
<br />
===== Passthrough selected GPU =====<br />
<br />
In this case we manually specify the GPU to bind.<br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
<br />
DEVS="0000:03:00.0 0000:03:00.1"<br />
<br />
if [ ! -z "$(ls -A /sys/class/iommu)" ]; then<br />
for DEV in $DEVS; do<br />
echo "vfio-pci" > /sys/bus/pci/devices/$DEV/driver_override<br />
done<br />
fi<br />
</nowiki>}}<br />
<br />
==== Script installation ====<br />
<br />
Create the following files:<br />
<br />
{{hc|/etc/initcpio/install/vfio|<br />
#!/bin/bash<br />
build() {<br />
add_file /usr/bin/vfio-pci-override.sh<br />
add_runscript<br />
}<br />
}}<br />
<br />
{{hc|/etc/initcpio/hooks/vfio|<br />
#!/usr/bin/ash<br />
<br />
run_hook() {<br />
msg ":: Triggering vfio-pci override"<br />
/bin/sh /usr/bin/vfio-pci-override.sh<br />
}<br />
}}<br />
<br />
Edit {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
# Remove any video drivers from {{ic|MODULES}}.<br />
# Add {{ic|/usr/bin/vfio-pci-override.sh}} to FILES: {{bc|1=FILES=(/usr/bin/vfio-pci-override.sh)}}<br />
# Add {{ic|vfio}} to {{ic|HOOKS}}: {{bc|1=HOOKS=(... vfio)}}<br />
# [[Regenerate the initramfs]] and reboot.<br />
<br />
{{Warning|If there is a syntax error in the hook, the boot will fail with a kernel panic. Be careful when generating the hook, and have install media handy in case you have to recover.}}<br />
<br />
=== Passing the boot GPU to the guest ===<br />
<br />
{{Expansion|This is related to VBIOS issues and should be moved into a separate section regarding VBIOS compatibility.|section=UEFI (OVMF) Compatibility in VBIOS}}<br />
<br />
The GPU marked as {{ic|boot_vga}} is a special case when it comes to doing PCI passthroughs, since the BIOS needs to use it in order to display things like boot messages or the BIOS configuration menu. To do that, it makes [https://www.redhat.com/archives/vfio-users/2016-May/msg00224.html a copy of the VGA boot ROM which can then be freely modified]. This modified copy is the version the system gets to see, which the passthrough driver may reject as invalid. As such, it is generally recommended to change the boot GPU in the BIOS configuration so the host GPU is used instead or, if that is not possible, to swap the host and guest cards in the machine itself.<br />
<br />
=== Using Looking Glass to stream guest screen to the host ===<br />
<br />
It is possible to make VM share the monitor, and optionally a keyboard and a mouse with a help of [https://looking-glass.hostfission.com/ Looking Glass].<br />
<br />
==== Adding IVSHMEM Device to VM ====<br />
<br />
Looking glass works by creating a shared memory buffer between a host and a guest. This is a lot faster than streaming frames via localhost, but requires additional setup. <br />
<br />
With your VM turned off open the machine configuration<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<devices><br />
...<br />
<shmem name='looking-glass'><br />
<model type='ivshmem-plain'/><br />
<size unit='M'>32</size><br />
</shmem><br />
</devices><br />
...<br />
</nowiki>}}<br />
<br />
You should replace 32 with your own calculated value based on what resolution you are going to pass through. It can be calculated like this:<br />
<br />
width x height x 4 x 2 = total bytes<br />
total bytes / 1024 / 1024 = total mebibytes + 2<br />
<br />
For example, in case of 1920x1080<br />
<br />
1920 x 1080 x 4 x 2 = 16,588,800 bytes<br />
16,588,800 / 1024 / 1024 = 15.82 MiB + 2 = 17.82<br />
<br />
The result must be '''rounded up''' to the nearest power of two, and since 17.82 is bigger than 16 we should choose 32.<br />
<br />
Next create a configuration file to create the shared memory file on boot<br />
<br />
{{hc|/etc/tmpfiles.d/10-looking-glass.conf|2=<br />
f /dev/shm/looking-glass 0660 '''user''' kvm -<br />
}}<br />
Replace user with your username.<br />
<br />
Ask systemd-tmpfiles to create the shared memory file now without waiting to next boot<br />
<br />
# systemd-tmpfiles --create /etc/tmpfiles.d/10-looking-glass.conf<br />
<br />
<br />
==== Installing the IVSHMEM Host to Windows guest ====<br />
<br />
Currently Windows would not notify users about a new IVSHMEM device, it would silently install a dummy driver. To actually enable the device you have to go into device manager and update the driver for the device under the "System Devices" node for '''"PCI standard RAM Controller"'''. Download the signed driver [https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/upstream-virtio/ from Red Hat].<br />
<br />
Once the driver is installed you must download a matching [https://github.com/gnif/LookingGlass/releases looking-glass-host] that matches the client you installed from AUR and start it on your guest. In order to run it you would also need to install Microsoft Visual C++ Redistributable from [https://www.visualstudio.com/downloads/ Microsoft]<br />
It is also possible to make it start automatically on VM boot by editing the {{ic|HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run}} registry and adding a path to the downloaded executable.<br />
<br />
==== Getting a client ====<br />
<br />
Looking glass client can be installed from AUR using {{AUR|looking-glass}} or {{AUR|looking-glass-git}} packages.<br />
<br />
You can start it once the VM is set up and running<br />
<br />
$ looking-glass-client<br />
<br />
If you do not want to use Spice to control the guest mouse and keyboard you can disable the Spice server.<br />
<br />
$ looking-glass-client -s<br />
<br />
Additionally you may want to start Looking Glass Client as full screen, otherwise the image may be scaled down resulting in poor image fidelity.<br />
<br />
$ looking-glass-client -F<br />
<br />
Launch with the {{ic|--help}} option for further information.<br />
<br />
=== Swap peripherals to and from the Host ===<br />
<br />
Looking Glass includes a Spice client in order to control mouse movement on the Windows guest. However this may have too much latency for certain applications, such as gaming. An alternative method is passing through specific USB devices for minimal latency. This allows for switching the devices between host and guest.<br />
<br />
First create a .xml file for the device(s) you wish to pass-through, which libvirt will use to identify the device.<br />
<br />
{{hc|/home/$USER/.VFIOinput/input_1.xml|2=<br />
<hostdev mode='subsystem' type='usb' managed='no'><br />
<source><br />
<vendor id='0x[Before Colon]'/><br />
<product id='0x[After Colon]'/><br />
</source><br />
</hostdev><br />
}}<br />
<br />
Replace [Before/After Colon] with the contents of the 'lsusb' command, specific to the device you want to pass-through.<br />
<br />
For instance my mouse is {{ic|Bus 005 Device 002: ID 1532:0037 Razer USA, Ltd}} so I would replace {{ic|vendor id}} with 1532, and {{ic|product id}} with 1037.<br />
<br />
Repeat this process for any additional USB devices you want to pass-through. If your mouse / keyboard has multiple entries in {{ic|lsusb}}, perhaps if it is wireless, then create additional xml files for each.<br />
<br />
{{Note|Do not forget to change the path & name of the script(s) above and below to match your user and specific system.}}<br />
<br />
Next a bash script file is needed to tell libvirt what to attach/detach the USB devices to the guest.<br />
<br />
{{hc|/home/$USER/.VFIOinput/input_attach.sh|2=<br />
#!/bin/bash<br />
<br />
virsh attach-device [VM-Name] [USBdevice]<br />
}}<br />
<br />
Replace [VM-Name] with the name of your virtual machine, which can be seen under virt-manager. Additionally replace [USBdevice] with the '''full''' path to the .xml file for the device you wish to pass-through. Add additional lines for more than 1 device. For example here is my script:<br />
<br />
{{hc|/home/$USER/.VFIOinput/input_attach.sh|2=<br />
#!/bin/bash<br />
<br />
virsh attach-device win10 /home/$USER/.VFIOinput/input_mouse.xml<br />
virsh attach-device win10 /home/$USER/.VFIOinput/input_keyboard.xml<br />
}}<br />
<br />
Next duplicate the script file and replace {{ic|attach-device}} with {{ic|detach-device}}. Ensure both scripts are executable with {{ic|chmod +x $script.sh}}<br />
<br />
This 2 script files can now be executed to attach or detach your USB devices from the host to the guest VM. It is important to note that they may need to be executed as root. To run the script from the Windows VM, one possibility is using [[PuTTY]] to [[SSH]] into the host, and execute the script. On Windows PuTTY comes with plink.exe which can execute singular commands over SSH before then logging out, instead of opening a SSH terminal, all in the background.<br />
<br />
{{hc|detach_devices.bat|2=<br />
"C:\Program Files\PuTTY\plink.exe" root@$HOST_IP -pw $ROOTPASSWORD /home/$USER/.VFIOinput/input_detach.sh<br />
}}<br />
<br />
Replace {{ic|$HOST_IP}} with the Host [[Network configuration#IP addresses|IP Address]] and $ROOTPASSWORD with the root password.<br />
<br />
{{warning|This method is insecure if somebody has access to your VM, since they could open the file and read your password. It is advisable to use [[SSH keys]] instead!}}<br />
<br />
You may also want to execute the script files using key binds. On Windows one option is [https://autohotkey.com/ Autohotkey], and on the Host [[Xbindkeys]]. Because of the need to run the scripts as root, you may also need to use [[Polkit]] or [[Sudo]] which can both be used to authenticate specific executables as able to run as root without needing a password.<br />
<br />
=== Bypassing the IOMMU groups (ACS override patch) ===<br />
<br />
If you find your PCI devices grouped among others that you do not wish to pass through, you may be able to seperate them using Alex Williamson's ACS override patch. Make sure you understand [https://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html the potential risk] of doing so. <br />
<br />
You will need a kernel with the patch applied. The easiest method to acquiring this is through the {{AUR|linux-vfio}} package. <br />
<br />
In addition, the ACS override patch needs to be enabled with kernel command line options. The patch file adds the following documentation:<br />
<br />
pcie_acs_override =<br />
[PCIE] Override missing PCIe ACS support for:<br />
downstream<br />
All downstream ports - full ACS capabilties<br />
multifunction<br />
All multifunction devices - multifunction ACS subset<br />
id:nnnn:nnnn<br />
Specfic device - full ACS capabilities<br />
Specified as vid:did (vendor/device ID) in hex<br />
<br />
The option {{ic|1=pcie_acs_override=downstream}} is typically sufficient.<br />
<br />
After installation and configuration, reconfigure your [[Kernel parameters|bootloader kernel parameters]] to load the new kernel with the {{ic|1=pcie_acs_override=}} option enabled.<br />
<br />
== Plain QEMU without libvirt ==<br />
<br />
Instead of setting up a virtual machine with the help of libvirt, plain QEMU commands with custom parameters can be used for running the VM intended to be used with PCI passthrough. This is desirable for some use cases like scripted setups, where the flexibility for usage with other scripts is needed.<br />
<br />
To achieve this after [[#Setting up IOMMU]] and [[#Isolating the GPU]], follow the [[QEMU]] article to setup the virtualized environment, [[QEMU#Enabling KVM|enable KVM]] on it and use the flag {{ic|1=-device vfio-pci,host=07:00.0}} replacing the identifier (07:00.0) with your actual device's ID that you used for the GPU isolation earlier.<br />
<br />
For utilizing the OVMF firmware, make sure the {{Pkg|ovmf}} package is installed, copy the UEFI variables from {{ic|/usr/share/ovmf/x64/OVMF_VARS.fd}} to temporary location like {{ic|/tmp/MY_VARS.fd}} and finally specify the OVMF paths by appending the following parameters to the QEMU command (order matters):<br />
<br />
* {{ic|1=-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/OVMF_CODE.fd}} for the actual OVMF firmware binary, note the readonly option<br />
* {{ic|1=-drive if=pflash,format=raw,file=/tmp/MY_VARS.fd}} for the variables<br />
<br />
{{Note|QEMU's default SeaBIOS can be used instead of OVMF, but it is not recommended as it can cause issues with passthrough setups.}}<br />
<br />
It is recommended to study the QEMU article for ways to enhance the performance by using the [[QEMU#Installing virtio drivers|virtio drivers]] and other further configurations for the setup.<br />
<br />
You also might have to use the {{ic|1=-cpu host,kvm=off}} parameter to forward the host's CPU model info to the VM and fool the virtualization detection used by Nvidia's and possibly other manufacturers' device drivers trying to block the full hardware usage inside a virtualized system.<br />
<br />
== Passing though other devices ==<br />
<br />
=== USB controller ===<br />
<br />
If your motherboard has multiple USB controllers mapped to multiple groups, it is possible to pass those instead of USB devices. Passing an actual controller over an individual USB device provides the following advantages : <br />
<br />
* If a device disconnects or changes ID over the course of an given operation (such as a phone undergoing an update), the VM will not suddenly stop seeing it.<br />
* Any USB port managed by this controller is directly handled by the VM and can have its devices unplugged, replugged and changed without having to notify the hypervisor.<br />
* Libvirt will not complain if one of the USB devices you usually pass to the guest is missing when starting the VM.<br />
<br />
Unlike with GPUs, drivers for most USB controllers do not require any specific configuration to work on a VM and control can normally be passed back and forth between the host and guest systems with no side effects.<br />
<br />
{{Warning|Make sure your USB controller supports resetting: [[#Passing through a device that does not support resetting]]}}<br />
<br />
You can find out which PCI devices correspond to which controller and how various ports and devices are assigned to each one of them using this command :<br />
<br />
{{hc|$ <nowiki>for usb_ctrl in $(find /sys/bus/usb/devices/usb* -maxdepth 0 -type l); do pci_path="$(dirname "$(realpath "${usb_ctrl}")")"; echo "Bus $(cat "${usb_ctrl}/busnum") --> $(basename $pci_path) (IOMMU group $(basename $(realpath $pci_path/iommu_group)))"; lsusb -s "$(cat "${usb_ctrl}/busnum"):"; echo; done</nowiki>|<br />
Bus 1 --> 0000:00:1a.0 (IOMMU group 4)<br />
Bus 001 Device 004: ID 04f2:b217 Chicony Electronics Co., Ltd Lenovo Integrated Camera (0.3MP)<br />
Bus 001 Device 007: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]<br />
Bus 001 Device 008: ID 0781:5530 SanDisk Corp. Cruzer<br />
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
Bus 2 --> 0000:00:1d.0 (IOMMU group 9)<br />
Bus 002 Device 006: ID 0451:e012 Texas Instruments, Inc. TI-Nspire Calculator<br />
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub<br />
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
}}<br />
<br />
This laptop has 3 USB ports managed by 2 USB controllers, each with their own IOMMU group. In this example, Bus 001 manages a single USB port (with a SanDisk USB pendrive plugged into it so it appears on the list), but also a number of internal devices, such as the internal webcam and the bluetooth card. Bus 002, on the other hand, does not apprear to manage anything except for the calculator that is plugged into it. The third port is empty, which is why it does not show up on the list, but is actually managed by Bus 002.<br />
<br />
Once you have identified which controller manages which ports by plugging various devices into them and decided which one you want to passthrough, simply add it to the list of PCI host devices controlled by the VM in your guest configuration. No other configuration should be needed.<br />
<br />
{{Note|If your USB controller does not support resetting, is not in an isolated group, or is otherwise unable to be passed through then it may still be possible to accomplish similar results through [[udev]] rules. See [https://github.com/olavmrk/usb-libvirt-hotplug] which allows any device connected to specified USB ports to be automatically attached to a virtual machine.}}<br />
<br />
=== Passing VM audio to host via PulseAudio ===<br />
<br />
It is possible to route the virtual machine's audio to the host as an application using libvirt. This has the advantage of multiple audio streams being routable to one host output, and working with audio output devices that do not support passthrough. [[PulseAudio]] is required for this to work.<br />
<br />
First, remove the comment from the {{ic|1=#user = ""}} line. Then add your username in the quotations. This tells QEMU which user's pulseaudio stream to route through.<br />
<br />
{{hc|/etc/libvirt/qemu.conf|2=<br />
user = "example"<br />
}}<br />
<br />
Next, modify the libvirt configuration<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm' xmlns:qemu<nowiki>='http://libvirt.org/schemas/domain/qemu/1.0'</nowiki>><br />
}}<br />
<br />
Then set the QEMU PulseAudio environment variables at the bottom of the libvirt xml file<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
</devices><br />
</domain><br />
}}<br />
<br />
to<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
</devices><br />
<qemu:commandline><br />
<qemu:env name<nowiki>=</nowiki>'QEMU_AUDIO_DRV' value<nowiki>=</nowiki>'pa'/><br />
<qemu:env name<nowiki>=</nowiki>'QEMU_PA_SERVER' value<nowiki>=</nowiki>'/run/user/1000/pulse/native'/><br />
</qemu:commandline><br />
</domain><br />
}}<br />
<br />
Change 1000 under the user directory to your user uid (which can be found by running the {{ic|id}} command. Remember to save the file and exit it without ending the process before continuing, otherwise the changes will not register. If you get the message {{ic|<nowiki>Domain [vmname] XML configuration edited.</nowiki>}} after exiting, it means that your changes have been applied.<br />
<br />
[[Restart]] {{ic|libvirtd.service}} and [[systemd/User|user service]] {{ic|pulseaudio.service}}.<br />
<br />
Virtual Machine audio will now be routed through the host as an application. The application {{Pkg|pavucontrol}} can be used to control the output device. Be aware that on Windows guests, this can cause audio crackling without [[#Slowed down audio pumped through HDMI on the video card|using Message-Signaled Interrupts.]]<br />
<br />
==== QEMU 3.0 audio changes ====<br />
<br />
As of QEMU 3.0 part of the audio patches have been merged ([https://www.reddit.com/r/VFIO/comments/97iuov/qemu_30_released/e49wmyd/ reddit link]). The {{AUR|qemu-patched}} package currently includes some additional audio patches, as some of the patches have not been officially up-streamed yet.<br />
<br />
You will need to change the chipset accordingly to how your VM is set up, i.e. {{ic|pc-q35-3.0}} or {{ic|pc-i440fx-3.0}} (after installing qemu 3.0) to use the new code paths:<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
...<br />
<os><br />
<type arch<nowiki>=</nowiki>'x86_64' machine<nowiki>=</nowiki>'pc-q35-3.0'>hvm</type><br />
...<br />
</os><br />
}}<br />
<br />
{{hc|$ virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
...<br />
<os><br />
<type arch<nowiki>=</nowiki>'x86_64' machine<nowiki>=</nowiki>'pc-i440fx-3.0'>hvm</type><br />
...<br />
</os><br />
}}<br />
<br />
{{Note|<br />
* To speed up compilation time with {{AUR|qemu-patched}} use {{ic|1=--target-list=x86_64-softmmu}} to compile qemu with only x86_64 guest support.<br />
* Since Qemu 3.0 the XML arguments {{ic|qemu:env}} above are ''not'' needed if you run PulseAudio as your user and you have {{ic|1= nographics_allow_host_audio = 1}} enabled in {{ic|1=/etc/libvirt/qemu.conf}}. If you use a different user with QEMU/Libvirt, you will need to keep the {{ic|QEMU_PA_SERVER}} variable otherwise permission errors will occur.<br />
}}<br />
<br />
<br />
=== Passing VM audio to host via Scream and IVSHMEM === <br />
<br />
It's possible to pass VM audio through a IVSHMEM device to the host using [https://github.com/duncanthrax/scream scream]. <br />
This guide will only cover using PulseAudio as a receiver on the host.<br />
See the project page for more details.<br />
<br />
==== Adding the IVSHMEM ====<br />
<br />
With the VM turned off, edit the machine configuration<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<devices><br />
...<br />
<shmem name='scream-ivshmem'><br />
<model type='ivshmem-plain'/><br />
<size unit='M'>2</size><br />
</shmem><br />
</devices><br />
...<br />
</nowiki>}}<br />
<br />
In the above configuration, the size of the IVSHMEM device is 2MB (the recommended amount). Change this as needed.<br />
<br />
Now refer to [[#Adding IVSHMEM Device to VM]] to configure the host to create the shared memory file on boot, replacing {{ic|looking-glass}} with {{ic|scream-ivshmem}}.<br />
<br />
==== Configuring the Windows guest ====<br />
<br />
The correct driver must be installed for the IVSHMEM device on the guest. <br />
See [[#Installing the IVSHMEM Host to Windows guest]]. Ignore the part about {{ic|looking-glass-host}}.<br />
<br />
Install the [https://github.com/duncanthrax/scream/releases scream] virtual audio driver on the guest. <br />
If you have secure boot enabled for your VM, you may need to disable it. <br />
<br />
Using the registry editor, set the DWORD {{ic|HKLM\SYSTEM\CurrentControlSet\Services\Scream\Options\UseIVSHMEM}} to the size of the IVSHMEM device in MB.<br />
Note that scream identifies its IVSHMEM device using its size, so make sure there is only one device of that size.<br />
<br />
==== Configuring the host ====<br />
<br />
Install {{AUR|scream-pulse}}.<br />
<br />
Create the systemd user service file to control the reciever<br />
<br />
{{hc|~/.config/systemd/user/scream-ivshmem-pulse.service|<nowiki><br />
[Unit]<br />
Description=Scream IVSHMEM pulse reciever<br />
After=pulseaudio.service<br />
Wants=pulseaudio.service<br />
<br />
[Service]<br />
Type=simple<br />
ExecStartPre=/usr/bin/truncate -s 0 /dev/shm/scream-ivshmem<br />
ExecStartPre=/usr/bin/dd if=/dev/zero of=/dev/shm/scream-ivshmem bs=1M count=2<br />
ExecStart=/usr/bin/scream-ivshmem-pulse /dev/shm/scream-ivshmem<br />
<br />
[Install]<br />
WantedBy=default.target<br />
<br />
</nowiki>}}<br />
<br />
Edit {{ic|1=count=2}} with the size of the IVSHMEM device in MB.<br />
<br />
Now start the service with <br />
$ systemctl start --user scream-ivshmem-pulse<br />
<br />
To have it automatically start on next login, enable the service<br />
$ systemctl enable --user scream-ivshmem-pulse<br />
<br />
=== Physical disk/partition ===<br />
<br />
A whole disk or a partition may be used as a whole for improved I/O performance by adding an entry to the XML<br />
<br />
Virtio-BLK Example:<br />
{{hc|$ virsh edit [vmname]| <nowiki><br />
<devices><br />
...<br />
<disk type='block' device='disk'><br />
<driver name='qemu' type='raw' cache='none' io='native'/><br />
<source dev='/dev/disk/by-id/xxxxxxxx'/><br />
<target dev='vda' bus='virtio'/><br />
</disk><br />
...<br />
</devices><br />
</nowiki><br />
}}<br />
<br />
Virtio-SCSI Example:<br />
{{hc|$ virsh edit [vmname]| <nowiki><br />
<devices><br />
...<br />
<disk type='block' device='disk'><br />
<driver name='qemu' type='raw' cache='none' io='native'/><br />
<source dev='/dev/disk/by-id/xxxxxxxx'/><br />
<target dev='sda' bus='scsi'/><br />
</disk><br />
...<br />
</devices><br />
</nowiki><br />
}}<br />
<br />
To find out which disk/partition is associated with the one you would like to pass:<br />
<br />
{{hc|<br />
$ ls -l /dev/disk/by-id|<br />
ata-ST1000LM002-9VQ14L_Z0501SZ9 -> ../../sdd<br />
ata-ST1000LM002-9VQ14L_Z0501SZ9-part1 -> ../../sdd1<br />
}}<br />
<br />
You can also add the disk with Virt-Manager's '''Add Hardware''' menu and then type the disk you want in the '''Select or create custom storage''' box, e.g. '''/dev/disk/by-id/ata-ST1000LM002-9VQ14L_Z0501SZ9'''<br />
<br />
Depending on which bus you use, the above step will require either the VIOSTOR(bus=virtio) or VIOSCSI(bus=scsi) driver on Windows guests, refer to [[#Setting up the guest OS]] for the driver ISO.<br />
<br />
=== Gotchas ===<br />
<br />
==== Passing through a device that does not support resetting ====<br />
<br />
When the VM shuts down, all devices used by the guest are deinitialized by its OS in preparation for shutdown. In this state, those devices are no longer functional and must then be power-cycled before they can resume normal operation. Linux can handle this power-cycling on its own, but when a device has no known reset methods, it remains in this disabled state and becomes unavailable. Since Libvirt and Qemu both expect all host PCI devices to be ready to reattach to the host before completely stopping the VM, when encountering a device that will not reset, they will hang in a "Shutting down" state where they will not be able to be restarted until the host system has been rebooted. It is therefore reccomanded to only pass through PCI devices which the kernel is able to reset, as evidenced by the presence of a {{ic|reset}} file in the PCI device sysfs node, such as {{ic|/sys/bus/pci/devices/0000:00:1a.0/reset}}.<br />
<br />
The following bash command shows which devices can and cannot be reset.<br />
<br />
{{hc|<nowiki>for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d);do echo "IOMMU group $(basename "$iommu_group")"; for device in $(\ls -1 "$iommu_group"/devices/); do if [[ -e "$iommu_group"/devices/"$device"/reset ]]; then echo -n "[RESET]"; fi; echo -n $'\t';lspci -nns "$device"; done; done</nowiki>|<br />
IOMMU group 0<br />
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/Ivy Bridge DRAM Controller [8086:0158] (rev 09)<br />
IOMMU group 1<br />
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09)<br />
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK208 [GeForce GT 720] [10de:1288] (rev a1)<br />
01:00.1 Audio device [0403]: NVIDIA Corporation GK208 HDMI/DP Audio Controller [10de:0e0f] (rev a1)<br />
IOMMU group 2<br />
00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)<br />
IOMMU group 4<br />
[RESET] 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)<br />
IOMMU group 5<br />
[RESET] 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)<br />
IOMMU group 10<br />
[RESET] 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04)<br />
IOMMU group 13<br />
06:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
06:00.1 Audio device [0403]: NVIDIA Corporation GM204 High Definition Audio Controller [10de:0fbb] (rev a1)<br />
}}<br />
<br />
This signals that the xHCI USB controller in 00:14.0 cannot be reset and will therefore stop the VM from shutting down properly, while the integrated sound card in 00:1b.0 and the other two controllers in 00:1a.0 and 00:1d.0 do not share this problem and can be passed without issue.<br />
<br />
== Complete setups and examples ==<br />
<br />
For many reasons users may seek to see [[PCI_passthrough_via_OVMF/Examples|complete passthrough setup examples]].<br />
<br />
These examples offer a supplement to existing hardware compatibility lists. Additionally, if you have trouble configuring a certain mechanism in your setup, you might find these examples very valuable. Users there have described their setups in detail, and some have provided examples of their configuration files as well. <br />
<br />
We encourage those who successfully build their system from this resource to help improve it by contributing their builds. Due to the many different hardware manufacturers involved, the seemingly significant lack of sufficient documentation, as well as other issues due to the nature of this process, community contributions are necessary.<br />
<br />
== Troubleshooting ==<br />
<br />
If your issue is not mentioned below, you may want to browse [[QEMU#Troubleshooting]].<br />
<br />
=== QEMU 4.0: Unable to load graphics drivers/BSOD/Graphics stutter after driver install using Q35 ===<br />
<br />
Starting with QEMU 4.0, the Q35 machine type changes the default {{ic|<nowiki>kernel_irqchip</nowiki>}} from {{ic|off}} to {{ic|split}} which breaks some guest devices, such as nVidia graphics (the driver fails to load / black screen / code 43 / graphics stutters, usually when mouse moving). Switch to full KVM mode instead by adding {{ic|<nowiki><ioapic driver='kvm'/></nowiki>}} under libvirt's {{ic|<nowiki><features></nowiki>}} tag in your VM configuration or by adding {{ic|<nowiki>kernel_irqchip=on</nowiki>}} in the {{ic|-machine}} QEMU arg.<br />
<br />
=== "Error 43: Driver failed to load" on Nvidia GPUs passed to Windows VMs ===<br />
<br />
{{Note|<br />
* This may also fix SYSTEM_THREAD_EXCEPTION_NOT_HANDLED boot crashes related to Nvidia drivers.<br />
* This may also fix problems under linux guests.<br />
}}<br />
<br />
Since version 337.88, Nvidia drivers on Windows check if an hypervisor is running and fail if it detects one, which results in an Error 43 in the Windows device manager. Starting with QEMU 2.5.0 and libvirt 1.3.3, the vendor_id for the hypervisor can be spoofed, which is enough to fool the Nvidia drivers into loading anyway. All one must do is add {{ic|<nowiki>hv_vendor_id=1234567890ab</nowiki>}} to the cpu parameters in their QEMU command line, or by adding the following line to their libvirt domain configuration. The vendor_id can be whatever you prefer, however it is important to note that the vendor_id must be exactly 12 characters long, per the libvirt documentation [https://libvirt.org/formatdomain.html]:<br />
<br />
"The optional vendor_id attribute (Since 0.10.0) can be used to set the vendor id seen by the guest. It must be exactly 12 characters long."<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<features><br />
<hyperv><br />
...<br />
<vendor_id state='on' value='1234567890ab'/><br />
...<br />
</hyperv><br />
...<br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features><br />
...<br />
</nowiki>}}<br />
<br />
Users with older versions of QEMU and/or libvirt will instead have to disable a few hypervisor extensions, which can degrade performance substantially. If this is what you want to do, do the following replacement in your libvirt domain config file.<br />
<br />
{{hc|$ virsh edit [vmname]|<nowiki><br />
...<br />
<features><br />
<hyperv><br />
<relaxed state='on'/><br />
<vapic state='on'/><br />
<spinlocks state='on' retries='8191'/><br />
</hyperv><br />
...<br />
</features><br />
...<br />
<clock offset='localtime'><br />
<timer name='hypervclock' present='yes'/><br />
</clock><br />
...<br />
</nowiki>}}<br />
<br />
{{bc|<nowiki><br />
...<br />
<clock offset='localtime'><br />
<timer name='hypervclock' present='no'/><br />
</clock><br />
...<br />
<features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
...<br />
<hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv><br />
...<br />
</features><br />
...<br />
</nowiki>}}<br />
<br />
=== "BAR 3: cannot reserve [mem]" error in dmesg after starting VM ===<br />
<br />
{{Expansion|This error is actually related to the boot_vgs issue and should be merged together with everything else concerning GPU ROMs.|section=UEFI (OVMF) Compatibility in VBIOS}}<br />
<br />
With respect to [https://www.linuxquestions.org/questions/linux-kernel-70/kernel-fails-to-assign-memory-to-pcie-device-4175487043/ this article]:<br />
<br />
If you still have code 43 check dmesg for memory reservation errors after starting up VM, if you have similar it could be the case:<br />
<br />
vfio-pci 0000:09:00.0: BAR 3: cannot reserve [mem 0xf0000000-0xf1ffffff 64bit pref]<br />
<br />
Find out a PCI Bridge your graphic card is connected to. This will give actual hierarchy of devices:<br />
<br />
$ lspci -t<br />
<br />
Before starting VM run following lines replacing IDs with actual from previous output.<br />
<br />
# echo 1 > /sys/bus/pci/devices/0000\:00\:03.1/remove<br />
# echo 1 > /sys/bus/pci/rescan<br />
<br />
{{Note|Probably setting [[kernel parameter]] {{ic|1=video=efifb:off}} is required as well. [https://pve.proxmox.com/wiki/Pci_passthrough#BAR_3:_can.27t_reserve_.5Bmem.5D_error Source]}}<br />
<br />
=== UEFI (OVMF) compatibility in VBIOS ===<br />
<br />
{{Remove|Flashing you guest GPU for the purpose of a GPU passthrough is '''never''' good advice. A full section should be dedicated to VBIOS compatibility.|section= UEFI (OVMF) Compatibility in VBIOS}}<br />
<br />
With respect to [https://pve.proxmox.com/wiki/Pci_passthrough#How_to_known_if_card_is_UEFI_.28ovmf.29_compatible this article]:<br />
<br />
Error 43 can be caused by the GPU's VBIOS without UEFI support. To check whenever your VBIOS supports it, you will have to use {{ic|rom-parser}}:<br />
<br />
$ git clone https://github.com/awilliam/rom-parser<br />
$ cd rom-parser && make<br />
<br />
Dump the GPU VBIOS:<br />
<br />
# echo 1 > /sys/bus/pci/devices/0000:01:00.0/rom<br />
# cat /sys/bus/pci/devices/0000:01:00.0/rom > /tmp/image.rom<br />
# echo 0 > /sys/bus/pci/devices/0000:01:00.0/rom<br />
<br />
And test it for compatibility:<br />
<br />
{{hc|$ ./rom-parser /tmp/image.rom|<br />
Valid ROM signature found @600h, PCIR offset 190h<br />
PCIR: type 0 (x86 PC-AT), vendor: 10de, device: 1184, class: 030000<br />
PCIR: revision 0, vendor revision: 1<br />
Valid ROM signature found @fa00h, PCIR offset 1ch<br />
PCIR: type 3 (EFI), vendor: 10de, device: 1184, class: 030000<br />
PCIR: revision 3, vendor revision: 0<br />
EFI: Signature Valid, Subsystem: Boot, Machine: X64<br />
Last image<br />
}}<br />
<br />
To be UEFI compatible, you need a "type 3 (EFI)" in the result. If it is not there, try updating your GPU VBIOS. GPU manufacturers often share VBIOS upgrades on their support pages. A large database of known compatible and working VBIOSes (along with their UEFI compatibility status!) is available on [https://www.techpowerup.com/vgabios/ TechPowerUp].<br />
<br />
Updated VBIOS can be used in the VM without flashing. To load it in QEMU:<br />
<br />
-device vfio-pci,host=07:00.0,......,romfile=/path/to/your/gpu/bios.bin \<br />
<br />
And in libvirt:<br />
<br />
{{bc|1=<br />
<hostdev><br />
...<br />
<rom file='/path/to/your/gpu/bios.bin'/><br />
...<br />
</hostdev><br />
}}<br />
<br />
One should compare VBIOS versions between host and guest systems using [https://www.techpowerup.com/download/nvidia-nvflash/ nvflash] (Linux versions under ''Show more versions'') or <br />
[https://www.techpowerup.com/download/techpowerup-gpu-z/ GPU-Z] (in Windows guest). To check the currently loaded VBIOS:<br />
<br />
{{hc|$ ./nvflash --version|<br />
...<br />
Version : 80.04.XX.00.97<br />
...<br />
UEFI Support : No<br />
UEFI Version : N/A<br />
UEFI Variant Id : N/A ( Unknown )<br />
UEFI Signer(s) : Unsigned<br />
...<br />
}}<br />
<br />
And to check a given VBIOS file:<br />
<br />
{{hc|$ ./nvflash --version NV299MH.rom|<br />
...<br />
Version : 80.04.XX.00.95<br />
...<br />
UEFI Support : Yes<br />
UEFI Version : 0x10022 (Jul 2 2013 @ 16377903 )<br />
UEFI Variant Id : 0x0000000000000004 ( GK1xx )<br />
UEFI Signer(s) : Microsoft Corporation UEFI CA 2011<br />
...<br />
}}<br />
<br />
If the external ROM did not work as it should in the guest, you will have to flash the newer VBIOS image to the GPU. In some cases it is possible to create your own VBIOS image with UEFI support using [https://www.win-raid.com/t892f16-AMD-and-Nvidia-GOP-update-No-requests-DIY.html GOPUpd] tool, however this is risky and may result in GPU brick.<br />
<br />
{{Warning|Failure during flashing may "brick" your GPU - recovery may be possible, but rarely easy and often requires additional hardware. '''DO NOT''' flash VBIOS images for other GPU models (different boards may use different VBIOSes, clocks, fan configuration). If it breaks, you get to keep all the pieces.}}<br />
<br />
In order to avoid the irreparable damage to your graphics adapter it is necessary to unload the NVIDIA kernel driver first:<br />
<br />
# modprobe -r nvidia_modeset nvidia <br />
<br />
Flashing the VBIOS can be done with:<br />
<br />
# ./nvflash romfile.bin<br />
<br />
{{Warning|'''DO NOT''' interrupt the flashing process, even if it looks like it is stuck. Flashing should take about a minute on most GPUs, but may take longer.}}<br />
<br />
=== Slowed down audio pumped through HDMI on the video card ===<br />
<br />
For some users VM's audio slows down/starts stuttering/becomes demonic after a while when it is pumped through HDMI on the video card. This usually also slows down graphics.<br />
A possible solution consists of enabling MSI (Message Signaled-Based Interrupts) instead of the default (Line-Based Interrupts).<br />
<br />
In order to check whether MSI is supported or enabled, run the following command as root:<br />
<br />
# lspci -vs $device | grep 'MSI:'<br />
<br />
where `$device` is the card's address (e.g. `01:00.0`).<br />
<br />
The output should be similar to:<br />
<br />
Capabilities: [60] MSI: Enable'''-''' Count=1/1 Maskable- 64bit+<br />
<br />
A {{ic|-}} after {{ic|Enable}} means MSI is supported, but not used by the VM, while a {{ic|+}} says that the VM is using it.<br />
<br />
The procedure to enable it is quite complex, instructions and an overview of the setting can be found [https://forums.guru3d.com/showthread.php?t=378044 here].<br />
<br />
On a linux guest you can use modinfo to see if there is option to enable MSI (for example: "modinfo snd_hda_intel |grep msi"). If there is, one can enable it by adding the relevant option to a custom omdprobe file - in "/etc/modprobe.d/snd-hda-intel.conf" inserting "options snd-hda-intel enable_msi=1"<br />
<br />
Other hints can be found on the [https://lime-technology.com/wiki/index.php/UnRAID_6/VM_Guest_Support#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support lime-technology's wiki], or on this article on [https://vfio.blogspot.it/2014/09/vfio-interrupts-and-how-to-coax-windows.html VFIO tips and tricks].<br />
<br />
A UI tool called [https://github.com/CHEF-KOCH/MSI-utility MSI Utility (FOSS Version 2)] works with Windows 10 64-bit and simplifies the process.<br />
<br />
In order to fix the issues enabling MSI on the 0 function of a nVidia card ({{ic|01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) (prog-if 00 [VGA controller])}}) was not enough; it will also be required to enable it on the other function ({{ic|01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)}}) to fix the issue.<br />
<br />
=== No HDMI audio output on host when intel_iommu is enabled ===<br />
<br />
If after enabling {{ic|intel_iommu}} the HDMI output device of Intel GPU becomes unusable on the host then setting the option {{ic|igfx_off}} (i.e. {{ic|1=intel_iommu=on,igfx_off}}) might bring the audio back, please read {{ic|Graphics Problems?}} in [https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt Intel-IOMMU.txt] for details about setting {{ic|igfx_off}}.<br />
<br />
=== X does not start after enabling vfio_pci ===<br />
<br />
This is related to the host GPU being detected as a secondary GPU, which causes X to fail/crash when it tries to load a driver for the guest GPU. To circumvent this, a Xorg configuration file specifying the BusID for the host GPU is required. The correct BusID can be acquired from lspci or the Xorg log. [https://www.redhat.com/archives/vfio-users/2016-August/msg00025.html Source →]<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-intel.conf|<nowiki><br />
Section "Device"<br />
Identifier "Intel GPU"<br />
Driver "modesetting"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
</nowiki>}}<br />
<br />
=== Chromium ignores integrated graphics for acceleration ===<br />
<br />
Chromium and friends will try to detect as many GPUs as they can in the system and pick which one is preferred (usually discrete NVIDIA/AMD graphics). It tries to pick a GPU by looking at PCI devices, not OpenGL renderers available in the system - the result is that Chromium may ignore the integrated GPU available for rendering and try to use the dedicated GPU bound to the {{ic|vfio-pci}} driver, and unusable on the host system, regardless of whenever a guest VM is running or not. This results in software rendering being used (leading to higher CPU load, which may also result in choppy video playback, scrolling and general un-smoothness).<br />
<br />
This can be fixed by [[Chromium/Tips and tricks#Forcing specific GPU|explicitly telling Chromium which GPU you want to use]].<br />
<br />
=== VM only uses one core ===<br />
<br />
For some users, even if IOMMU is enabled and the core count is set to more than 1, the VM still only uses one CPU core and thread. To solve this enable "Manually set CPU topology" in {{ic|virt-manager}} and set it to the desirable amount of CPU sockets, cores and threads. Keep in mind that "Threads" refers to the thread count per CPU, not the total count.<br />
<br />
=== Passthrough seems to work but no output is displayed ===<br />
<br />
Make sure if you are using virt-manager that UEFI firmware is selected for your virtual machine. Also, make sure you have passed the correct device to the VM.<br />
<br />
=== virt-manager has permission issues ===<br />
<br />
If you are getting a permission error with virt-manager add the following to your {{ic|/etc/libvirt/qemu.conf}}:<br />
<br />
group="kvm"<br />
user="''user''"<br />
<br />
If that does not work make sure your user is added to the {{ic|kvm}} and {{ic|libvirt}} [[user group]]s.<br />
<br />
=== Host lockup after VM shutdown ===<br />
<br />
This issue seems to primarily affect users running a Windows 10 guest and usually after the VM has been run for a prolonged period of time: the host will experience multiple CPU core lockups (see [https://bbs.archlinux.org/viewtopic.php?id=206050&p=2]). To fix this try enabling Message Signal Interrupts on the GPU passed through to the guest. A good guide for how to do this can be found in [https://forums.guru3d.com/threads/windows-line-based-vs-message-signaled-based-interrupts.378044/]. You can also download this application for windows here [https://github.com/TechtonicSoftware/MSIInturruptEnabler] that should make the process easier.<br />
<br />
=== Host lockup if guest is left running during sleep ===<br />
<br />
VFIO-enabled virtual machines tend to become unstable if left running through a sleep/wakeup cycle and have been known to cause the host machine to lockup when an attempt is then made to shut them down. In order to avoid this, one can simply prevent the host from going into sleep while the guest is running using the following libvirt hook script and systemd unit. The hook file needs executable permissions to work.<br />
<br />
{{hc|/etc/libvirt/hooks/qemu|<nowiki><br />
#!/bin/bash<br />
<br />
OBJECT="$1"<br />
OPERATION="$2"<br />
SUBOPERATION="$3"<br />
EXTRA_ARG="$4"<br />
<br />
case "$OPERATION" in<br />
"prepare")<br />
systemctl start libvirt-nosleep@"$OBJECT"<br />
;;<br />
"release")<br />
systemctl stop libvirt-nosleep@"$OBJECT"<br />
;;<br />
esac<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/libvirt-nosleep@.service|<nowiki><br />
[Unit]<br />
Description=Preventing sleep while libvirt domain "%i" is running<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/systemd-inhibit --what=sleep --why="Libvirt domain \"%i\" is running" --who=%U --mode=block sleep infinity<br />
</nowiki>}}<br />
<br />
=== Cannot boot after upgrading ovmf ===<br />
If you cannot boot after upgrading from ovmf-1:r23112.018432f0ce-1 then you need to remove the old *VARS.fd file in {{ic|/var/lib/libvirt/qemu/nvram}}:<br />
<br />
mv /var/lib/libvirt/qemu/nvram/vmname_VARS.fd /var/lib/libvirt/qemu/nvram/vmname_VARS.fd.old<br />
<br />
See {{Bug|57825}} for further details.<br />
<br />
=== QEMU via cli pulseaudio stuttering/delay ===<br />
Using following flags for the audio device and chipset might help if you are running into the stuttering/delay audio issues when running QEMU via cli:<br />
<br />
qemu-system-x86_64 \<br />
-machine pc-i440fx-3.0 \<br />
-device hda-micro \<br />
-soundhw hda \<br />
-...<br />
<br />
As noted in [[#QEMU 3.0 audio changes|QEMU 3.0 audio changes]] the specified chipset will include a series of audio patches.<br />
<br />
Setting {{ic|QEMU_AUDIO_TIMER_PERIOD}} to values higher than 100 might also help (did not test value lower than 100).<br />
<br />
=== Bluescreen at boot since Windows 10 1803 ===<br />
Since Windows 10 1803 there is a problem when you are using "host-passthrough" as cpu model. The machine can't boot and is either boot looping or you get a bluescreen.<br />
You can workaround this by:<br />
<br />
echo 1 > /sys/module/kvm/parameters/ignore_msrs<br />
<br />
To make it permanently you can create a modprobe file {{ic|kvm.conf}}:<br />
<br />
options kvm ignore_msrs=1<br />
=== AMD Ryzen / BIOS updates (AGESA) yields "Error: internal error: Unknown PCI header type ‘127’" ===<br />
<br />
AMD users have been experiencing breakage of their KVM setups after updating the BIOS on their motherboard. There is a kernel [https://clbin.com/VCiYJ patch], (see [[Kernel/Arch Build System]] for instruction on compiling kernels with custom patches) that can resolve the issue as of now (7/28/19), but this is not the first time AMD has made an error of this very nature, so take this into account if you are considering updating your BIOS in the future as a VFIO user.<br />
<br />
== See also ==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=162768 Discussion on Arch Linux forums] | [https://archive.is/kZYMt Archived link]<br />
* [https://docs.google.com/spreadsheet/ccc?key=0Aryg5nO-kBebdFozaW9tUWdVd2VHM0lvck95TUlpMlE User contributed hardware compatibility list]<br />
* [https://pastebin.com/rcnUZCv7 Example script] from https://www.youtube.com/watch?v=37D2bRsthfI<br />
* [https://vfio.blogspot.com/ Complete tutorial for PCI passthrough]<br />
* [https://www.redhat.com/archives/vfio-users/ VFIO users mailing list]<br />
* [ircs://chat.freenode.net/vfio-users #vfio-users on freenode]<br />
* [https://www.youtube.com/watch?v=aLeWg11ZBn0 YouTube: Level1Linux - GPU Passthrough for Virtualization with Ryzen]<br />
* [https://www.reddit.com/r/VFIO /r/VFIO: A subreddit focused on vfio]<br />
* [https://github.com/intel/gvt-linux/wiki/GVTd_Setup_Guide GVT-d: passthrough of an entire integrated GPU]</div>Calinouhttps://wiki.archlinux.org/index.php?title=Power_management&diff=564374Power management2019-01-23T10:20:29Z<p>Calinou: /* Delayed lid switch action */ Remove closing nowiki tag</p>
<hr />
<div>[[Category:Power management]]<br />
[[es:Power management]]<br />
[[it:Shutdown Pressing Power Button]]<br />
[[ja:電源管理]]<br />
[[zh-hans:Power management]]<br />
{{Related articles start}}<br />
{{Related|Power management/Suspend and hibernate}}<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's 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.|http://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|[[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.|http://linrunner.de/tlp|{{Pkg|tlp}}}}<br />
<br />
=== Graphical ===<br />
<br />
* {{App|batterymon-clone|Simple battery monitor tray icon.|https://github.com/jareksed/batterymon-clone|{{AUR|batterymon-clone}}}}<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://userbase.kde.org/Power_Devil|{{Pkg|powerdevil}} {{aur|powerdevil-light}}}}<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|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.|http://www.jezra.net/projects/vattery|{{AUR|vattery}}}}<br />
<br />
== Power management with systemd ==<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" border=1<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, [[restart]] {{ic|systemd-logind.service}} (be warned that this will terminate all login sessions that might still be open).<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 [http://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. As of December 2016, 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 />
Start xss-lock in your [[autostart]], 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 and if it is not interrupted within the delay specified by {{ic|HibernateDelaySec}} in {{man|5|systemd-sleep.conf}}, then the system will be woken using an RTC alarm and hibernated.<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://www.kernel.org/doc/html/latest/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation linux kernel documentation on power states].<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=<nowiki><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 />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/resume@.service|2=<nowiki><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 />
</nowiki>}}<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=<nowiki><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 />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki><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 />
</nowiki>}}<br />
<br />
A couple of handy hints about these service files (more in {{man|5|systemd.service}}):<br />
<br />
* If {{ic|1=<nowiki>Type=oneshot</nowiki>}} then you can use multiple {{ic|1=<nowiki>ExecStart=</nowiki>}} 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 />
==== 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=<nowiki><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 />
</nowiki>}}<br />
<br />
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: After started, the service is considered active until it is explicitly stopped.<br />
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: 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 />
==== 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 [[systemd#Journal|journal]]:<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 />
# chmod a+x /usr/lib/systemd/system-sleep/example.sh<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. [http://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. [http://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 [http://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|<nowiki><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 />
</nowiki>}}<br />
<br />
{{Style|Explicit {{ic|systemctl}} commands should not be provided.}}<br />
<br />
Restart services and reload rules:<br />
<br />
# systemctl restart systemd-udevd.service<br />
# udevadm trigger<br />
# systemctl restart systemd-logind.service<br />
<br />
Now you should see {{ic|Watching system buttons on /dev/input/event0}} in syslog.<br />
<br />
== Power saving ==<br />
<br />
{{Note|See [[Laptop#Power management]] for power management specific to laptops, such as battery monitoring.}}<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 HWP (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 performance balance_performance balance_power power}}.<br />
<br />
This can be validated by {{ic|$ cat /sys/devices/system/cpu/cpufreq/policy?/energy_performance_available_preferences}}<br />
<br />
To conserve more energy, you can config 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 />
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 />
=== Backlight ===<br />
<br />
See [[Backlight]].<br />
<br />
=== Bluetooth ===<br />
<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<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|<nowiki><br />
# disable bluetooth<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
</nowiki>}}<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 configs 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.<br />
See also [[sysctl#Virtual memory]] for other parameters affecting I/O performance and power saving.<br />
<br />
==== Laptop Mode ====<br />
<br />
See the [https://www.kernel.org/doc/Documentation/laptops/laptop-mode.txt 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 a [[Wake-on-LAN#udev|udev rule]] to disable the feature for all Ethernet interfaces.<br />
<br />
To enable powersaving with {{Pkg|iw}} on all wireless interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/70-wifi-powersave.rules|2=<br />
ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*", RUN+="/usr/bin/iw dev %k set power_save on"<br />
}}<br />
<br />
In this example, {{ic|%k}} is a specifier for the kernel name of the matched device. For example, if it finds that the rule is applicable to {{ic|wlan0}}, the {{ic|%k}} specifier will be replaced with {{ic|wlan0}}. To apply the rules to only a particular interface, just replace the pattern {{ic|wlan*}} and specifier {{ic|%k}} with the desired interface name. For more information, see [http://www.reactivated.net/writing_udev_rules.html Writing udev rules].<br />
<br />
{{Note|In this case, the name of the configuration file is important. Due to the introduction of [[Network configuration#Change interface name|persistent device names]] via {{ic|80-net-setup-link.rules}} in systemd, it is important that the network powersave rules are named lexicographically before {{ic|80-net-setup-link.rules}} so that they are applied before the devices are named e.g. {{ic|enp2s0}}.<br />
<br />
However, be advised that commands ran with {{ic|RUN}} are executed '''after''' all rules have been processed -- in which case the naming of the rules file is irrelevant and the persistent device names should be used (the persistent device name can be referenced by replacing {{ic|%k}} with {{ic|$name}}).}}<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 it persistent can be achieved by adding the line below to {{ic|/etc/modprobe.d/iwlwifi.conf}} file:<br />
<br />
options iwlwifi power_save=1 d0i3_disable=0 uapsd_disable=0<br />
options iwldvm force_cam=0<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 [http://wireless.kernel.org/en/users/Documentation/ASPM ref]:<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 the {{ic|dmesg {{!}} grep ASPM}} command can be used and if that is the case, hardware-specific Wiki article should be consulted.<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<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.<br />
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|<nowiki><br />
# whitelist for pci autosuspend<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}="auto"<br />
</nowiki>}}<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|<nowiki><br />
# blacklist for pci runtime power management<br />
SUBSYSTEM=="pci", ATTR{vendor}=="0x1234", ATTR{device}=="0x1234", ATTR{power/control}:="on"<br />
<br />
SUBSYSTEM=="pci", ATTR{power/control}="auto"<br />
</nowiki>}}<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|<nowiki><br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="auto"<br />
</nowiki>}}<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|<nowiki><br />
# whitelist for usb autosuspend<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/control}="auto"<br />
</nowiki>}}<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|<nowiki><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 />
</nowiki>}}<br />
<br />
The default autosuspend idle delay time is controlled by the {{ic|autosuspend}} parameter of the {{ic|usbcore}} [[kernel module]]. To set the delay to 5 seconds instead of the default 2 seconds:<br />
<br />
{{hc|/etc/modprobe.d/usb-autosuspend.conf|<nowiki><br />
options usbcore autosuspend=5<br />
</nowiki>}}<br />
<br />
Similarly to {{ic|power/control}}, the delay time can be fine-tuned per device by setting the {{ic|power/autosuspend}} attribute.<br />
<br />
See the [https://www.kernel.org/doc/Documentation/usb/power-management.txt 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 />
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 />
=== CD-ROM or DVD drive ===<br />
<br />
See [[Udisks#Devices do not remain unmounted (udisks)]].<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 />
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=<nowiki><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 />
</nowiki>}}<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://github.com/quequotion/pantheon-bzr-qq/blob/master/EXTRAS/indicator-powersave/throttle throttle], from {{AUR|indicator-powersave}}<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|<nowiki><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 />
</nowiki>}}<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 />
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|<nowiki><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 />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.thinkwiki.org/wiki/How_to_reduce_power_consumption ThinkWiki:How to reduce power consumption]<br />
* [http://ivanvojtko.blogspot.sk/2016/04/how-to-get-longer-battery-life-on-linux.html How to get longer battery life on Linux]</div>Calinouhttps://wiki.archlinux.org/index.php?title=PulseAudio&diff=548023PulseAudio2018-10-17T07:35:16Z<p>Calinou: Fix typos, put TODO in comment</p>
<hr />
<div>[[Category:Sound]]<br />
[[cs:PulseAudio]]<br />
[[es:PulseAudio]]<br />
[[fr:PulseAudio]]<br />
[[it:PulseAudio]]<br />
[[ja:PulseAudio]]<br />
[[pt:PulseAudio]]<br />
[[ru:PulseAudio]]<br />
[[zh-hans:PulseAudio]]<br />
{{Related articles start}}<br />
{{Related|PulseAudio/Examples}}<br />
{{Related|PulseAudio/Troubleshooting}}<br />
{{Related articles end}}<br />
[[Wikipedia:PulseAudio|PulseAudio]] is a general purpose sound server intended to run as a middleware between your applications and your hardware devices, either using [[ALSA]] or [[OSS]]. It also offers easy network streaming across local devices using [[Avahi]] if enabled. While its main purpose is to ease audio configuration, its modular design allows more advanced users to configure the daemon precisely to best suit their needs.<br />
<br />
{{Note|Some confusion may occur between [[ALSA]] and PulseAudio. ALSA includes a Linux kernel component with sound card drivers, as well as a userspace component, {{ic|libalsa}}.[http://www.alsa-project.org/main/index.php/Download] PulseAudio builds only on the kernel component, but offers compatibility with {{ic|libalsa}} through {{Pkg|pulseaudio-alsa}}.[http://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#index14h3]}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|pulseaudio}} package.<br />
<br />
{{Note|Some PulseAudio modules have been [https://www.archlinux.org/news/pulseaudio-split/ split] from the main package and must be installed separately if needed.}}<br />
<br />
* {{Pkg|pulseaudio-alsa}}, for PulseAudio to manage [[ALSA]] as well, see [[#ALSA]].<br />
* {{Pkg|pulseaudio-bluetooth}}, for [[bluetooth]] support (Bluez), see [[bluetooth headset]] page.<br />
* {{Pkg|pulseaudio-equalizer}}, for equalizer sink (qpaeq).<br />
* {{Pkg|pulseaudio-jack}}, for [[JACK]] sink, source and jackdbus detection.<br />
* {{Pkg|pulseaudio-lirc}}, for infrared (LIRC) volume control.<br />
* {{Pkg|pulseaudio-zeroconf}}, for Zeroconf ([[Avahi]]/DNS-SD) support.<br />
<br />
=== Front-ends ===<br />
<br />
There are a number of front-ends available for controlling the PulseAudio daemon:<br />
<br />
==== Console ====<br />
<br />
* {{App|ncpamixer|Ncurses mixer for PulseAudio inspired by pavucontrol.|https://github.com/fulhax/ncpamixer|{{AUR|ncpamixer}}}}<br />
* {{App|pacmixer|Alsamixer alike for PulseAudio.|https://github.com/cdemoulins/pamixer|{{AUR|pacmixer}}}}<br />
* {{App|PAmix|Ncurses PulseAudio mixer similar to pavucontrol.|https://github.com/cdemoulins/pamixer|{{AUR|pamix-git}}}}<br />
* {{App|pamixer|PulseAudio command line mixer.|https://github.com/cdemoulins/pamixer|{{Pkg|pamixer}}}}<br />
* {{App|pavolume|Simple command-line volume control for PulseAudio with libnotify messages.|https://github.com/sseemayer/pavolume|{{AUR|pavolume-git}}}}<br />
* {{App|Ponymix|Command line mixer for PulseAudio.|https://github.com/falconindy/ponymix|{{Pkg|ponymix}}}}<br />
* {{App|pulseaudio-ctl|Control PulseAudio volume from the shell or mapped to keyboard shortcuts.|https://github.com/graysky2/pulseaudio-ctl|{{AUR|pulseaudio-ctl}}}}<br />
* {{App|pulsemixer|CLI and curses mixer for PulseAudio|https://github.com/GeorgeFilipkin/pulsemixer|{{Pkg|pulsemixer}}}}<br />
<br />
==== Graphical ====<br />
<br />
* {{App|MicTray|Lightweight system tray application which lets you control the microphone state and volume using PulseAudio.|https://github.com/Junker/MicTray|{{AUR|mictray}}}}<br />
* {{App|pa-applet|System tray applet for PulseAudio with volume bar.|https://github.com/fernandotcl/pa-applet|{{AUR|pa-applet-git}}}}<br />
* {{App|pasystray|System tray applet for PulseAudio.|https://github.com/christophgysin/pasystray|{{Pkg|pasystray}}}}<br />
* {{App|plasma-pa|[[KDE]] Plasma applet for audio volume management using PulseAudio|https://cgit.kde.org/plasma-pa.git|{{Pkg|plasma-pa}}}}<br />
* {{App|PulseAudio Manager|Simple GTK+ frontend for PulseAudio.|http://0pointer.de/lennart/projects/paman/|{{AUR|paman}}}}<br />
* {{App|PulseAudio Preferences|Simple GTK+ configuration dialog for PulseAudio.|https://freedesktop.org/software/pulseaudio/paprefs/|{{Pkg|paprefs}}}}<br />
* {{App|PulseAudio Volume Control|Simple GTK+ volume control tool ("mixer") for PulseAudio.|https://freedesktop.org/software/pulseaudio/pavucontrol/|{{Pkg|pavucontrol}}}}<br />
* {{App|PulseAudio Volume Control (Qt)|Mixer for PulseAudio (Qt port of pavucontrol).|https://github.com/lxqt/pavucontrol-qt|{{Pkg|pavucontrol-qt}}}}<br />
* {{App|PulseAudio Volume Meter|Simple GTK+ volume meter for PulseAudio.|http://0pointer.de/lennart/projects/pavumeter/|{{AUR|pavumeter}}}}<br />
* {{App|PulseEffects|Audio effects for PulseAudio applications.|https://github.com/wwmm/pulseeffects|{{Pkg|pulseeffects}}}}<br />
* {{App|Volctl|Per-application system tray applet volume control for PulseAudio.|https://buzz.github.io/volctl/|{{AUR|volctl}}}}<br />
* {{App|Xfce PulseAudio Panel Plugin|PulseAudio plugin for [[Xfce]]4 panel.|https://goodies.xfce.org/projects/panel-plugins/xfce4-pulseaudio-plugin|{{Pkg|xfce4-pulseaudio-plugin}}}}<br />
<br />
== Configuration ==<br />
{{Merge|PulseAudio/Configuration|Configuration should stay in the main article, so the linked page should be merged here.|section=Abandoned draft}}<br />
<br />
By default, PulseAudio is configured to automatically detect all sound cards and manage them. It takes control of all detected ALSA devices and redirects all audio streams to itself, making the PulseAudio daemon the central configuration point. The daemon should work mostly out of the box, only requiring a few minor tweaks. <br />
<br />
While PulseAudio usually runs fine out of the box and requires only minimal configuration, advanced users can change almost every aspect of the daemon by either altering the default configuration file to disable modules or writing your own from scratch.<br />
<br />
PulseAudio runs as a server daemon that can run either system-wide or on per-user basis using a client/server architecture. The daemon by itself does nothing without its '''modules''' except to provide an API and host dynamically loaded modules. The audio routing and processing tasks are all handled by various modules, including PulseAudio's native protocol itself (provided by [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index22h3 module-native-protocol-unix]). Clients reach the server through one of many protocol modules that will accept audio from external sources, route it through PulseAudio and eventually have it go out through a final other module. The output module does not have to be an actual sound output: it can dump the stream into a file, stream it to a broadcasting server such as [[Icecast]], or even just discard it.<br />
<br />
You can find a detailed list of all available modules at [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/ Pulseaudio Loadable Modules]. To enable them you can just add a line {{ic|load-module <module-name-from-list>}} to {{ic|~/.config/pulse/default.pa}}.<br />
<br />
=== Configuration files ===<br />
<br />
PulseAudio will first look for configuration files in the home directory {{ic|~/.config/pulse}}, then system-wide {{ic|/etc/pulse}}.<br />
<br />
{{Tip|<br />
* It is strongly suggested not to edit system-wide configuration files, but rather edit user ones. Create the {{ic|~/.config/pulse}} directory, then copy the system configuration files into it and edit according to your need.<br />
* Make sure you keep user configuration in sync with changes to the packaged files in {{ic|/etc/pulse/}}. Otherwise, PulseAudio may refuse to start due to configuration errors.<br />
* There is usually no need to add your user to the {{ic|audio}} group, as PulseAudio uses [[udev]] and ''logind'' to give access dynamically to the currently "active" user. Exceptions would include running the machine headless so that there is no currently "active" user.}}<br />
<br />
==== daemon.conf ====<br />
<br />
This is the main configuration file to configure the daemon itself. It defines base settings like the default sample rates used by modules, resampling methods, realtime scheduling and various other settings related to the server process. These can not be changed at runtime without restarting the PulseAudio daemon. The defaults are sensible for most users, see the {{man|5|pulse-daemon.conf}} manpage for additional information. Boolean options accepts any of these: {{ic|true}}, {{ic|yes}}, {{ic|on}} and {{ic|1}} as well as {{ic|false}}, {{ic|no}}, {{ic|off}} and {{ic|0}}.<br />
<br />
{{Note|PulseAudio does not perform tilde expansion on paths in this file. Use absolute paths for any files.}}<br />
<br />
{| class="wikitable"<br />
|+ Notable configuration options<br />
! Option || Description<br />
|+<br />
| daemonize || Controls whether the server will daemonize itself and return. Set to {{ic|no}} when debugging so you can see the debugging information on the terminal.<br />
|+<br />
| resample-method || Which resampler to use when audio with incompatible sample rates needs to be passed between modules (e.g. playback of 96kHz audio on hardware which only supports 48kHz). The available resamplers can be listed with {{ic|$ pulseaudio --dump-resample-methods}}. Choose the best tradeoff between CPU usage and audio quality for the present use-case. {{Tip|In some cases PulseAudio will generate a high CPU load. This can happen when multiple streams are resampled (individually). If this is a common use-case in a workflow, it should be considered to create an additional sink at a matching sample rate which can then be fed into the main sink, resampling only once.}}<br />
|+<br />
| avoid-resampling || With {{ic|1=avoid-resampling = yes}}, PulseAudio automatically configures the hardware to the sample rate which the application uses, if the hardware supports this sample rate (needs [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ PA 11] or higher)<br />
{{Warning|Enabling this feature might cause audio distortion, therefore it is disabled by default, see the [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ release notes] for more information.}}<br />
|+<br />
| enable-remixing || When the input and output have a different channel count (for example, outputting a 6 channel movie into a stereo sink), pulse can either remix all the channels (default, {{ic|yes}}) or just trivially map the channels by their name (left goes to left, right to right, all others ignored) when {{ic|no}}<br />
|+<br />
| system-instance || If set to {{ic|yes}}, run the daemon as a [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/SystemWide/ system-wide] instance. [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/ Highly discouraged] as it can introduce security issues. Useful on [[Xorg multiseat|Multiseat]] systems, or headless systems that have no real local users. Defaults to {{ic|no}}.<br />
|+<br />
| flat-volumes ||{{ic|flat-volumes}} scales the device-volume with the volume of the "loudest" application. For example, raising the VoIP call volume will raise the hardware volume and adjust the music-player volume so it stays where it was, without having to lower the volume of the music-player manually. Defaults to {{ic|yes}} upstream, but to {{ic|no}} within Arch. {{Note|The default behavior upstream can sometimes be confusing and some applications, unaware of this feature, can set their volume to 100% at startup, potentially blowing your speakers or your ears. This is why Arch defaults to the classic (ALSA) behavior by setting this to {{ic|no}}.}}<br />
|+<br />
| realtime-scheduling || If your [[kernel]] supports realtime scheduling (for instance, [[Realtime kernel]] or [[Linux-ck]]), set this to {{ic|yes}} to ensure PulseAudio can deliver low-latency glitch-free playback. You can adjust {{ic|realtime-priority}} as well to have it use the correct priority, especially when [[JACK]] is also running on the system.<br />
|+<br />
| nice-level || Since PulseAudio runs in userspace and involves inter-process communication, audio can be subject to dropouts if the daemon does not have enough CPU time to process the audio. The default usually is enough, but can be tweaked to give pulse the wanted priority over (or below) other applications.<br />
|+<br />
| exit-idle-time || If you want to run PulseAudio only when needed and use ALSA otherwise, you can set a delay in seconds after which the daemon will automatically shutdown after all clients are disconnected. Set it to -1 to disable this feature.<br />
|+<br />
| log-level || When debugging, you may want to increase the logging level of the daemon to see exactly why a specific module fails to load. High logging levels will sometimes print useful information such as detected minimum latency for the system, which can then be used to tweak {{ic|default-fragments}} and {{ic|default-fragment-size-msec}}.<br />
|+<br />
| default-sample-format || This usually does not need to be changed, but if your sound card's native format is different, performance and quality can be improved by setting the right format here.<br />
|+<br />
| default-sample-rate || The default sample rate user by pulse unless overriden at module level. Change this if your sound card does not support 44100Hz or if you wish to upsample all audio. See previous note about CPU usage.<br />
|+<br />
| alternate-sample-rate || To fix a common limitation where movies at 48000Hz were needlessly downsampled to 44100Hz, some modules support changing their sample rate dynamically to avoid resampling when possible. See manual for more in-depth information. This usually does not need to be changed.<br />
|+<br />
| default-channels || The default number of channels when not specified. Usually do not need any change as you can configure more channels on per-module basis.<br />
|+<br />
| default-fragments || Audio samples are split into multiple fragments of {{ic|default-fragment-size-msec}} each. The larger the buffer is, the less likely audio will skip when the system is overloaded. On the downside this will increase the overall latency. Increase this value if you have issues.<br />
|+<br />
| default-fragment-size-msec || The size in milliseconds of each fragment. This is the amount of data that will be processed at once by the daemon. <!-- TODO: Verify --><br />
|}<br />
<br />
==== default.pa ====<br />
<br />
This file is a startup script and is used to configure modules. It is actually parsed and read after the daemon has finished initializing and additional commands can be sent at runtime using {{ic|$ pactl}} or {{ic|$ pacmd}}. The startup script can also be provided on the command line by starting PulseAudio in a terminal using {{ic|$ pulseaudio -nC}}. This will make the daemon load the CLI module and will accept the configuration directly from the command line, and output resulting information or error messages on the same terminal. This can be useful when debugging the daemon or just to test various modules before setting them permanently on disk. The manual page is quite self-explanatory, consult {{man|5|pulse-cli-syntax}} for the details of the syntax.<br />
<br />
{{tip|<br />
* Rather than being a complete copy, {{ic|~/.config/pulse/default.pa}} can start with the line {{ic|.include /etc/pulse/default.pa}} and then just override the defaults.<br />
* Run {{ic|<nowiki>$ pacmd list-sinks|egrep -i 'index:|name:'</nowiki>}} to list available sinks. The present default sink is marked with an asterisk.<br />
* Edit {{ic|~/.config/pulse/default.pa}} to insert/alter the set-default-sink command using the sink's name as the numbering cannot be guaranteed repeatable.<br />
}}<br />
<br />
==== client.conf ====<br />
This is the configuration file read by every PulseAudio client application. It is used to configure runtime options for individual clients. It can be used to set and configure the default sink and source statically as well as allowing (or disallowing) clients to automatically start the server if not currently running.<br />
<br />
=== Configuration command ===<br />
<br />
The main command to configure a server during runtime is {{ic|$ pacmd}}. Run {{ic|$ pacmd --help}} for a list options, or just run {{ic|$ pacmd}} to enter the shell interactive mode and {{ic|Ctrl+d}} to exit. All modifications will immediately be applied.<br />
<br />
Once your new settings have been tested and meet your needs, edit the {{ic|default.pa}} accordingly to make the change persistent. See [[PulseAudio/Examples]] for some basic settings.<br />
<br />
{{Tip|leave the {{ic|load-module module-default-device-restore}} line in the {{ic|default.pa}} file untouched. It will allow you to restart the server in its default state, thus dismissing any wrong setting.}}<br />
<br />
It is important to understand that the "sources" (processes, capture devices) and "sinks" (sound cards, servers, other processes) accessible and selectable through PulseAudio depend upon the current hardware "Profile" selected. These "Profiles" are those ALSA "pcms" listed by the command {{ic|aplay -L}}, and more specifically by the command {{ic|pacmd list-cards}}, which will include a line "index:", a list beginning "profiles:", and a line "active profile: <...>" in the output, among other things. "Profiles" correspond to different card input/output configurations, notably the number of available input/output channels.<br />
<br />
The "active profile" can be set with the command {{ic|pacmd set-card-profile INDEX PROFILE}}, with ''no'' comma separating INDEX and PROFILE, where INDEX is just the number on the line "index:" and a PROFILE name is everything shown from the beginning of any line under "profile:" to just ''before'' the colon and first space, as shown by the command {{ic|pacmd list-cards}}. For instance, {{ic|pacmd set-card-profile 0 output:analog-stereo+input:analog-stereo}}.<br />
<br />
It may be easier to select a "Profile" with a graphical tool like {{ic|pavucontrol}}, under the "Configuration" tab, or KDE System Settings, "Multimedia/Audio and Video Settings", under the "Audio Hardware Setup" tab. Each audio "Card", which are those devices listed by the command {{ic|aplay -l}}, or again by the command {{ic|pacmd list-cards}}, will have its own selectable "Profile". When a "Profile" has been selected, the then available "sources" and "sinks" can be seen by using the commands {{ic|pacmd list-sources}} and {{ic|pacmd list-sinks}}. Note that the "index" of the available sources and sinks will change each time a card profile is changed.<br />
<br />
The selected "Profile" can be an issue for some applications, especially the Adobe Flash players, typically {{ic|/usr/lib/mozilla/plugins/libflashplayer.so}} and {{ic|/usr/lib/PepperFlash/libpepflashplayer.so}}. Often, these Flash players will only work when one of the Stereo profiles is selected, and otherwise, will play video with no sound, or will simply "crash". When all else fails, you might try selecting a different profile.<br />
<br />
Of course, when configuring some variation of Surround Sound in PulseAudio, the appropriate Surround profile will have to be selected, before Surround Sound will work, or in order to do things like remap the speaker channels.<br />
<br />
== Running ==<br />
<br />
PulseAudio on Arch has {{ic|pulseaudio.socket}} enabled by default for the [[systemd/User]] instance. This means that PulseAudio will automatically start when needed.<br />
<br />
{{Note|<br />
* To disable {{ic|pulseaudio.socket}}, make sure that {{ic|$XDG_CONFIG_HOME/systemd/user/}} exists and run {{ic|systemctl --user mask pulseaudio.socket}}.<br />
* Many [[desktop environments]] support [[XDG Autostart]]. In those desktop environments, PulseAudio will be launched automatically regardless of the socket activation status.<br />
}}<br />
<br />
For more information, see [http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Running/ PulseAudio: Running].<br />
<br />
== Back-end configuration ==<br />
<br />
=== ALSA ===<br />
<br />
If you have applications that do not support PulseAudio explicitly but rely on ALSA, these applications will try to access the sound card directly via ALSA and will therefore bypass PulseAudio. PulseAudio will thus not have access to the sound card any more. As a result, all applications relying on PulseAudio will not be working any more, leading to [[PulseAudio/Troubleshooting#The only device shown is "dummy output" or newly connected cards are not detected|this issue]]. To prevent this, you will need to install the {{Pkg|pulseaudio-alsa}} package. It contains the necessary {{ic|/etc/asound.conf}} for configuring ALSA to use PulseAudio. Also make sure that {{ic|~/.asoundrc}} does not exist, as it would override the {{ic|/etc/asound.conf}} file.<br />
<br />
Also install {{Pkg|lib32-libpulse}} and {{Pkg|lib32-alsa-plugins}} if you run a x86_64 system and want to have sound for 32-bit [[multilib]] programs like [[Wine]] and [[Steam]].<br />
<br />
To prevent applications from using ALSA's OSS emulation and bypassing PulseAudio (thereby preventing other applications from playing sound), make sure the module {{ic|snd_pcm_oss}} is not being loaded at boot. If it is currently loaded ({{ic|<nowiki>lsmod | grep oss</nowiki>}}), disable it by executing:<br />
# rmmod snd_pcm_oss<br />
<br />
==== Enable DTS via ALSA ====<br />
<br />
To enable PulseAudio DTS via ALSA install {{aur|dcaenc}} package and enable it:<br />
<br />
{{hc|/etc/asound.conf|2=<br />
<confdir:pcm/dca.conf><br />
}}<br />
<br />
Finally restart PulseAudio. If experience volume issues with your DTS device and/or PulseAudio, you may fix it by looking for more setting option at [https://github.com/darealshinji/dcaenc dcaenc's Github].<br />
<br />
==== Expose PulseAudio sources, sinks and mixers to ALSA ====<br />
Although {{Pkg|pulseaudio-alsa}} contains the necessary configuration file to allow ALSA applications to use PulseAudio's default device, ALSA's {{ic|pulse}} plugin is more versatile than that:<br />
<br />
{{hc|~/.asoundrc (or /etc/asound.conf)|2=<br />
# Create an alsa input/output using specific PulseAudio sources/sinks<br />
pcm.pulse-example1 {<br />
type pulse<br />
device "my-combined-sink" # name of a source or sink<br />
fallback "pulse-example2" # if combined not available<br />
}<br />
<br />
pcm.pulse-example2 {<br />
type pulse<br />
device "other-sound-card" # name of a source or sink<br />
# example: device "alsa_output.pci-0000_00_1b.0.analog-stereo"<br />
}<br />
<br />
# Create an alsa mixer using specific PulseAudio sources/sinks<br />
# these can be tested with "alsamixer -D pulse-example3"<br />
ctl.pulse-example3 {<br />
type pulse<br />
device "my-output" # name of source or sink to control<br />
<br />
# example: always control the laptop speakers:<br />
# device "alsa_output.pci-0000_00_1b.0.analog-stereo"<br />
fallback "pulse-example4" # supports fallback too<br />
}<br />
<br />
# Mixers also can control a specific source and sink, separately:<br />
ctl.pulse-example4 {<br />
type pulse<br />
sink "my-usb-headphones"<br />
source "my-internal-mic"<br />
<br />
# example: output to HDMI, record using internal<br />
sink "alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1"<br />
source "alsa_input.pci-0000_00_1b.0.analog-stereo"<br />
}<br />
<br />
# These can override the default mixer (example: for pnmixer integration)<br />
ctl.!default {<br />
type pulse<br />
sink "alsa_output.pci-0000_01_00.1.hdmi-stereo-extra1"<br />
source "alsa_input.pci-0000_00_1b.0.analog-stereo"<br />
}<br />
}}<br />
<br />
The [http://git.alsa-project.org/?p=alsa-plugins.git;a=tree;f=pulse;hb=HEAD source code] can be read to know all available options.<br />
<br />
==== ALSA/dmix without grabbing hardware device ====<br />
<br />
{{Note|This section describes alternative configuration, which is generally '''not''' recommended.}}<br />
<br />
You may want to use ALSA directly in most of your applications while still being able to use applications which require PulseAudio at the same time. The following steps allow you to make PulseAudio use dmix instead of grabbing ALSA hardware device.<br />
<br />
* Remove package {{Pkg|pulseaudio-alsa}}, which provides compatibility layer between ALSA applications and PulseAudio. After this your ALSA apps will use ALSA directly without being hooked by Pulse.<br />
<br />
* Edit {{ic|/etc/pulse/default.pa}}.<br />
<br />
:Find and uncomment lines which load back-end drivers. Add '''device''' parameters as follows. Then find and comment lines which load autodetect modules.<br />
<br />
load-module module-alsa-sink '''device=dmix'''<br />
load-module module-alsa-source '''device=dsnoop'''<br />
# load-module module-udev-detect<br />
# load-module module-detect<br />
<br />
* ''Optional:'' If you use {{Pkg|kmix}} you may want to control ALSA volume instead of PulseAudio volume:<br />
<br />
$ echo export KMIX_PULSEAUDIO_DISABLE=1 > ~/.kde4/env/kmix_disable_pulse.sh<br />
$ chmod +x ~/.kde4/env/kmix_disable_pulse.sh<br />
<br />
* Now, reboot your computer and try running ALSA and PulseAudio applications at the same time. They both should produce sound simultaneously.<br />
:Use {{Pkg|pavucontrol}} to control PulseAudio volume if needed.<br />
<br />
=== OSS ===<br />
<br />
There are multiple ways of making OSS-only programs output to PulseAudio:<br />
<br />
==== ossp ====<br />
<br />
Install {{Pkg|ossp}} package and start {{ic|osspd.service}}.<br />
<br />
==== padsp wrapper ====<br />
<br />
Programs using OSS can work with PulseAudio by starting it with padsp (included with PulseAudio):<br />
<br />
$ padsp OSSprogram<br />
<br />
A few examples:<br />
<br />
$ padsp aumix<br />
$ padsp sox foo.wav -t ossdsp /dev/dsp<br />
<br />
You can also add a custom wrapper script like this: <br />
<br />
{{hc|/usr/local/bin/OSSProgram|<nowiki><br />
#!/bin/sh<br />
exec padsp /usr/bin/OSSprogram "$@"<br />
</nowiki>}}<br />
<br />
Make sure {{ic|/usr/local/bin}} comes before {{ic|/usr/bin}} in your '''PATH'''.<br />
<br />
=== GStreamer ===<br />
<br />
Install {{Pkg|gst-plugins-good}}, or {{AUR|gstreamer0.10-good-plugins}} if your intended program has a legacy [[GStreamer]] implementation.<br />
<br />
=== OpenAL ===<br />
<br />
OpenAL Soft should use PulseAudio by default, but can be explicitly configured to do so: {{hc|/etc/openal/alsoft.conf|2=drivers=pulse,alsa}}<br />
<br />
By default, OpenAL does not allow pulseaudio to move audio streams to a different device. To change this, add the allow-moves option:<br />
<br />
{{hc|/etc/openal/alsoft.conf|2=<br />
[pulse]<br />
allow-moves=true<br />
}}<br />
<br />
=== libao ===<br />
<br />
Edit the libao configuration file:<br />
{{hc|/etc/libao.conf|2=default_driver=pulse}}<br />
Be sure to remove the {{ic|1=dev=default}} option of the alsa driver or adjust it to specify a specific Pulse sink name or number. <br />
<br />
{{Note|You could possibly also keep the libao standard of outputting to the ''alsa'' driver and its default device if you install {{pkg|pulseaudio-alsa}} since the ALSA default device then '''is''' PulseAudio.}}<br />
<br />
== Equalizer ==<br />
<br />
{{Warning|The equalizer module is considered unstable and might be removed from PulseAudio. For more, see the [https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-March/020174.html mailing list].}}<br />
<br />
{{Tip|You might want to use {{pkg|pulseeffects}} instead.}}<br />
<br />
PulseAudio has an integrated 10-band equalizer system. In order to use the equalizer do the following:<br />
<br />
Install {{Pkg|pulseaudio-equalizer}}:<br />
<br />
=== Load equalizer sink and dbus-protocol module ===<br />
<br />
$ pactl load-module module-equalizer-sink<br />
$ pactl load-module module-dbus-protocol<br />
<br />
=== GUI front-end ===<br />
<br />
run:<br />
<br />
$ qpaeq<br />
<br />
{{Note|If qpaeq has no effect, install {{pkg|pavucontrol}} and change "ALSA Playback on" to "FFT based equalizer on ..." while the media player is running.}}<br />
<br />
=== Load equalizer and dbus module on every boot ===<br />
<br />
Edit the {{ic|/etc/pulse/default.pa}} or {{ic|~/.config/pulse/default.pa}} file with your favorite editor and append the following lines:<br />
<br />
### Load the integrated PulseAudio equalizer and D-Bus module<br />
load-module module-equalizer-sink<br />
load-module module-dbus-protocol<br />
<br />
{{Note|The equalizer sink needs to be loaded after the master sink is already available.}}<br />
<br />
=== Alternative equalizers ===<br />
<br />
{{Pkg|pulseaudio-equalizer-ladspa}} (based on {{Pkg|swh-plugins}}) can be used as an alternative to {{Pkg|pulseaudio-equalizer}}.<br />
<br />
{{Pkg|pulseeffects}} applies peak limiting, compression, reverberation, auto volume and 15 bands equalization to Pulseaudio applications output.<br />
<br />
== Applications ==<br />
<br />
=== QEMU ===<br />
<br />
Refer to [[QEMU#Host]] for a detailed guide on how to configure pulseaudio within [[QEMU]].<br />
<br />
=== AlsaMixer.app ===<br />
<br />
Make {{AUR|alsamixer.app}} dockapp for the {{AUR|windowmaker}} use pulseaudio, e.g.<br />
$ AlsaMixer.app --device pulse<br />
<br />
Here is a two examples where the first one is for ALSA and the other one is for pulseaudio. You can run multiple instances of it. Use the {{ic|-w}} option to choose which of the control buttons to bind to the mouse wheel.<br />
<br />
# AlsaMixer.app -3 Mic -1 Master -2 PCM --card 0 -w 1<br />
# AlsaMixer.app --device pulse -1 Capture -2 Master -w 2<br />
<br />
{{Note|It can use only those output sinks that set as default.}}<br />
<br />
=== XMMS2 ===<br />
<br />
Make it switch to pulseaudio output<br />
<br />
$ nyxmms2 server config output.plugin pulse<br />
<br />
and to alsa<br />
<br />
$ nyxmms2 server config output.plugin alsa<br />
<br />
To make xmms2 use a different output sink, e.g.<br />
<br />
$ nyxmms2 server config pulse.sink alsa_output.pci-0000_04_01.0.analog-stereo.monitor<br />
<br />
See also the official guide [https://xmms2.org/wiki/Using_the_application].<br />
<br />
=== KDE Plasma Workspaces and Qt4 ===<br />
<br />
PulseAudio will automatically be used by KDE/Qt4 applications. It is supported by default in the KDE sound mixer. For more information see the [https://www.freedesktop.org/wiki/Software/PulseAudio/Desktops/KDE/ KDE page in the PulseAudio wiki].<br />
<br />
One useful tidbit from that page is that {{ic|load-module module-device-manager}} should be loaded. This usually happens automatically at login through the script {{ic|/usr/bin/start-pulseaudio-x11}}; if you find that the module is not loaded automatically you can consider adding it manually to {{ic|/etc/pulse/default.pa}}. See [[#Switch on connect]] for possible conflicts with the {{ic|module-switch-on-connect}}.<br />
<br />
If the phonon-gstreamer backend is used for Phonon, GStreamer should also be configured as described in [[#GStreamer]].<br />
<br />
=== Audacious ===<br />
<br />
[[Audacious]] natively supports PulseAudio. In order to use it, set Audacious Preferences -> Audio -> Current output plugin to 'PulseAudio Output Plugin'.<br />
<br />
=== Music Player Daemon (MPD) ===<br />
<br />
[http://mpd.wikia.com/wiki/PulseAudio configure] [[MPD]] to use PulseAudio. See also [[MPD/Tips and Tricks#PulseAudio]].<br />
<br />
=== MPlayer ===<br />
<br />
[[MPlayer]] natively supports PulseAudio output with the {{ic|-ao pulse}} option. It can also be configured to default to PulseAudio output, in {{ic|~/.mplayer/config}} for per-user, or {{ic|/etc/mplayer/mplayer.conf}} for system-wide:<br />
<br />
{{hc|/etc/mplayer/mplayer.conf|2=<br />
ao=pulse<br />
}}<br />
<br />
=== guvcview ===<br />
<br />
{{Pkg|guvcview}} when using the PulseAudio input from a [[Webcam]] may have the audio input suspended resulting in no audio being recorded. You can check this by executing:<br />
<br />
$ pactl list sources<br />
<br />
If the audio source is "suspended" then modifying the following line in {{ic|/etc/pulse/default.pa}} and changing:<br />
<br />
load-module module-suspend-on-idle<br />
<br />
to<br />
<br />
#load-module module-suspend-on-idle<br />
<br />
And then either restarting PulseAudio or your computer will only idle the input source instead of suspending it. guvcview will then correctly record audio from the device.<br />
<br />
== Networked audio ==<br />
<br />
{{Expansion|please allow for some time for me to port the most important information here -- [[User:Nodiscc|Nodiscc]]|Talk:PulseAudio#Networked_audio}}<br />
Play sound through the outputs of another computer on the network<br />
<br />
=== Basic setup with direct connection ===<br />
<br />
==== On the server ====<br />
<br />
Edit {{ic|~/.config/pulse/default.pa}} or {{ic|/etc/pulse/default.pa}} (or {{ic|/etc/pulse/system.pa}} if PulseAudio is started in system mode) and add the following line:<br />
<br />
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;172.16.0.0/16<br />
<br />
Here only client from the IPs or IPs range specified here can stream sound.<br />
<br />
To allow access from everywhere:<br />
<br />
load-module module-native-protocol-tcp auth-anonymous=true<br />
<br />
{{Note| If {{ic|auth-ip-acl}} neither {{ic|auth-anonymous}} are specified, authentification is done via {{ic|~/.pulse-cookie}} which must be the same on clients and server.}}<br />
<br />
By default PulseAudio listens on port {{ic|tcp/4713}} for incoming connections, you may need to open this port in your [[firewall]].<br />
<br />
==== On the client ====<br />
<br />
Edit {{ic|~/.config/pulse/client.conf}} or {{ic|/etc/pulse/client.conf}}, to respectively apply this directive to one user or to all, and add :<br />
<br />
default-server = ''server-address''<br />
<br />
''server-address'' can be a simple domain-name or IPv4, for more see [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/ServerStrings/ the documentation]<br />
<br />
It is also possible to set the server address in the environment variable {{ic|$PULSE_SERVER}}.<br />
<br />
== Tips and tricks ==<br />
<br />
{{Merge|PulseAudio/Examples|Same topic.}}<br />
<br />
=== Keyboard volume control ===<br />
<br />
See [[Keyboard shortcuts#Xorg]] to bind the following commands to your volume keys: {{ic|XF86AudioRaiseVolume}}, {{ic|XF86AudioLowerVolume}} and {{ic|XF86AudioMute}}.<br />
<br />
First find out which sink corresponds to the audio output you would like to control.<br />
To list available sinks:<br />
<br />
$ pactl list sinks short<br />
<br />
Suppose sink 0 is to be used, to raise the volume:<br />
sh -c "pactl set-sink-mute 0 false ; pactl set-sink-volume 0 +5%"<br />
<br />
To lower the volume:<br />
<br />
$ sh -c "pactl set-sink-mute 0 false ; pactl set-sink-volume 0 -5%"<br />
<br />
To mute/unmute the volume:<br />
<br />
$ pactl set-sink-mute 0 toggle<br />
<br />
To mute/unmute the microphone:<br />
<br />
$ pactl set-source-mute 1 toggle<br />
<br />
{{Tip|To have keyboard shortcuts operate always on the default sink, specify {{ic|@DEFAULT_SINK@}} as the sink number, for example {{ic|pactl set-sink-mute @DEFAULT_SINK@ toggle}}.}}<br />
<br />
=== Play sound from a non-interactive shell (systemd service, cron) ===<br />
<br />
Set {{ic|XDG_RUNTIME_DIR}} before the command (replace {{ic|''user_id''}} with the ID of the user running PulseAudio):<br />
<br />
$ XDG_RUNTIME_DIR=/run/user/''user_id'' paplay /usr/share/sounds/freedesktop/stereo/complete.oga<br />
<br />
Or use {{ic|machinectl}}:<br />
<br />
# machinectl shell .host --uid=''user_id'' /usr/bin/paplay /usr/share/sounds/freedesktop/stereo/complete.oga<br />
<br />
=== X11 Bell Events ===<br />
<br />
To get pulseaudio to handle X11 bell events, run the following commands after the X11 session has been started:<br />
<br />
$ pactl upload-sample /usr/share/sounds/freedesktop/stereo/bell.oga x11-bell<br />
$ pactl load-module module-x11-bell sample=x11-bell display=$DISPLAY<br />
<br />
To adjust the volume of the X11 bell, run the following command:<br />
<br />
$ xset b 100<br />
<br />
100 is a percentage. This requires the {{Pkg|xorg-xset}} package. See [[Autostarting]] for a way to run these commands automatically when the X11 session is started.<br />
<br />
=== Switch on connect ===<br />
<br />
This is a module used to switch the output sound to the newly connected device. For example, if you plug in a USB headset, the output will be switched to that. If you unplug it, the output will be set back to the last device. This used to be quite buggy but got a lot of attention in PulseAudio 8.0 and should work quite well now.<br />
<br />
If you just want to test the module then you can load it at runtime by calling:<br />
<br />
$ pactl load-module module-switch-on-connect<br />
<br />
If you want to make the change persistent you will have to add it to your local pulseaudio settings or to /etc/pulse/default.pa (system wide effect). In either case, add this line:<br />
<br />
load-module module-switch-on-connect<br />
<br />
{{Accuracy|Editing {{ic|/usr/bin/start-pulseaudio-x11}} will not survive package upgrade. The offending module can be unloaded in the config before loading {{ic|module-switch-on-connect}}, see [[Talk:Bluetooth_headset#GDMs_pulseaudio_instance_captures_bluetooth_headset]].}}<br />
<br />
On KDE/Plasma5 you should furthermore disable module-device-manager. As soon as Plasma5 is started it loads (via start-pulseaudio-x11) the module module-device-manager for pulseaudio to manage the devices. But that module apparently conflicts with module-switch-on-connect. Therefore you should disable that module by editing /bin/start-pulseaudio-x11 and commenting the lines for KDE. Simply logout and login again and in order to renew your pulseaudio session. On connect switching should now work properly.<br />
<br />
=== Script for switching analog outputs ===<br />
<br />
Some sound cards present the option of multiple analog outputs, being switchable through using Pulseaudio profiles. But switching manually can become a chore, so you can use the following commands to switch it:<br />
<br />
$ pactl set-sink-port 'number of the card' 'port'<br />
<br />
This will set the default output to whatever port you chose.<br />
Example:<br />
<br />
$ pactl set-sink-port 0 "analog-output;output-speaker" <br />
<br />
The values can be easily obtained using:<br />
<br />
$ pactl list<br />
<br />
Current output can be obtained through:<br />
<br />
$ pactl list sinks | grep "active profile"| cut -d ' ' -f 3-<br />
<br />
This process can be automated through a simple script. This script then can be given a shortcut by the user:<br />
<br />
{{hc|~/pa.sh (or anything the user wants)|<nowiki><br />
#!/bin/bash<br />
# This script uses kdialog notification to warn the user of the currently swapped to profile. User could adapt it to their needs or change it.<br />
<br />
CURRENT_PROFILE=$(pactl list sinks | grep "active profile"| cut -d ' ' -f 3-)<br />
<br />
if [ "$CURRENT_PROFILE" = "analog-output;output-speaker" ] ; then<br />
pactl set-sink-port 0 "analog-output;output-headphones-1"<br />
kdialog --title "Pulseaudio" --passivepopup "Headphone" 2 & <br />
else <br />
pactl set-sink-port 0 "analog-output;output-speaker" <br />
kdialog --title "Pulseaudio" --passivepopup "Speaker" 2 &<br />
fi<br />
</nowiki>}}<br />
<br />
This script is intended to swap between two profiles. First checking the current profile then swapping it. Users are required to change the field 'active profile' according to the language pactl reports. Users might need to change the number of the card and the output to fit their machine.<br />
<br />
== Troubleshooting ==<br />
<br />
See [[PulseAudio/Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* [https://www.freedesktop.org/wiki/Software/PulseAudio/ PulseAudio official website], including documentation<br />
* [https://gavv.github.io/blog/pulseaudio-under-the-hood/ Pulseaudio under the hood]</div>Calinouhttps://wiki.archlinux.org/index.php?title=Gamepad&diff=541878Gamepad2018-09-17T20:49:56Z<p>Calinou: /* Connect Xbox Wireless Controller with bluetooth */ Improve grammar</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Gaming]]<br />
[[ja:ゲームパッド]]<br />
[[ru:Gamepad]]<br />
Joysticks can be a bit of a hassle to get working in Linux. Not because they are poorly supported, but simply because you need to determine which modules to load to get your joystick working, and it's not always very obvious!<br />
<br />
== Joystick input systems ==<br />
<br />
Linux has two different input systems for Joysticks – the original Joystick interface and the newer evdev-based interface.<br />
<br />
{{ic|1=/dev/input/jsX}} maps to the Joystick API interface and {{ic|/dev/input/event*}} maps to the evdev ones (this also includes other input devices such as mice and keyboards). Symbolic links to those devices are also available in {{ic|/dev/input/by-id/}} and {{ic|/dev/input/by-path/}} where the legacy Joystick API has names ending with {{ic|-joystick}} while the evdev have names ending with {{ic|-event-joystick}}.<br />
<br />
Most new games will default to the evdev interface as it gives more detailed information about the buttons and axes available and also adds support for force feedback.<br />
<br />
While SDL1 defaults to evdev interface you can force it to use the old Joystick API by setting the environment variable {{ic|1=SDL_JOYSTICK_DEVICE=/dev/input/js0}}. This can help many games such as X3. SDL2 supports only the new evdev interface.<br />
<br />
== Determining which modules you need ==<br />
<br />
Unless you're using very old joystick that uses gameport or proprietary USB protocol, you will need just the generic USB human interface device (HID) modules.<br />
<br />
For an extensive overview of all joystick related modules in Linux, you will need access to the Linux kernel sources -- specifically the Documentation section. Unfortunately, pacman kernel packages do not include what we need. If you have the kernel sources downloaded, have a look at {{ic|Documentation/input/joydev/}}. You can browse the kernel source tree at [https://kernel.org/ kernel.org] by clicking the "browse" (cgit - the git frontend) link for the kernel that you're using, then clicking the "tree" link near the top. Here's a link to the [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/input/joydev/joystick.rst documentation from the latest kernel].<br />
<br />
Some joysticks need specific modules, such as the Microsoft Sidewinder controllers ({{ic|sidewinder}}), or the Logitech digital controllers ({{ic|adi}}). Many older joysticks will work with the simple {{ic|analog}} module. If your joystick is plugging in to a gameport provided by your soundcard, you will need your soundcard drivers loaded - however, some cards, like the Soundblaster Live, have a specific gameport driver ({{ic|emu10k1-gp}}). Older ISA soundcards may need the {{ic|ns558}} module, which is a standard gameport module.<br />
<br />
As you can see, there are many different modules related to getting your joystick working in Linux, so I couldn't possibly cover everything here. Please have a look at the documentation mentioned above for details.<br />
<br />
=== Loading the modules for analogue devices ===<br />
<br />
You need to load a module for your gameport ({{ic|ns558}}, {{ic|emu10k1-gp}}, {{ic|cs461x}}, etc...), a module for your joystick ({{ic|analog}}, {{ic|sidewinder}}, {{ic|adi}}, etc...), and finally the kernel joystick device driver ({{ic|joydev}}). Add these to a new file in {{ic|/etc/modules-load.d/}}, or simply modprobe them. The {{ic|gameport}} module should load automatically, as this is a dependency of the other modules.<br />
<br />
=== USB joysticks ===<br />
<br />
You need to get USB working, and then modprobe your joystick driver, which is {{ic|usbhid}}, as well as {{ic|joydev}}. <br />
If you use a usb mouse or keyboard, {{ic|usbhid}} will be loaded already and you just have to load the {{ic|joydev}} module.<br />
<br />
== Testing your configuration ==<br />
<br />
Once the modules are loaded, you should be able to find a new device: {{ic|/dev/input/js0}} and a file ending with {{ic|-event-joystick}} in {{ic|/dev/input/by-id}} directory. You can simply {{ic|cat}} those devices to see if the joystick works - move the stick around, press all the buttons - you should see mojibake printed when you move the sticks or press buttons. <br />
<br />
Both interfaces are also supported in wine and reported as separate devices. You can test them with {{ic|1=wine control joy.cpl}}.<br />
<br />
{{Tip| Input devices by default have '''input''' group, for example {{pkg|pcsx2}} have no access to gamepad without rights. Make sure your user in '''input''' group.}}<br />
<br />
<br />
=== Joystick API ===<br />
There are a lot of applications that can test this old API, {{ic|jstest}} from the {{pkg|joyutils}} package is the simplest one. If the output is unreadable because the line printed is too long you can also use graphical tools. Plasma has a built in one in Input Devices panel in System Settings or {{AUR|jstest-gtk-git}} is an alternative.<br />
<br />
Use of {{ic|jstest}} is fairly simple, you just run {{ic|jstest /dev/input/js0}} and it will print a line with state of all the axes (normalised to {-32767,32767}) and buttons.<br />
<br />
After you start {{ic|jstest-gtk}}, it will just show you a list of joysticks available, you just need to select one and press Properties.<br />
<br />
=== evdev API ===<br />
<br />
The new 'evdev' API can be tested using the SDL2 joystick test application or using {{ic|evtest}} from community repository. Install {{AUR|sdl2-jstest-git}} and then run {{ic|sdl2-jstest --test 0}}. Use {{ic|sdl2-jstest --list}} to get IDs of other controllers if you have multiple ones connected.<br />
<br />
To test force feedback on the device, use {{ic|fftest}} from {{ic|linuxconsole}} package:<br />
$ fftest /dev/input/by-id/usb-*event-joystick<br />
<br />
==Setting up deadzones and calibration==<br />
If you want to set up the deadzones (or remove them completely) of your analog input you have to do it separately for the xorg (for mouse and keyboard emulation), Joystick API and evdev API.<br />
<br />
===Wine deadzones===<br />
Add the following registry entry and set it to a string from 0 to 10000 (affects all axes):<br />
HKEY_CURRENT_USER\Software\Wine\DirectInput\DefaultDeadZone<br />
Source: [http://wiki.winehq.org/UsefulRegistryKeys UsefulRegistryKeys]<br />
<br />
===Xorg deadzones===<br />
Add a similar line to {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it doesn't exist):<br />
{{hc|1=/etc/X11/xorg.conf.d/51-joystick.conf|2=<nowiki><br />
Section "InputClass"<br />
Option "MapAxis1" "deadzone=1000"<br />
EndSection<br />
</nowiki>}}<br />
1000 is the default value, but you can set anything between 0 and 30 000. To get the axis number see the "Testing Your Configuration" section of this article.<br />
If you already have an option with a specific axis just type in the {{ic|1=deadzone=value}} at the end of the parameter separated by a space.<br />
<br />
===Joystick API deadzones===<br />
The easiest way is using {{ic|jstest-gtk}} from {{AUR|jstest-gtk-git}}. Select the controller you want to edit, then click the Calibration button at the bottom of the dialog ('''don't''' click Start Calibration there). You can then set the CenterMin and CenterMax values (which control the center deadzone), RangeMin and RangeMax which control the end of throw deadzones. Note that the calibration settings are applied when the application opens the device, so you need to restart your game or test application to see updated calibration settings.<br />
<br />
After you set the deadzones use {{ic|jscal}} to dump the new values into a shell script:<br />
$ jscal -p /dev/input/jsX > jscal.sh # replace X with your joystick's number <br />
$ chmod +x jscal.sh<br />
<br />
Now you need to make a [[udev]] rule (for example {{ic|/etc/udev/rules.d and name it 85-jscal.rules}}) so the script will automatically run when you connect the controller:<br />
SUBSYSTEM=="input", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="c268", ACTION=="add", RUN+="/usr/bin/jscal.sh"<br />
To get the idVendor and idProduct use {{ic|udevadm info --attribute-walk --name /dev/input/jsX}}<br />
<br />
Use the `/dev/input/by-id/*-joystick` device names in case you use multiple controllers.<br />
<br />
===evdev API deadzones===<br />
The {{ic|evdev-joystick}} tool from the {{pkg|linuxconsole}} package can be used to view and change deadzones and calibration for {{ic|evdev}} API devices.<br />
<br />
To view your device configuration:<br />
$ evdev-joystick --showcal /dev/input/by-id/usb-*-event-joystick<br />
<br />
To change the deadzone for a particular axis, use a command like:<br />
$ evdev-joystick --evdev /dev/input/by-id/usb-*-event-joystick --axis 0 --deadzone 0<br />
<br />
To set the same deadzone for all axes at once, omit the "--axis 0" option.<br />
<br />
Use udev rules file to set them automatically when the controller is connected.<br />
<br />
Note that inside the kernel, the value is called {{ic|flatness}} and is set using the {{ic|EVIOCSABS}} {{ic|ioctl}}.<br />
<br />
Default configuration will look like similar to this:<br />
{{hc|$ evdev-joystick --showcal /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick|2= Supported Absolute axes:<br />
Absolute axis 0x00 (0) (X Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x01 (1) (Y Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x05 (5) (Z Rate Axis) (min: 0, max: 4095, flatness: 255 (=6.23%), fuzz: 15)<br />
Absolute axis 0x10 (16) (Hat zero, x axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)<br />
Absolute axis 0x11 (17) (Hat zero, y axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)}}<br />
<br />
While a more reasonable setting would be achieved with something like this (repeat for other axes):<br />
{{hc|$ evdev-joystick --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick --axis 0 --deadzone 512|2= Event device file: /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick<br />
Axis index to deal with: 0<br />
New dead zone value: 512<br />
Trying to set axis 0 deadzone to: 512<br />
Absolute axis 0x00 (0) (X Axis) Setting deadzone value to : 512<br />
(min: 0, max: 65535, flatness: 512 (=0.78%), fuzz: 255)}}<br />
<br />
===Configuring curves and responsivness===<br />
In case your game requires just limited amount of buttons or has good support for multiple controllers, you may have good results with using {{ic|xboxdrv}} to change response curves of the joystick.<br />
<br />
Below are the setups I use for Saitek X-55 HOTAS:<br />
$ xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Throttle_G0000021-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_#40=x1,ABS_#41=y1,ABS_X=x2,ABS_Y=y2' --device-name 'Hat and throttle' \<br />
--ui-axismap 'x2^cal:-32000:0:32000=,y2^cal:-32000:0:32000=' --silent<br />
<br />
this maps the EV_ABS event with id of 40 and 41 (use xboxdrv with --evdev-debug to see the events registered), which is the normally inaccessible "mouse pointer" on the throttle, to first gamepad joystick and throttles to second joystick, it also clamps the top and lower ranges as they not always register fully.<br />
<br />
A bit more interesting is the setup for the stick:<br />
$ xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_X=x1' --evdev-absmap 'ABS_Y=y1' --device-name 'Joystick' \<br />
--ui-axismap 'x1^cal:-32537:-455:32561=,x1^dead:-900:700:1=,x1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--ui-axismap 'y1^cal:-32539:-177:32532=,y1^dead:-700:2500:1=,y1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--evdev-absmap 'ABS_RZ=x2' --ui-axismap 'x2^cal:-32000:-100:32000,x2^dead:-1500:1000:1=,x2^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--silent<br />
<br />
this maps the 3 joystick axes to gamepad axes and changes the calibration (min value, centre value, max value), dead zones (negative side, positive side, flag to turn smoothing) and finally change of response curve to a more flat one in the middle.<br />
<br />
You can also modify the responsiveness by setting the 'sen' (sensitivity). Setting it to value of 0 will give you a linear sensitivity, value of -1 will give very insensitive axis while value of 1 will give very sensitive axis. You can use intermediate values to make it less or more sensitive. Internally xboxdrv uses a quadratic formula to calculate the resulting value, so this setting gives a more smooth result than 'resp' shown above.<br />
<br />
Nice thing about xboxdrv is that it exports resulting device as both old Joystick API and new style evdev API so it should be compatible with basically any application.<br />
<br />
== Disable joystick from controlling mouse ==<br />
If you want to play games with your controller, you might want to disable joystick control over mouse cursor. To do this, edit {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it doesn't exists) so that it looks like this:<br />
{{hc|/etc/X11/xorg.conf.d/51-joystick.conf |<br />
Section "InputClass"<br />
Identifier "joystick catchall"<br />
MatchIsJoystick "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "joystick"<br />
Option "StartKeysEnabled" "False" #Disable mouse<br />
Option "StartMouseEnabled" "False" #support<br />
EndSection}}<br />
<br />
== Using Joystick to send keystrokes ==<br />
<br />
A couple joystick to keystroke programs exist like {{AUR|qjoypad}} or {{AUR|antimicro}}, all work well without the need for X.org configuration.<br />
<br />
=== Xorg configuration example ===<br />
<br />
This is a good solution for systems where restarting Xorg is a rare event because it is a static configuration loaded only on X startup. The example runs on a [[Kodi]] media PC, controlled with a Logitech Cordless RumblePad 2. Due to a problem with the d-pad (a.k.a. "hat") being recognized as another axis, [[Joy2key]] was used as a workaround. Since upgrade to Kodi version 11.0 and joy2key 1.6.3-1, this setup no longer worked and the following was created for letting Xorg handle joystick events.<br />
<br />
First, [[install]] the {{AUR|xf86-input-joystick}} package. Then, create {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} like so:<br />
{{bc|<nowiki><br />
Section "InputClass"<br />
Identifier "Joystick hat mapping"<br />
Option "StartKeysEnabled" "True"<br />
#MatchIsJoystick "on"<br />
Option "MapAxis5" "keylow=113 keyhigh=114"<br />
Option "MapAxis6" "keylow=111 keyhigh=116"<br />
EndSection<br />
</nowiki>}}<br />
{{Note|The {{ic|MatchIsJoystick "on"}} line does not seem to be required for the setup to work, but you may want to uncomment it.}}<br />
<br />
== Specific devices ==<br />
<br />
While most joysticks, especially USB based ones should just work, some may require (or give better results) if you use alternative drivers. If it doesn't work the first time, do not give up, and read those docs thoroughly!<br />
<br />
=== Dance pads ===<br />
Most dance pads should work. However some pads, especially those used from a video game console via an adapter, have a tendency to map the directional buttons as axis buttons. This prevents hitting left-right or up-down simultaneously. This behavior can be fixed for devices recognized by xpad via a module option:<br />
<br />
# modprobe -r xpad<br />
# modprobe xpad dpad_to_buttons=1<br />
<br />
=== Logitech Thunderpad Digital ===<br />
<br />
Logitech Thunderpad Digital won't show all the buttons if you use the {{ic|analog}} module. Use the device specific {{ic|adi}} module for this controller.<br />
<br />
=== Nintendo Gamecube Controller ===<br />
<br />
Dolphin Emulator has a [https://wiki.dolphin-emu.org/index.php?title=How_to_use_the_Official_GameCube_Controller_Adapter_for_Wii_U_in_Dolphin page on their wiki] that explains how to use the official Nintendo USB adapter with a Gamecube controller. This configuration also works with the Mayflash Controller Adapter if the switch is set to "Wii U".<br />
<br />
By default, the controller will register with [[udev]], but will only be readable by the root user. You can fix this by adding a udev device rule, like the below. <br />
<br />
{{hc<br />
|head=/etc/udev/rules.d/51-gcadapter.rules<br />
|output=<nowiki>SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="0337", MODE="0666"</nowiki><br />
}}<br />
<br />
This only matches the USB device with the specified vendor and product IDs, which match those of the official USB adapter. It sets the permissions of the device file to 0666 so that programs that aren't running as root can read the device's input. <br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
=== Nintendo Switch Wired Pro Controller ===<br />
<br />
While the controller works for native Linux games, this controller isn't detected by Steam. To fix this, we'll need to add a line to 70-steam-controller.rules.<br />
<br />
{{hc<br />
|head=/lib/udev/rules.d/70-steam-controller.rules<br />
|output=<nowiki># NS PRO Controller USB<br />
KERNEL=="hidraw*", ATTRS{idVendor}=="20d6", ATTRS{idProduct}=="a711", MODE="0660", TAG+="uaccess"</nowiki><br />
}}<br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
=== PlayStation 3/4 controller ===<br />
<br />
The DualShock 3, DualShock 4 and Sixaxis controllers work out of the box when plugged in via USB (the PS button will need to be pushed to begin). They can also be used wirelessly via Bluetooth.<br />
<br />
Steam properly recognizes it as a PS3 pad and Big Picture can be launched with the PS button. Big Picture and some games may act as if it was a 360 controller. Gamepad control over mouse is on by default. You may want to turn it off before playing games, see [[#Joystick moving mouse]].<br />
<br />
=====Connecting via Bluetooth=====<br />
<br />
Install the {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}} packages, which includes the ''sixaxis'' plugin. Then [[start]] {{ic|bluetooth.service}}, plug the controller in via USB, and the plugin should program your PC's bluetooth address into the controller automatically.<br />
<br />
You can now disconnect your controller. The next time you hit the PlayStation button it will connect without asking anything else.<br />
<br />
Alternatively, you can press the share button and the PlayStation button simultaneously to put the gamepad in pairing mode, and pair as you would normally.<br />
<br />
Remember to disconnect the controller when you are done as the controller will stay on when connected and drain the battery.<br />
<br />
{{Note|If the controller does not connect, make sure the bluetooth interface is turned on and the controllers have been trusted. (See [[Bluetooth]])}}<br />
<br />
=====Using generic/clone controllers=====<br />
<br />
Using generic/clone Dualshock controllers is possible, however there are some issues that may require to install patched packages. The default Bluetooth protocol stack doesn't detect some of the clone controllers, the {{AUR|bluez-ps3}} package is a version patched to be able to detect them. Another issue is a bug where the controller starts to non-stop rumble as soon as it gets connected via USB. That can be fixed by using a patched version of the hid-sony driver, which is available on the {{AUR|dkms-hid-sony-shanwan}} package.<br />
<br />
=== iPEGA-9017s and other Bluetooth gamepads ===<br />
<br />
If you want to use one of the widely available bluetooth gamepads, such as iPEGA-9017s designed mostly for Android and iOS devices you would need {{AUR|xboxdrv}}, {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}}. You should connect it in gamepad mode (if there are different modes, choose the gamepad one). Technically it's ready to be used, but in most cases games would not recognize it, and you would have to map it individually for all application. The best way to simplify it and make it work with all applications is to mimic Microsoft X360 controller with {{AUR|xboxdrv}}.<br />
Once connected you can create a udev rule to give it a persistent name, that would come in handy when setting it up.<br />
<br />
{{hc<br />
|/etc/udev/rules.d/99-btjoy.rules|2=<br />
#Create a symlink to appropriate /dev/input/eventX at /dev/btjoy<br />
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="Bluetooth Gamepad", ATTRS{uniq}=="00:17:02:01:ae:2a", SYMLINK+="btjoy"<br />
}}<br />
<br />
Replace "Bluetooth Gampad" with your device name and "00:17:02:01:ae:2a" with your device's address.<br />
<br />
Next, create a configuration for {{AUR|xboxdrv}} somewhere, for example:<br />
<br />
{{hc<br />
|~/.config/xboxdrv/ipega.conf|2=<br />
#iPEGA PG-9017S Config <br />
<br />
[xboxdrv]<br />
evdev-debug = true<br />
evdev-grab = true<br />
rumble = false<br />
mimic-xpad = true<br />
<br />
[evdev-absmap]<br />
ABS_HAT0X = dpad_x<br />
ABS_HAT0Y = dpad_y<br />
<br />
ABS_X = X1<br />
ABS_Y = Y1<br />
<br />
ABS_Z = X2<br />
ABS_RZ = Y2<br />
<br />
[axismap]<br />
-Y1 = Y1<br />
-Y2 = Y2<br />
<br />
[evdev-keymap]<br />
BTN_EAST=a<br />
BTN_C=b<br />
BTN_NORTH=y<br />
BTN_SOUTH=x<br />
BTN_TR2=start<br />
BTN_TL2=back<br />
BTN_Z=rt<br />
BTN_WEST=lt<br />
<br />
BTN_MODE = guide<br />
}}<br />
<br />
Refer to the xboxdrv man to see all the options.<br />
<br />
Now when you have the config and your device is connected you can start the {{AUR|xboxdrv}} like so:<br />
<br />
{{ic | sudo xboxdrv --evdev /dev/btjoy --config .config/xboxdrv/ipega.conf}}<br />
<br />
Your games will now work with bluetooth gamepad as long as xboxdrv is running.<br />
<br />
=== Steam Controller ===<br />
<br />
{{Note|Kernel 4.18 [https://lkml.org/lkml/2018/4/16/380 provides a kernel driver] for wired/wireless use of the steam controller as a controller input device without [[Steam]].}}<br />
<br />
The [[Steam]] client will recognize the controller and provide keyboard/mouse/gamepad emulation while Steam is running. The in-game Steam overlay needs to be enabled and working in order for gamepad emulation to work. You may need to run {{ic|udevadm trigger}} with root privileges or plug the dongle out and in again, if the controller doesn't work immediately after installing and running Steam. If all else fails, try restarting the computer while the dongle is plugged in.<br />
<br />
If you can't get the Steam Controller to work, see [[#Steam Controller not pairing]].<br />
<br />
Alternatively you can install {{AUR|python-steamcontroller-git}} to have controller and mouse emulation without Steam or {{AUR|sc-controller}} for a versatile graphical configuration tool simillar to what is provided by the Steam client.<br />
<br />
On some desktop environments the on-screen keyboard might freeze when trying to input text after one or two characters. This is a problem with window focus. Check the settings for your [[window manager]] to see if it is possible to have focus follow the mouse or automatically focus new windows. Preventing the keyboard from receiving focus will fix the issue in [[Awesome]], see [[Awesome#Steam Keyboard]].<br />
<br />
{{Note|If you do not use the [[Steam runtime]], you might actually need to disable the overlay for the controller to work in certain games (Rocket Wars, Rocket League, Binding of Isaac, etc.). Right click on a game in your library, select "Properties", and uncheck "Enable Steam Overlay".}}<br />
<br />
==== Wine ====<br />
<br />
{{AUR|python-steamcontroller-git}} can also be used to make the Steam Controller work for games running under Wine. You need to find and download the application {{ic|xbox360cemu.v.3.0}} (e.g. from [https://github.com/jacobmischka/ds4-in-wine/tree/master/xbox360cemu.v.3.0 here]). Then copy the files {{ic|dinput8.dll}}, {{ic|xbox360cemu.ini}}, {{ic|xinput1_3.dll}} and {{ic|xinput_9_1_0.dll}} to the directory that contains your game executable. Edit {{ic|xbox360cemu.ini}} and only change the following values under {{ic|[PAD1]}} to remap the Steam Controller correctly to a XBox controller.<br />
<br />
{{hc|xbox360cemu.ini|2= Right Analog X=4<br />
Right Analog Y=-5<br />
A=1<br />
B=2<br />
X=3<br />
Y=4<br />
Back=7<br />
Start=8<br />
Left Thumb=10<br />
Right Thumb=11<br />
Left Trigger=a3<br />
Right Trigger=a6}}<br />
<br />
Now start python-steamcontroller in Xbox360 mode ({{ic|sc-xbox.py start}}). You might also want to copy {{ic|XInputTest.exe}} from {{ic|xbox360cemu.v.3.0}} to the same directory and run it with Wine in order to test if the mappings work correctly. However neither mouse nor keyboard emulation work with this method.<br />
<br />
Alternatively you can use {{AUR|sc-controller}} for a similar graphical setup as Steam's own configurator. As of writing, it's a bit buggy here and there but offers an easy click and go way of configuring the controller.<br />
<br />
=== Xbox 360 controller ===<br />
<br />
Both the wired and wireless (with the ''Xbox 360 Wireless Receiver for Windows'') controllers are supported by the {{ic|xpad}} kernel module and should work without additional packages.<br />
<br />
It has been reported that the default xpad driver has some issues with a few newer wired and wireless controllers, such as:<br />
* incorrect button mapping. ([https://github.com/ValveSoftware/steam-for-linux/issues/95#issuecomment-14009081 discussion in Steam bugtracker])<br />
* not-working sync. All four leds keep blinking, but controller works. ([https://bbs.archlinux.org/viewtopic.php?id=156028 discussion in Arch Forum])<br />
<br />
If you experience such issues, you can use either [[#SteamOS xpad]] or [[#xboxdrv]] instead of the default {{ic|xpad}} driver.<br />
<br />
If you wish to use the controller for controlling the mouse, or mapping buttons to keys, etc. you should use the {{AUR|xf86-input-joystick}} package (configuration help can be found using {{ic|man joystick}}). If the mouse locks itself in a corner, it might help changing the {{ic|MatchDevicePath}} in {{ic|/etc/X11/xorg.conf.d/50-joystick.conf}} from {{ic|/dev/input/event*}} to {{ic|/dev/input/js*}}.<br />
<br />
{{Tip|If you use the [[TLP]] power management tool, you may experience connection issues with your Microsoft wireless adapter (e.g. the indicator LED will go out after the adapter has been connected for a few seconds, and controller connection attempts fail). This is due to TLP's USB autosuspend functionality, and the solution is to add the Microsoft wireless adapter's device ID to this feature's blacklist (USB_BLACKLIST, check [http://linrunner.de/en/tlp/docs/tlp-configuration.html#usb TLP configuration] for more details).}}<br />
<br />
==== SteamOS xpad ====<br />
<br />
If you have issues with the default {{ic|xpad}} kernel module, you can install the SteamOS version. There is still a known issue with compatibility between wireless Xbox360 controllers and games made in GameMaker Studio. If you encounter this problem, the only known workaround is to use xboxdrv. YoYo Games has refused to acknowledge this as a bug with their product and it is unlikely to ever be fixed.<br />
<br />
First make sure you have [[DKMS]] installed and running, then install the modified kernel module {{AUR|steamos-xpad-dkms}}. During the installation you'll see that new xpad kernel module is strapped to your current kernel:<br />
<br />
Creating symlink /var/lib/dkms/steamos-xpad-dkms/0.1/source -&gt;<br />
/usr/src/steamos-xpad-dkms-0.1<br />
<br />
DKMS: add completed.<br />
<br />
Kernel preparation unnecessary for this kernel. Skipping...<br />
<br />
Building module:<br />
cleaning build area....<br />
make KERNELRELEASE=3.12.8-1-ARCH KVERSION=3.12.8-1-ARCH....<br />
cleaning build area....<br />
<br />
Then unload the old xpad module and load new one:<br />
<br />
# rmmod xpad<br />
# modprobe steamos-xpad<br />
<br />
Or just restart your computer.<br />
<br />
==== xboxdrv ====<br />
<br />
xboxdrv is an alternative to {{ic|xpad}} which provides more functionality and might work better with certain controllers. It works in userspace and can be launched as system service. <br />
<br />
Install it with the {{AUR|xboxdrv}} package. Then [[start]]/[[enable]] {{ic|xboxdrv.service}}.<br />
<br />
If you have issues with the controller being recognized but not working in steam games or working but with incorrect mappings, it may be required to modify you config as such:<br />
{{hc<br />
|/etc/default/xboxdrv|2=<br />
[xboxdrv]<br />
silent = true<br />
device-name = "Xbox 360 Wireless Receiver"<br />
mimic-xpad = true<br />
deadzone = 4000<br />
<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Multiple controllers =====<br />
<br />
xboxdrv supports a multitude of controllers, but they need to be set up in {{ic|/etc/default/xboxdrv}}. For each extra controller, add an {{ic|1=next-controller = true}} line. For example, when using 4 controllers, add it 3 times:<br />
<br />
{{bc|<nowiki><br />
[xboxdrv]<br />
silent = true<br />
next-controller = true<br />
next-controller = true<br />
next-controller = true<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
</nowiki>}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Mimic Xbox 360 controller with other controllers =====<br />
<br />
xboxdrv can be used to make any controller register as an Xbox 360 controller with the {{ic|--mimic-xpad}} switch. This may be desirable for games that support Xbox 360 controllers out of the box, but have trouble detecting or working with other gamepads.<br />
<br />
First, you need to find out what each button and axis on the controller is called. You can use {{Pkg|evtest}} for this. Run {{ic|evtest}} and select the device event ID number ({{ic|/dev/input/event*}}) that corresponds to your controller. Press the buttons on the controller and move the axes to read the names of each button and axis.<br />
<br />
Here is an example of the output:<br />
{{bc|<nowiki><br />
<br />
Event: time 1380985017.964843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985017.964843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 1<br />
Event: time 1380985017.964843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.076843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985018.076843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 0<br />
Event: time 1380985018.076843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.460841, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.460841, type 1 (EV_KEY), code 289 (BTN_THUMB), value 1<br />
Event: time 1380985018.460841, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.572835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.572835, type 1 (EV_KEY), code 289 (BTN_THUMB), value 0<br />
Event: time 1380985018.572835, -------------- SYN_REPORT ------------<br />
Event: time 1380985019.980824, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985019.980824, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 1<br />
Event: time 1380985019.980824, -------------- SYN_REPORT ------------<br />
Event: time 1380985020.092835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985020.092835, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 0<br />
Event: time 1380985020.092835, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.596806, type 3 (EV_ABS), code 3 (ABS_RX), value 18<br />
Event: time 1380985023.596806, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.612811, type 3 (EV_ABS), code 3 (ABS_RX), value 0<br />
Event: time 1380985023.612811, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.708768, type 3 (EV_ABS), code 3 (ABS_RX), value 14<br />
Event: time 1380985023.708768, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.724772, type 3 (EV_ABS), code 3 (ABS_RX), value 128<br />
Event: time 1380985023.724772, -------------- SYN_REPORT ------------<br />
</nowiki>}}<br />
<br />
In this case, {{ic|BTN_THUMB}}, {{ic|BTN_THUMB2}} and {{ic|BTN_PINKIE}} are buttons and {{ic|ABS_RX}} is the X axis of the right analogue stick.<br />
You can now mimic an Xbox 360 controller with the following command:<br />
<br />
$ xboxdrv --evdev /dev/input/event* --evdev-absmap ABS_RX=X2 --evdev-keymap BTN_THUMB2=a,BTN_THUMB=b,BTN_PINKIE=rt --mimic-xpad<br />
<br />
The above example is incomplete. It only maps one axis and 3 buttons for demonstration purposes. Use {{ic|xboxdrv --help-button}} to see the names of the Xbox controller buttons and axes and bind them accordingly by expanding the command above. Axes mappings should go after {{ic|--evdev-absmap}} and button mappings follow {{ic|--evdev-keymap}} (comma separated list; no spaces).<br />
<br />
By default, xboxdrv outputs all events to the terminal. You can use this to test that the mappings are correct. Append the {{ic|--silent}} option to keep it quiet.<br />
<br />
=== Xbox Wireless Controller / Xbox One Wireless Controller ===<br />
<br />
==== Connect Xbox Wireless Controller with usb cable ====<br />
<br />
This is supported by the kernel and should work without additional packages.<br />
<br />
==== Connect Xbox Wireless Controller with Bluetooth ====<br />
<br />
You will probably have to disable Enhanced Retransmission Mode (ERTM) to make it work.<br />
<br />
Use either:<br />
<br />
# echo 1 > /sys/module/bluetooth/parameters/disable_ertm<br />
<br />
Or add this file to your module configuration:<br />
<br />
{{hc<br />
|/etc/modprobe.d/xbox_bt.conf|2=<br />
options bluetooth disable_ertm=1<br />
}}<br />
<br />
===== xpadneo =====<br />
<br />
A relatively new driver which does (yet) support only the Xbox One S controller via Bluetooth is called [https://github.com/atar-axis/xpadneo/ xpadneo].<br />
In exchange for supporting just one controller so far, it enables one to read out the correct battery level, supports rumble (even the one on the trigger buttons - L2/R2), corrects the (sometimes wrong) button mapping and more.<br />
<br />
Installation is done using DKMS: {{AUR|xpadneo-dkms-git}}<br />
<br />
==== Connect Xbox Wireless Controller with Microsoft Xbox Wireless Adapter ====<br />
<br />
It does not work on Linux.<br />
<br />
===Logitech Dual Action===<br />
<br />
The Logitech Dual Action gamepad has a very similar mapping to the PS2 pad, but some buttons and triggers need to be swapped to mimic the Xbox controller.<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TRIGGER=x,BTN_TOP=y,BTN_THUMB=a,BTN_THUMB2=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lt,BTN_BASE2=rt,BTN_TOP2=lb,BTN_PINKIE=rb,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
===PlayStation 2 controller via USB adapter===<br />
<br />
To fix the button mapping of PS2 dual adapters and mimic the Xbox controller you can run the following command:<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TOP=x,BTN_TRIGGER=y,BTN_THUMB2=a,BTN_THUMB=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lb,BTN_BASE2=rb,BTN_TOP2=lt,BTN_PINKIE=rt,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
===PlayStation 3 controller via USB===<br />
<br />
If you own a PS3 controller and can connect with USB, xboxdrv has the mappings built in. Just run the program (and detach the running driver) and it works! <br />
<br />
# xboxdrv --silent --detach-kernel-driver<br />
<br />
There are some games which might also need the {{ic|--mimic-xpad}} option, additionally.<br />
<br />
===PlayStation 3 controller via Bluetooth===<br />
<br />
With your controller connected via Bluetooth, find the device address with {{ic|bluetoothctl}}. Then create a new udev rule with the following content:<br />
<br />
{{hc|1=/etc/udev/rules.d/99-dualshock.rules|2=<br />
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{uniq}=="<device_addr_you_got_on_pairing>", SYMLINK+="input/dualshock3"<br />
}}<br />
<br />
The address must be in lowercase, like {{ic|06:9a:b4:c8:ef:8b}}.<br />
<br />
Now run xboxdrv over the new device:<br />
<br />
$ xboxdrv --evdev /dev/input/dualshock3 --mimic-xpad<br />
<br />
===PlayStation 4 controller===<br />
<br />
==Button mapping==<br />
<br />
To fix the button mapping of PS4 controller you can use the following command with xboxdrv (or try with the [https://github.com/chrippa/ds4drv ds4drv] program):<br />
<br />
# xboxdrv \<br />
--evdev /dev/input/by-id/usb-Sony_Computer_Entertainment_Wireless_Controller-event-joystick\<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1 \<br />
--evdev-absmap ABS_Z=x2,ABS_RZ=y2 \<br />
--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--evdev-keymap BTN_A=x,BTN_B=a \<br />
--evdev-keymap BTN_C=b,BTN_X=y \<br />
--evdev-keymap BTN_Y=lb,BTN_Z=rb \<br />
--evdev-keymap BTN_TL=lt,BTN_TR=rt \<br />
--evdev-keymap BTN_SELECT=tl,BTN_START=tr \<br />
--evdev-keymap BTN_TL2=back,BTN_TR2=start \<br />
--evdev-keymap BTN_MODE=guide \<br />
--axismap -y1=y1,-y2=y2 \<br />
--mimic-xpad \<br />
--silent<br />
<br />
<br />
<br />
==Fix Motion control conflict (gamepad won't work on somes apps)==<br />
<br />
Dualshock 4 V1 and V2 are both like 3 devices, touchpad, motion control, and joypad.<br />
<br />
With somes softwares like Parsec and Shadow cloud gaming streaming apps, motion control is in conflict with joypad, you can disable touchpad and motion control with :<br />
<br />
<code>sudo nano /etc/udev/rules.d/51-disable-DS3-and-DS4-motion-controls.rules</code><br />
<br />
Then copy/paste and register :<br />
<br />
<code><br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Motion Sensors", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Touchpad", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
</code><br />
<br />
This should work in USB and Bluetooth mode. (If you want use bluetooth mode, press "home" button and "share" button together, white led of gamepad should blink very quickly, then add wireless controller with your bluetooth manager (bluez, gnome-bluetooth...)<br />
<br />
== Troubleshooting ==<br />
<br />
=== Joystick moving mouse ===<br />
<br />
Sometimes USB joystick can be recognized as HID mouse (only in X, it is still being installed as {{ic|/dev/input/js0}} as well). Known issue is cursor being moved by the joystick, or escaping to en edge of a screen right after plugin. If your application can detect joystick by it self, you can remove the {{AUR|xf86-input-joystick}} package.<br />
<br />
A more gentle solution is described in [[#Disable joystick from controlling mouse]].<br />
<br />
=== Joystick not working in FNA/SDL based games ===<br />
If you are using a generic non-widely used gamepad you may encounter issues getting the gamepad recognized in games based on SDL. Since [https://github.com/flibitijibibo/FNA/commit/e55742cfe7e38b778a21ed8a12cb2f2081490d8d 14 May 2015], FNA supports dropping a {{ic|gamecontrollerdb.txt }} into the executable folder of the game, for example the [https://github.com/gabomdq/SDL_GameControllerDB SDL_GameControllerDB].<br />
<br />
As an alternative and for older versions of FNA or for SDL you can generate a mapping yourself by downloading the SDL source code via http://libsdl.org/, navigating to {{ic|/test/}}, compile the {{ic|controllermap.c}} program (alternatively install {{AUR|controllermap}}) and run the test. After completing the controllermap test, a guid will be generated that you can put in the {{ic|SDL_GAMECONTROLLERCONFIG}} environment variable which will then be picked up by SDL/FNA games. For example:<br />
<br />
$ export SDL_GAMECONTROLLERCONFIG="030000008f0e00000300000010010000,GreenAsia Inc. USB Joystick ,platform:Linux,x:b3,a:b2,b:b1,y:b0,back:b8,start:b9,dpleft:h0.8,dpdown:h0.0,dpdown:h0.4,dpright:h0.0,dpright:h0.2,dpup:h0.0,dpup:h0.1,leftshoulder:h0.0,leftshoulder:b6,lefttrigger:b4,rightshoulder:b7,righttrigger:b5,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a3,righty:a2,"<br />
<br />
=== Joystick not recognized by all programs ===<br />
<br />
Some software, Steam for example, will only recognize the first joystick it encounters. Due to a bug in the driver for Microsoft wireless periphery devices this can in fact be the bluetooth dongle. If you find you have a {{ic|/dev/input/js*}} and {{ic|/dev/input/event*}} belonging to you keyboard's bluetooth transceiver you can get automatically get rid of it by creating according udev rules.<br />
Create a {{ic|/}}:<br />
{{hc|/etc/udev/rules.d/99-btcleanup.rules|<nowiki><br />
ACTION=="add", KERNEL=="js[0-9]*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/js%n"<br />
ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/event%n"<br />
</nowiki>}}<br />
Correct the {{ic|<nowiki>KERNELS=="..."</nowiki>}} to match your device. The correct value can be found by running<br />
<br />
# udevadm info -an /dev/input/js0<br />
<br />
Assuming the device in question is {{ic|/dev/input/js0}}. After you placed the rule reload the rules with<br />
<br />
# udevadm control --reload<br />
<br />
Then replug the device making you trouble. The joystick and event devices should be gone, although their number will still be reserved. But the files are out of the way.<br />
<br />
=== Steam Controller not pairing ===<br />
<br />
There are some unknown cases where the packaged udev rule for the Steam controller does not work ({{bug|47330}}). The most reliable workaround is to make the controller world readable. Copy the rule {{ic|/usr/lib/udev/rules.d/70-steam-controller.rules}} to {{ic|/etc/udev/rules.d}} with a later prioritiy and change anything that says {{ic|1=MODE="0660"}} to {{ic|1=MODE="066'''6'''"}} e.g.<br />
<br />
{{hc|/etc/udev/rules.d/99-steam-controller-perms.rules|<nowiki><br />
...<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"<br />
...<br />
</nowiki>}}<br />
<br />
You may have to reboot in order for the change to take effect.</div>Calinouhttps://wiki.archlinux.org/index.php?title=Gamepad&diff=541877Gamepad2018-09-17T20:46:03Z<p>Calinou: /* Connect Xbox Wireless Controller with Microsoft Xbox Wireless Adapter */ Grammar</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Gaming]]<br />
[[ja:ゲームパッド]]<br />
[[ru:Gamepad]]<br />
Joysticks can be a bit of a hassle to get working in Linux. Not because they are poorly supported, but simply because you need to determine which modules to load to get your joystick working, and it's not always very obvious!<br />
<br />
== Joystick input systems ==<br />
<br />
Linux has two different input systems for Joysticks – the original Joystick interface and the newer evdev-based interface.<br />
<br />
{{ic|1=/dev/input/jsX}} maps to the Joystick API interface and {{ic|/dev/input/event*}} maps to the evdev ones (this also includes other input devices such as mice and keyboards). Symbolic links to those devices are also available in {{ic|/dev/input/by-id/}} and {{ic|/dev/input/by-path/}} where the legacy Joystick API has names ending with {{ic|-joystick}} while the evdev have names ending with {{ic|-event-joystick}}.<br />
<br />
Most new games will default to the evdev interface as it gives more detailed information about the buttons and axes available and also adds support for force feedback.<br />
<br />
While SDL1 defaults to evdev interface you can force it to use the old Joystick API by setting the environment variable {{ic|1=SDL_JOYSTICK_DEVICE=/dev/input/js0}}. This can help many games such as X3. SDL2 supports only the new evdev interface.<br />
<br />
== Determining which modules you need ==<br />
<br />
Unless you're using very old joystick that uses gameport or proprietary USB protocol, you will need just the generic USB human interface device (HID) modules.<br />
<br />
For an extensive overview of all joystick related modules in Linux, you will need access to the Linux kernel sources -- specifically the Documentation section. Unfortunately, pacman kernel packages do not include what we need. If you have the kernel sources downloaded, have a look at {{ic|Documentation/input/joydev/}}. You can browse the kernel source tree at [https://kernel.org/ kernel.org] by clicking the "browse" (cgit - the git frontend) link for the kernel that you're using, then clicking the "tree" link near the top. Here's a link to the [https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/Documentation/input/joydev/joystick.rst documentation from the latest kernel].<br />
<br />
Some joysticks need specific modules, such as the Microsoft Sidewinder controllers ({{ic|sidewinder}}), or the Logitech digital controllers ({{ic|adi}}). Many older joysticks will work with the simple {{ic|analog}} module. If your joystick is plugging in to a gameport provided by your soundcard, you will need your soundcard drivers loaded - however, some cards, like the Soundblaster Live, have a specific gameport driver ({{ic|emu10k1-gp}}). Older ISA soundcards may need the {{ic|ns558}} module, which is a standard gameport module.<br />
<br />
As you can see, there are many different modules related to getting your joystick working in Linux, so I couldn't possibly cover everything here. Please have a look at the documentation mentioned above for details.<br />
<br />
=== Loading the modules for analogue devices ===<br />
<br />
You need to load a module for your gameport ({{ic|ns558}}, {{ic|emu10k1-gp}}, {{ic|cs461x}}, etc...), a module for your joystick ({{ic|analog}}, {{ic|sidewinder}}, {{ic|adi}}, etc...), and finally the kernel joystick device driver ({{ic|joydev}}). Add these to a new file in {{ic|/etc/modules-load.d/}}, or simply modprobe them. The {{ic|gameport}} module should load automatically, as this is a dependency of the other modules.<br />
<br />
=== USB joysticks ===<br />
<br />
You need to get USB working, and then modprobe your joystick driver, which is {{ic|usbhid}}, as well as {{ic|joydev}}. <br />
If you use a usb mouse or keyboard, {{ic|usbhid}} will be loaded already and you just have to load the {{ic|joydev}} module.<br />
<br />
== Testing your configuration ==<br />
<br />
Once the modules are loaded, you should be able to find a new device: {{ic|/dev/input/js0}} and a file ending with {{ic|-event-joystick}} in {{ic|/dev/input/by-id}} directory. You can simply {{ic|cat}} those devices to see if the joystick works - move the stick around, press all the buttons - you should see mojibake printed when you move the sticks or press buttons. <br />
<br />
Both interfaces are also supported in wine and reported as separate devices. You can test them with {{ic|1=wine control joy.cpl}}.<br />
<br />
{{Tip| Input devices by default have '''input''' group, for example {{pkg|pcsx2}} have no access to gamepad without rights. Make sure your user in '''input''' group.}}<br />
<br />
<br />
=== Joystick API ===<br />
There are a lot of applications that can test this old API, {{ic|jstest}} from the {{pkg|joyutils}} package is the simplest one. If the output is unreadable because the line printed is too long you can also use graphical tools. Plasma has a built in one in Input Devices panel in System Settings or {{AUR|jstest-gtk-git}} is an alternative.<br />
<br />
Use of {{ic|jstest}} is fairly simple, you just run {{ic|jstest /dev/input/js0}} and it will print a line with state of all the axes (normalised to {-32767,32767}) and buttons.<br />
<br />
After you start {{ic|jstest-gtk}}, it will just show you a list of joysticks available, you just need to select one and press Properties.<br />
<br />
=== evdev API ===<br />
<br />
The new 'evdev' API can be tested using the SDL2 joystick test application or using {{ic|evtest}} from community repository. Install {{AUR|sdl2-jstest-git}} and then run {{ic|sdl2-jstest --test 0}}. Use {{ic|sdl2-jstest --list}} to get IDs of other controllers if you have multiple ones connected.<br />
<br />
To test force feedback on the device, use {{ic|fftest}} from {{ic|linuxconsole}} package:<br />
$ fftest /dev/input/by-id/usb-*event-joystick<br />
<br />
==Setting up deadzones and calibration==<br />
If you want to set up the deadzones (or remove them completely) of your analog input you have to do it separately for the xorg (for mouse and keyboard emulation), Joystick API and evdev API.<br />
<br />
===Wine deadzones===<br />
Add the following registry entry and set it to a string from 0 to 10000 (affects all axes):<br />
HKEY_CURRENT_USER\Software\Wine\DirectInput\DefaultDeadZone<br />
Source: [http://wiki.winehq.org/UsefulRegistryKeys UsefulRegistryKeys]<br />
<br />
===Xorg deadzones===<br />
Add a similar line to {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it doesn't exist):<br />
{{hc|1=/etc/X11/xorg.conf.d/51-joystick.conf|2=<nowiki><br />
Section "InputClass"<br />
Option "MapAxis1" "deadzone=1000"<br />
EndSection<br />
</nowiki>}}<br />
1000 is the default value, but you can set anything between 0 and 30 000. To get the axis number see the "Testing Your Configuration" section of this article.<br />
If you already have an option with a specific axis just type in the {{ic|1=deadzone=value}} at the end of the parameter separated by a space.<br />
<br />
===Joystick API deadzones===<br />
The easiest way is using {{ic|jstest-gtk}} from {{AUR|jstest-gtk-git}}. Select the controller you want to edit, then click the Calibration button at the bottom of the dialog ('''don't''' click Start Calibration there). You can then set the CenterMin and CenterMax values (which control the center deadzone), RangeMin and RangeMax which control the end of throw deadzones. Note that the calibration settings are applied when the application opens the device, so you need to restart your game or test application to see updated calibration settings.<br />
<br />
After you set the deadzones use {{ic|jscal}} to dump the new values into a shell script:<br />
$ jscal -p /dev/input/jsX > jscal.sh # replace X with your joystick's number <br />
$ chmod +x jscal.sh<br />
<br />
Now you need to make a [[udev]] rule (for example {{ic|/etc/udev/rules.d and name it 85-jscal.rules}}) so the script will automatically run when you connect the controller:<br />
SUBSYSTEM=="input", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="c268", ACTION=="add", RUN+="/usr/bin/jscal.sh"<br />
To get the idVendor and idProduct use {{ic|udevadm info --attribute-walk --name /dev/input/jsX}}<br />
<br />
Use the `/dev/input/by-id/*-joystick` device names in case you use multiple controllers.<br />
<br />
===evdev API deadzones===<br />
The {{ic|evdev-joystick}} tool from the {{pkg|linuxconsole}} package can be used to view and change deadzones and calibration for {{ic|evdev}} API devices.<br />
<br />
To view your device configuration:<br />
$ evdev-joystick --showcal /dev/input/by-id/usb-*-event-joystick<br />
<br />
To change the deadzone for a particular axis, use a command like:<br />
$ evdev-joystick --evdev /dev/input/by-id/usb-*-event-joystick --axis 0 --deadzone 0<br />
<br />
To set the same deadzone for all axes at once, omit the "--axis 0" option.<br />
<br />
Use udev rules file to set them automatically when the controller is connected.<br />
<br />
Note that inside the kernel, the value is called {{ic|flatness}} and is set using the {{ic|EVIOCSABS}} {{ic|ioctl}}.<br />
<br />
Default configuration will look like similar to this:<br />
{{hc|$ evdev-joystick --showcal /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick|2= Supported Absolute axes:<br />
Absolute axis 0x00 (0) (X Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x01 (1) (Y Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x05 (5) (Z Rate Axis) (min: 0, max: 4095, flatness: 255 (=6.23%), fuzz: 15)<br />
Absolute axis 0x10 (16) (Hat zero, x axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)<br />
Absolute axis 0x11 (17) (Hat zero, y axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)}}<br />
<br />
While a more reasonable setting would be achieved with something like this (repeat for other axes):<br />
{{hc|$ evdev-joystick --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick --axis 0 --deadzone 512|2= Event device file: /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick<br />
Axis index to deal with: 0<br />
New dead zone value: 512<br />
Trying to set axis 0 deadzone to: 512<br />
Absolute axis 0x00 (0) (X Axis) Setting deadzone value to : 512<br />
(min: 0, max: 65535, flatness: 512 (=0.78%), fuzz: 255)}}<br />
<br />
===Configuring curves and responsivness===<br />
In case your game requires just limited amount of buttons or has good support for multiple controllers, you may have good results with using {{ic|xboxdrv}} to change response curves of the joystick.<br />
<br />
Below are the setups I use for Saitek X-55 HOTAS:<br />
$ xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Throttle_G0000021-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_#40=x1,ABS_#41=y1,ABS_X=x2,ABS_Y=y2' --device-name 'Hat and throttle' \<br />
--ui-axismap 'x2^cal:-32000:0:32000=,y2^cal:-32000:0:32000=' --silent<br />
<br />
this maps the EV_ABS event with id of 40 and 41 (use xboxdrv with --evdev-debug to see the events registered), which is the normally inaccessible "mouse pointer" on the throttle, to first gamepad joystick and throttles to second joystick, it also clamps the top and lower ranges as they not always register fully.<br />
<br />
A bit more interesting is the setup for the stick:<br />
$ xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_X=x1' --evdev-absmap 'ABS_Y=y1' --device-name 'Joystick' \<br />
--ui-axismap 'x1^cal:-32537:-455:32561=,x1^dead:-900:700:1=,x1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--ui-axismap 'y1^cal:-32539:-177:32532=,y1^dead:-700:2500:1=,y1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--evdev-absmap 'ABS_RZ=x2' --ui-axismap 'x2^cal:-32000:-100:32000,x2^dead:-1500:1000:1=,x2^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--silent<br />
<br />
this maps the 3 joystick axes to gamepad axes and changes the calibration (min value, centre value, max value), dead zones (negative side, positive side, flag to turn smoothing) and finally change of response curve to a more flat one in the middle.<br />
<br />
You can also modify the responsiveness by setting the 'sen' (sensitivity). Setting it to value of 0 will give you a linear sensitivity, value of -1 will give very insensitive axis while value of 1 will give very sensitive axis. You can use intermediate values to make it less or more sensitive. Internally xboxdrv uses a quadratic formula to calculate the resulting value, so this setting gives a more smooth result than 'resp' shown above.<br />
<br />
Nice thing about xboxdrv is that it exports resulting device as both old Joystick API and new style evdev API so it should be compatible with basically any application.<br />
<br />
== Disable joystick from controlling mouse ==<br />
If you want to play games with your controller, you might want to disable joystick control over mouse cursor. To do this, edit {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it doesn't exists) so that it looks like this:<br />
{{hc|/etc/X11/xorg.conf.d/51-joystick.conf |<br />
Section "InputClass"<br />
Identifier "joystick catchall"<br />
MatchIsJoystick "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "joystick"<br />
Option "StartKeysEnabled" "False" #Disable mouse<br />
Option "StartMouseEnabled" "False" #support<br />
EndSection}}<br />
<br />
== Using Joystick to send keystrokes ==<br />
<br />
A couple joystick to keystroke programs exist like {{AUR|qjoypad}} or {{AUR|antimicro}}, all work well without the need for X.org configuration.<br />
<br />
=== Xorg configuration example ===<br />
<br />
This is a good solution for systems where restarting Xorg is a rare event because it is a static configuration loaded only on X startup. The example runs on a [[Kodi]] media PC, controlled with a Logitech Cordless RumblePad 2. Due to a problem with the d-pad (a.k.a. "hat") being recognized as another axis, [[Joy2key]] was used as a workaround. Since upgrade to Kodi version 11.0 and joy2key 1.6.3-1, this setup no longer worked and the following was created for letting Xorg handle joystick events.<br />
<br />
First, [[install]] the {{AUR|xf86-input-joystick}} package. Then, create {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} like so:<br />
{{bc|<nowiki><br />
Section "InputClass"<br />
Identifier "Joystick hat mapping"<br />
Option "StartKeysEnabled" "True"<br />
#MatchIsJoystick "on"<br />
Option "MapAxis5" "keylow=113 keyhigh=114"<br />
Option "MapAxis6" "keylow=111 keyhigh=116"<br />
EndSection<br />
</nowiki>}}<br />
{{Note|The {{ic|MatchIsJoystick "on"}} line does not seem to be required for the setup to work, but you may want to uncomment it.}}<br />
<br />
== Specific devices ==<br />
<br />
While most joysticks, especially USB based ones should just work, some may require (or give better results) if you use alternative drivers. If it doesn't work the first time, do not give up, and read those docs thoroughly!<br />
<br />
=== Dance pads ===<br />
Most dance pads should work. However some pads, especially those used from a video game console via an adapter, have a tendency to map the directional buttons as axis buttons. This prevents hitting left-right or up-down simultaneously. This behavior can be fixed for devices recognized by xpad via a module option:<br />
<br />
# modprobe -r xpad<br />
# modprobe xpad dpad_to_buttons=1<br />
<br />
=== Logitech Thunderpad Digital ===<br />
<br />
Logitech Thunderpad Digital won't show all the buttons if you use the {{ic|analog}} module. Use the device specific {{ic|adi}} module for this controller.<br />
<br />
=== Nintendo Gamecube Controller ===<br />
<br />
Dolphin Emulator has a [https://wiki.dolphin-emu.org/index.php?title=How_to_use_the_Official_GameCube_Controller_Adapter_for_Wii_U_in_Dolphin page on their wiki] that explains how to use the official Nintendo USB adapter with a Gamecube controller. This configuration also works with the Mayflash Controller Adapter if the switch is set to "Wii U".<br />
<br />
By default, the controller will register with [[udev]], but will only be readable by the root user. You can fix this by adding a udev device rule, like the below. <br />
<br />
{{hc<br />
|head=/etc/udev/rules.d/51-gcadapter.rules<br />
|output=<nowiki>SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="0337", MODE="0666"</nowiki><br />
}}<br />
<br />
This only matches the USB device with the specified vendor and product IDs, which match those of the official USB adapter. It sets the permissions of the device file to 0666 so that programs that aren't running as root can read the device's input. <br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
=== Nintendo Switch Wired Pro Controller ===<br />
<br />
While the controller works for native Linux games, this controller isn't detected by Steam. To fix this, we'll need to add a line to 70-steam-controller.rules.<br />
<br />
{{hc<br />
|head=/lib/udev/rules.d/70-steam-controller.rules<br />
|output=<nowiki># NS PRO Controller USB<br />
KERNEL=="hidraw*", ATTRS{idVendor}=="20d6", ATTRS{idProduct}=="a711", MODE="0660", TAG+="uaccess"</nowiki><br />
}}<br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
=== PlayStation 3/4 controller ===<br />
<br />
The DualShock 3, DualShock 4 and Sixaxis controllers work out of the box when plugged in via USB (the PS button will need to be pushed to begin). They can also be used wirelessly via Bluetooth.<br />
<br />
Steam properly recognizes it as a PS3 pad and Big Picture can be launched with the PS button. Big Picture and some games may act as if it was a 360 controller. Gamepad control over mouse is on by default. You may want to turn it off before playing games, see [[#Joystick moving mouse]].<br />
<br />
=====Connecting via Bluetooth=====<br />
<br />
Install the {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}} packages, which includes the ''sixaxis'' plugin. Then [[start]] {{ic|bluetooth.service}}, plug the controller in via USB, and the plugin should program your PC's bluetooth address into the controller automatically.<br />
<br />
You can now disconnect your controller. The next time you hit the PlayStation button it will connect without asking anything else.<br />
<br />
Alternatively, you can press the share button and the PlayStation button simultaneously to put the gamepad in pairing mode, and pair as you would normally.<br />
<br />
Remember to disconnect the controller when you are done as the controller will stay on when connected and drain the battery.<br />
<br />
{{Note|If the controller does not connect, make sure the bluetooth interface is turned on and the controllers have been trusted. (See [[Bluetooth]])}}<br />
<br />
=====Using generic/clone controllers=====<br />
<br />
Using generic/clone Dualshock controllers is possible, however there are some issues that may require to install patched packages. The default Bluetooth protocol stack doesn't detect some of the clone controllers, the {{AUR|bluez-ps3}} package is a version patched to be able to detect them. Another issue is a bug where the controller starts to non-stop rumble as soon as it gets connected via USB. That can be fixed by using a patched version of the hid-sony driver, which is available on the {{AUR|dkms-hid-sony-shanwan}} package.<br />
<br />
=== iPEGA-9017s and other Bluetooth gamepads ===<br />
<br />
If you want to use one of the widely available bluetooth gamepads, such as iPEGA-9017s designed mostly for Android and iOS devices you would need {{AUR|xboxdrv}}, {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}}. You should connect it in gamepad mode (if there are different modes, choose the gamepad one). Technically it's ready to be used, but in most cases games would not recognize it, and you would have to map it individually for all application. The best way to simplify it and make it work with all applications is to mimic Microsoft X360 controller with {{AUR|xboxdrv}}.<br />
Once connected you can create a udev rule to give it a persistent name, that would come in handy when setting it up.<br />
<br />
{{hc<br />
|/etc/udev/rules.d/99-btjoy.rules|2=<br />
#Create a symlink to appropriate /dev/input/eventX at /dev/btjoy<br />
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="Bluetooth Gamepad", ATTRS{uniq}=="00:17:02:01:ae:2a", SYMLINK+="btjoy"<br />
}}<br />
<br />
Replace "Bluetooth Gampad" with your device name and "00:17:02:01:ae:2a" with your device's address.<br />
<br />
Next, create a configuration for {{AUR|xboxdrv}} somewhere, for example:<br />
<br />
{{hc<br />
|~/.config/xboxdrv/ipega.conf|2=<br />
#iPEGA PG-9017S Config <br />
<br />
[xboxdrv]<br />
evdev-debug = true<br />
evdev-grab = true<br />
rumble = false<br />
mimic-xpad = true<br />
<br />
[evdev-absmap]<br />
ABS_HAT0X = dpad_x<br />
ABS_HAT0Y = dpad_y<br />
<br />
ABS_X = X1<br />
ABS_Y = Y1<br />
<br />
ABS_Z = X2<br />
ABS_RZ = Y2<br />
<br />
[axismap]<br />
-Y1 = Y1<br />
-Y2 = Y2<br />
<br />
[evdev-keymap]<br />
BTN_EAST=a<br />
BTN_C=b<br />
BTN_NORTH=y<br />
BTN_SOUTH=x<br />
BTN_TR2=start<br />
BTN_TL2=back<br />
BTN_Z=rt<br />
BTN_WEST=lt<br />
<br />
BTN_MODE = guide<br />
}}<br />
<br />
Refer to the xboxdrv man to see all the options.<br />
<br />
Now when you have the config and your device is connected you can start the {{AUR|xboxdrv}} like so:<br />
<br />
{{ic | sudo xboxdrv --evdev /dev/btjoy --config .config/xboxdrv/ipega.conf}}<br />
<br />
Your games will now work with bluetooth gamepad as long as xboxdrv is running.<br />
<br />
=== Steam Controller ===<br />
<br />
{{Note|Kernel 4.18 [https://lkml.org/lkml/2018/4/16/380 provides a kernel driver] for wired/wireless use of the steam controller as a controller input device without [[Steam]].}}<br />
<br />
The [[Steam]] client will recognize the controller and provide keyboard/mouse/gamepad emulation while Steam is running. The in-game Steam overlay needs to be enabled and working in order for gamepad emulation to work. You may need to run {{ic|udevadm trigger}} with root privileges or plug the dongle out and in again, if the controller doesn't work immediately after installing and running Steam. If all else fails, try restarting the computer while the dongle is plugged in.<br />
<br />
If you can't get the Steam Controller to work, see [[#Steam Controller not pairing]].<br />
<br />
Alternatively you can install {{AUR|python-steamcontroller-git}} to have controller and mouse emulation without Steam or {{AUR|sc-controller}} for a versatile graphical configuration tool simillar to what is provided by the Steam client.<br />
<br />
On some desktop environments the on-screen keyboard might freeze when trying to input text after one or two characters. This is a problem with window focus. Check the settings for your [[window manager]] to see if it is possible to have focus follow the mouse or automatically focus new windows. Preventing the keyboard from receiving focus will fix the issue in [[Awesome]], see [[Awesome#Steam Keyboard]].<br />
<br />
{{Note|If you do not use the [[Steam runtime]], you might actually need to disable the overlay for the controller to work in certain games (Rocket Wars, Rocket League, Binding of Isaac, etc.). Right click on a game in your library, select "Properties", and uncheck "Enable Steam Overlay".}}<br />
<br />
==== Wine ====<br />
<br />
{{AUR|python-steamcontroller-git}} can also be used to make the Steam Controller work for games running under Wine. You need to find and download the application {{ic|xbox360cemu.v.3.0}} (e.g. from [https://github.com/jacobmischka/ds4-in-wine/tree/master/xbox360cemu.v.3.0 here]). Then copy the files {{ic|dinput8.dll}}, {{ic|xbox360cemu.ini}}, {{ic|xinput1_3.dll}} and {{ic|xinput_9_1_0.dll}} to the directory that contains your game executable. Edit {{ic|xbox360cemu.ini}} and only change the following values under {{ic|[PAD1]}} to remap the Steam Controller correctly to a XBox controller.<br />
<br />
{{hc|xbox360cemu.ini|2= Right Analog X=4<br />
Right Analog Y=-5<br />
A=1<br />
B=2<br />
X=3<br />
Y=4<br />
Back=7<br />
Start=8<br />
Left Thumb=10<br />
Right Thumb=11<br />
Left Trigger=a3<br />
Right Trigger=a6}}<br />
<br />
Now start python-steamcontroller in Xbox360 mode ({{ic|sc-xbox.py start}}). You might also want to copy {{ic|XInputTest.exe}} from {{ic|xbox360cemu.v.3.0}} to the same directory and run it with Wine in order to test if the mappings work correctly. However neither mouse nor keyboard emulation work with this method.<br />
<br />
Alternatively you can use {{AUR|sc-controller}} for a similar graphical setup as Steam's own configurator. As of writing, it's a bit buggy here and there but offers an easy click and go way of configuring the controller.<br />
<br />
=== Xbox 360 controller ===<br />
<br />
Both the wired and wireless (with the ''Xbox 360 Wireless Receiver for Windows'') controllers are supported by the {{ic|xpad}} kernel module and should work without additional packages.<br />
<br />
It has been reported that the default xpad driver has some issues with a few newer wired and wireless controllers, such as:<br />
* incorrect button mapping. ([https://github.com/ValveSoftware/steam-for-linux/issues/95#issuecomment-14009081 discussion in Steam bugtracker])<br />
* not-working sync. All four leds keep blinking, but controller works. ([https://bbs.archlinux.org/viewtopic.php?id=156028 discussion in Arch Forum])<br />
<br />
If you experience such issues, you can use either [[#SteamOS xpad]] or [[#xboxdrv]] instead of the default {{ic|xpad}} driver.<br />
<br />
If you wish to use the controller for controlling the mouse, or mapping buttons to keys, etc. you should use the {{AUR|xf86-input-joystick}} package (configuration help can be found using {{ic|man joystick}}). If the mouse locks itself in a corner, it might help changing the {{ic|MatchDevicePath}} in {{ic|/etc/X11/xorg.conf.d/50-joystick.conf}} from {{ic|/dev/input/event*}} to {{ic|/dev/input/js*}}.<br />
<br />
{{Tip|If you use the [[TLP]] power management tool, you may experience connection issues with your Microsoft wireless adapter (e.g. the indicator LED will go out after the adapter has been connected for a few seconds, and controller connection attempts fail). This is due to TLP's USB autosuspend functionality, and the solution is to add the Microsoft wireless adapter's device ID to this feature's blacklist (USB_BLACKLIST, check [http://linrunner.de/en/tlp/docs/tlp-configuration.html#usb TLP configuration] for more details).}}<br />
<br />
==== SteamOS xpad ====<br />
<br />
If you have issues with the default {{ic|xpad}} kernel module, you can install the SteamOS version. There is still a known issue with compatibility between wireless Xbox360 controllers and games made in GameMaker Studio. If you encounter this problem, the only known workaround is to use xboxdrv. YoYo Games has refused to acknowledge this as a bug with their product and it is unlikely to ever be fixed.<br />
<br />
First make sure you have [[DKMS]] installed and running, then install the modified kernel module {{AUR|steamos-xpad-dkms}}. During the installation you'll see that new xpad kernel module is strapped to your current kernel:<br />
<br />
Creating symlink /var/lib/dkms/steamos-xpad-dkms/0.1/source -&gt;<br />
/usr/src/steamos-xpad-dkms-0.1<br />
<br />
DKMS: add completed.<br />
<br />
Kernel preparation unnecessary for this kernel. Skipping...<br />
<br />
Building module:<br />
cleaning build area....<br />
make KERNELRELEASE=3.12.8-1-ARCH KVERSION=3.12.8-1-ARCH....<br />
cleaning build area....<br />
<br />
Then unload the old xpad module and load new one:<br />
<br />
# rmmod xpad<br />
# modprobe steamos-xpad<br />
<br />
Or just restart your computer.<br />
<br />
==== xboxdrv ====<br />
<br />
xboxdrv is an alternative to {{ic|xpad}} which provides more functionality and might work better with certain controllers. It works in userspace and can be launched as system service. <br />
<br />
Install it with the {{AUR|xboxdrv}} package. Then [[start]]/[[enable]] {{ic|xboxdrv.service}}.<br />
<br />
If you have issues with the controller being recognized but not working in steam games or working but with incorrect mappings, it may be required to modify you config as such:<br />
{{hc<br />
|/etc/default/xboxdrv|2=<br />
[xboxdrv]<br />
silent = true<br />
device-name = "Xbox 360 Wireless Receiver"<br />
mimic-xpad = true<br />
deadzone = 4000<br />
<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Multiple controllers =====<br />
<br />
xboxdrv supports a multitude of controllers, but they need to be set up in {{ic|/etc/default/xboxdrv}}. For each extra controller, add an {{ic|1=next-controller = true}} line. For example, when using 4 controllers, add it 3 times:<br />
<br />
{{bc|<nowiki><br />
[xboxdrv]<br />
silent = true<br />
next-controller = true<br />
next-controller = true<br />
next-controller = true<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
</nowiki>}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Mimic Xbox 360 controller with other controllers =====<br />
<br />
xboxdrv can be used to make any controller register as an Xbox 360 controller with the {{ic|--mimic-xpad}} switch. This may be desirable for games that support Xbox 360 controllers out of the box, but have trouble detecting or working with other gamepads.<br />
<br />
First, you need to find out what each button and axis on the controller is called. You can use {{Pkg|evtest}} for this. Run {{ic|evtest}} and select the device event ID number ({{ic|/dev/input/event*}}) that corresponds to your controller. Press the buttons on the controller and move the axes to read the names of each button and axis.<br />
<br />
Here is an example of the output:<br />
{{bc|<nowiki><br />
<br />
Event: time 1380985017.964843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985017.964843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 1<br />
Event: time 1380985017.964843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.076843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985018.076843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 0<br />
Event: time 1380985018.076843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.460841, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.460841, type 1 (EV_KEY), code 289 (BTN_THUMB), value 1<br />
Event: time 1380985018.460841, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.572835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.572835, type 1 (EV_KEY), code 289 (BTN_THUMB), value 0<br />
Event: time 1380985018.572835, -------------- SYN_REPORT ------------<br />
Event: time 1380985019.980824, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985019.980824, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 1<br />
Event: time 1380985019.980824, -------------- SYN_REPORT ------------<br />
Event: time 1380985020.092835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985020.092835, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 0<br />
Event: time 1380985020.092835, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.596806, type 3 (EV_ABS), code 3 (ABS_RX), value 18<br />
Event: time 1380985023.596806, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.612811, type 3 (EV_ABS), code 3 (ABS_RX), value 0<br />
Event: time 1380985023.612811, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.708768, type 3 (EV_ABS), code 3 (ABS_RX), value 14<br />
Event: time 1380985023.708768, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.724772, type 3 (EV_ABS), code 3 (ABS_RX), value 128<br />
Event: time 1380985023.724772, -------------- SYN_REPORT ------------<br />
</nowiki>}}<br />
<br />
In this case, {{ic|BTN_THUMB}}, {{ic|BTN_THUMB2}} and {{ic|BTN_PINKIE}} are buttons and {{ic|ABS_RX}} is the X axis of the right analogue stick.<br />
You can now mimic an Xbox 360 controller with the following command:<br />
<br />
$ xboxdrv --evdev /dev/input/event* --evdev-absmap ABS_RX=X2 --evdev-keymap BTN_THUMB2=a,BTN_THUMB=b,BTN_PINKIE=rt --mimic-xpad<br />
<br />
The above example is incomplete. It only maps one axis and 3 buttons for demonstration purposes. Use {{ic|xboxdrv --help-button}} to see the names of the Xbox controller buttons and axes and bind them accordingly by expanding the command above. Axes mappings should go after {{ic|--evdev-absmap}} and button mappings follow {{ic|--evdev-keymap}} (comma separated list; no spaces).<br />
<br />
By default, xboxdrv outputs all events to the terminal. You can use this to test that the mappings are correct. Append the {{ic|--silent}} option to keep it quiet.<br />
<br />
=== Xbox Wireless Controller / Xbox One Wireless Controller ===<br />
<br />
==== Connect Xbox Wireless Controller with usb cable ====<br />
<br />
This is supported by the kernel and should work without additional packages.<br />
<br />
==== Connect Xbox Wireless Controller with bluetooth ====<br />
<br />
You should disable ertm to get it work.<br />
<br />
either<br />
<br />
# echo 1 > /sys/module/bluetooth/parameters/disable_ertm<br />
<br />
or<br />
<br />
Add this file to your config:<br />
{{hc<br />
|/etc/modprobe.d/xbox_bt.conf|2=<br />
options bluetooth disable_ertm=1<br />
}}<br />
<br />
===== xpadneo =====<br />
<br />
A relatively new driver which does (yet) support only the Xbox One S controller via Bluetooth is called 'xpadneo'.<br />
In exchange for supporting just one hardware so far, it enables one to read out the correct battery level, supports rumble (even the one on the trigger buttons - L2/R2), corrects the (sometimes wrong) button mapping and more.<br />
<br />
Installation is done using DKMS.<br />
<br />
Download: https://github.com/atar-axis/xpadneo/<br />
<br />
Try {{AUR|xpadneo-dkms-git}}.<br />
<br />
==== Connect Xbox Wireless Controller with Microsoft Xbox Wireless Adapter ====<br />
<br />
It does not work on Linux.<br />
<br />
===Logitech Dual Action===<br />
<br />
The Logitech Dual Action gamepad has a very similar mapping to the PS2 pad, but some buttons and triggers need to be swapped to mimic the Xbox controller.<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TRIGGER=x,BTN_TOP=y,BTN_THUMB=a,BTN_THUMB2=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lt,BTN_BASE2=rt,BTN_TOP2=lb,BTN_PINKIE=rb,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
===PlayStation 2 controller via USB adapter===<br />
<br />
To fix the button mapping of PS2 dual adapters and mimic the Xbox controller you can run the following command:<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TOP=x,BTN_TRIGGER=y,BTN_THUMB2=a,BTN_THUMB=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lb,BTN_BASE2=rb,BTN_TOP2=lt,BTN_PINKIE=rt,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
===PlayStation 3 controller via USB===<br />
<br />
If you own a PS3 controller and can connect with USB, xboxdrv has the mappings built in. Just run the program (and detach the running driver) and it works! <br />
<br />
# xboxdrv --silent --detach-kernel-driver<br />
<br />
There are some games which might also need the {{ic|--mimic-xpad}} option, additionally.<br />
<br />
===PlayStation 3 controller via Bluetooth===<br />
<br />
With your controller connected via Bluetooth, find the device address with {{ic|bluetoothctl}}. Then create a new udev rule with the following content:<br />
<br />
{{hc|1=/etc/udev/rules.d/99-dualshock.rules|2=<br />
KERNEL=="event*", SUBSYSTEM=="input", ATTRS{uniq}=="<device_addr_you_got_on_pairing>", SYMLINK+="input/dualshock3"<br />
}}<br />
<br />
The address must be in lowercase, like {{ic|06:9a:b4:c8:ef:8b}}.<br />
<br />
Now run xboxdrv over the new device:<br />
<br />
$ xboxdrv --evdev /dev/input/dualshock3 --mimic-xpad<br />
<br />
===PlayStation 4 controller===<br />
<br />
==Button mapping==<br />
<br />
To fix the button mapping of PS4 controller you can use the following command with xboxdrv (or try with the [https://github.com/chrippa/ds4drv ds4drv] program):<br />
<br />
# xboxdrv \<br />
--evdev /dev/input/by-id/usb-Sony_Computer_Entertainment_Wireless_Controller-event-joystick\<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1 \<br />
--evdev-absmap ABS_Z=x2,ABS_RZ=y2 \<br />
--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--evdev-keymap BTN_A=x,BTN_B=a \<br />
--evdev-keymap BTN_C=b,BTN_X=y \<br />
--evdev-keymap BTN_Y=lb,BTN_Z=rb \<br />
--evdev-keymap BTN_TL=lt,BTN_TR=rt \<br />
--evdev-keymap BTN_SELECT=tl,BTN_START=tr \<br />
--evdev-keymap BTN_TL2=back,BTN_TR2=start \<br />
--evdev-keymap BTN_MODE=guide \<br />
--axismap -y1=y1,-y2=y2 \<br />
--mimic-xpad \<br />
--silent<br />
<br />
<br />
<br />
==Fix Motion control conflict (gamepad won't work on somes apps)==<br />
<br />
Dualshock 4 V1 and V2 are both like 3 devices, touchpad, motion control, and joypad.<br />
<br />
With somes softwares like Parsec and Shadow cloud gaming streaming apps, motion control is in conflict with joypad, you can disable touchpad and motion control with :<br />
<br />
<code>sudo nano /etc/udev/rules.d/51-disable-DS3-and-DS4-motion-controls.rules</code><br />
<br />
Then copy/paste and register :<br />
<br />
<code><br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Motion Sensors", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Touchpad", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
</code><br />
<br />
This should work in USB and Bluetooth mode. (If you want use bluetooth mode, press "home" button and "share" button together, white led of gamepad should blink very quickly, then add wireless controller with your bluetooth manager (bluez, gnome-bluetooth...)<br />
<br />
== Troubleshooting ==<br />
<br />
=== Joystick moving mouse ===<br />
<br />
Sometimes USB joystick can be recognized as HID mouse (only in X, it is still being installed as {{ic|/dev/input/js0}} as well). Known issue is cursor being moved by the joystick, or escaping to en edge of a screen right after plugin. If your application can detect joystick by it self, you can remove the {{AUR|xf86-input-joystick}} package.<br />
<br />
A more gentle solution is described in [[#Disable joystick from controlling mouse]].<br />
<br />
=== Joystick not working in FNA/SDL based games ===<br />
If you are using a generic non-widely used gamepad you may encounter issues getting the gamepad recognized in games based on SDL. Since [https://github.com/flibitijibibo/FNA/commit/e55742cfe7e38b778a21ed8a12cb2f2081490d8d 14 May 2015], FNA supports dropping a {{ic|gamecontrollerdb.txt }} into the executable folder of the game, for example the [https://github.com/gabomdq/SDL_GameControllerDB SDL_GameControllerDB].<br />
<br />
As an alternative and for older versions of FNA or for SDL you can generate a mapping yourself by downloading the SDL source code via http://libsdl.org/, navigating to {{ic|/test/}}, compile the {{ic|controllermap.c}} program (alternatively install {{AUR|controllermap}}) and run the test. After completing the controllermap test, a guid will be generated that you can put in the {{ic|SDL_GAMECONTROLLERCONFIG}} environment variable which will then be picked up by SDL/FNA games. For example:<br />
<br />
$ export SDL_GAMECONTROLLERCONFIG="030000008f0e00000300000010010000,GreenAsia Inc. USB Joystick ,platform:Linux,x:b3,a:b2,b:b1,y:b0,back:b8,start:b9,dpleft:h0.8,dpdown:h0.0,dpdown:h0.4,dpright:h0.0,dpright:h0.2,dpup:h0.0,dpup:h0.1,leftshoulder:h0.0,leftshoulder:b6,lefttrigger:b4,rightshoulder:b7,righttrigger:b5,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a3,righty:a2,"<br />
<br />
=== Joystick not recognized by all programs ===<br />
<br />
Some software, Steam for example, will only recognize the first joystick it encounters. Due to a bug in the driver for Microsoft wireless periphery devices this can in fact be the bluetooth dongle. If you find you have a {{ic|/dev/input/js*}} and {{ic|/dev/input/event*}} belonging to you keyboard's bluetooth transceiver you can get automatically get rid of it by creating according udev rules.<br />
Create a {{ic|/}}:<br />
{{hc|/etc/udev/rules.d/99-btcleanup.rules|<nowiki><br />
ACTION=="add", KERNEL=="js[0-9]*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/js%n"<br />
ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/event%n"<br />
</nowiki>}}<br />
Correct the {{ic|<nowiki>KERNELS=="..."</nowiki>}} to match your device. The correct value can be found by running<br />
<br />
# udevadm info -an /dev/input/js0<br />
<br />
Assuming the device in question is {{ic|/dev/input/js0}}. After you placed the rule reload the rules with<br />
<br />
# udevadm control --reload<br />
<br />
Then replug the device making you trouble. The joystick and event devices should be gone, although their number will still be reserved. But the files are out of the way.<br />
<br />
=== Steam Controller not pairing ===<br />
<br />
There are some unknown cases where the packaged udev rule for the Steam controller does not work ({{bug|47330}}). The most reliable workaround is to make the controller world readable. Copy the rule {{ic|/usr/lib/udev/rules.d/70-steam-controller.rules}} to {{ic|/etc/udev/rules.d}} with a later prioritiy and change anything that says {{ic|1=MODE="0660"}} to {{ic|1=MODE="066'''6'''"}} e.g.<br />
<br />
{{hc|/etc/udev/rules.d/99-steam-controller-perms.rules|<nowiki><br />
...<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"<br />
...<br />
</nowiki>}}<br />
<br />
You may have to reboot in order for the change to take effect.</div>Calinouhttps://wiki.archlinux.org/index.php?title=Systemd/Timers&diff=537370Systemd/Timers2018-08-23T13:39:21Z<p>Calinou: Improve writing style</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[fr:Systemd/cron]]<br />
[[ja:Systemd/タイマー]]<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 />
Timers are [[systemd]] unit files whose name ends in {{ic|.timer}} that control {{ic|.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 {{ic|.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|1=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|1=On''Type''Sec=}}. Common monotonic timers include {{ic|OnBootSec}} and {{ic|OnActiveSec}}.<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 />
== Service unit ==<br />
<br />
For each {{ic|.timer}} file, a matching {{ic|.service}} file exists (e.g. {{ic|foo.timer}} and {{ic|foo.service}}). The {{ic|.timer}} file activates and controls the {{ic|.service}} file. The {{ic|.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|1=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 {{ic|.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|1=Persistent=true}}), for example due to the system being powered off: <br />
<br />
{{hc|/etc/systemd/system/foo.timer|<nowiki><br />
[Unit]<br />
Description=Run foo weekly<br />
<br />
[Timer]<br />
OnCalendar=weekly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target</nowiki>}}<br />
<br />
When more specific dates and times are required, {{ic|OnCalendar}} events uses the following format:<br />
{{ic|DayOfWeek Year-Month-Day Hour:Minute:Second}}<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 on 4am, use:<br />
<br />
OnCalendar=*-*-* 4:00: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 />
<br />
== Transient .timer units ==<br />
<br />
One can use {{ic|systemd-run}} to create transient {{ic|.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|1=OnFailure=}}.<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}} 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}}:<br />
<br />
{{hc|/usr/local/bin/systemd-email|<nowiki>#!/bin/bash<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|1=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 />
=== 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. {{AUR|systemd-cron-next}} and {{AUR|systemd-cron}} are two such packages. These 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 />
== See also ==<br />
<br />
* {{man|5|systemd.timer}}<br />
* [https://fedoraproject.org/wiki/Features/SystemdCalendarTimers Fedora Project wiki page] on ''systemd'' calendar timers<br />
* [https://wiki.gentoo.org/wiki/Systemd#Timer_services Gentoo wiki section] on ''systemd'' timer services<br />
* {{App|systemd-cron-next|tool to generate timers/services from crontab and anacrontab files|https://github.com/systemd-cron/systemd-cron-next|{{Aur|systemd-cron-next}}}}<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}}}}</div>Calinouhttps://wiki.archlinux.org/index.php?title=S.M.A.R.T&diff=532463S.M.A.R.T2018-08-04T13:29:42Z<p>Calinou: Create a redirect because links on Discord do not include the final period</p>
<hr />
<div>#REDIRECT [[S.M.A.R.T.]]</div>Calinouhttps://wiki.archlinux.org/index.php?title=Nonfree_applications_package_guidelines&diff=529757Nonfree applications package guidelines2018-07-15T12:26:11Z<p>Calinou: /* Unpacking */ upx is not an encryption tool, it compresses</p>
<hr />
<div>[[Category:Package development]]<br />
[[ja:ノンフリーアプリケーションパッケージガイドライン]]<br />
[[pt:Nonfree applications package guidelines]]<br />
{{Package guidelines}}<br />
<br />
{{Expansion|cover about encrypting archives, symlinking etc.}}<br />
<br />
For many applications (most of which are Windows ones) there are neither sources nor tarballs available. Many of such applications can not be freely distributed because of license restrictions and/or lack of legal ways to obtain installer for no fee. Such software obviously can not be included into the [[official repositories]] but due to nature of [[AUR]] it is still possible to privately [[makepkg|build packages]] for it, manageable with [[pacman]].<br />
{{Note|All information here is package-agnostic, for information specific to the most typical nonfree software see [[Wine PKGBUILD guidelines]].}}<br />
<br />
== Rationale ==<br />
There are multiple reasons for packaging even non-packageable software:<br />
* Simplification of installation/removal process<br />
:This is applicable even to the simplest of apps, which consist of a single script to be installed into {{Ic|/usr/bin}}. Instead of issuing:<br />
:{{bc|$ chmod +x ''filename''}}<br />
:{{bc|$ chown root:root ''filename''}}<br />
:{{bc|# cp ''filename'' /usr/bin/}}<br />
:you can type just<br />
:{{bc|$ makepkg -i}}<br />
:Most non-free applications are obviously much more complicated, but the burden of downloading an archive/installer from a homepage (often full of advertising), unpacking/decrypting it, hand-writing stereotypical launcher scripts and doing other similar tasks can be effectively lightened by a well-written packaging script.<br />
* Utilizing pacman capabilities<br />
:The ability to track state, perform automatic updates of any installed piece of software, determine ownership of every single file, and store compressed packages in a well-organized cache is what makes GNU/Linux distributions so powerful.<br />
* Sharing code and knowledge<br />
:It is simpler to apply tweaks, fix bugs and seek/provide help in a single public place like AUR versus submitting patches to proprietary developers who may have ceased support or asking vague questions on general purpose forums.<br />
<br />
== Common rules ==<br />
=== Avoid nonfree software when possible ===<br />
Yes, it's better to leave this guide and spend some time searching (or maybe even creating) alternatives to an application you wanted to package because:<br />
<br />
# It is better to support software that is owned by us all than software that is owned by a company<br />
# It is better to support software that is actively maintained<br />
# It is better to support software that can be fixed if just one person out of millions cares enough<br />
<br />
=== Use open source variants where possible ===<br />
Many commercial games ([[List of Applications/Games|some are listed in this Wiki]]) have open source engines and many old games can be played with emulators such as [[Wikipedia:ScummVM|ScummVM]]. Using open source engines together with the original game assets gives users access to bug fixes and eliminates several issues caused by binary packages.<br />
<br />
=== Keep it simple ===<br />
If the packaging of some program requires more effort and hacks than buying and using the original version - do the simplest thing, it is Arch!<br />
<br />
== Package naming ==<br />
Before choosing a name on your own, search in AUR for existing versions of the software you want to package. Try to use established naming conversion (e.g. do not create something like {{AUR|gish-hb}}{{Broken package link|{{aur-mirror|gish-hb}}}} when there are already {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}} and {{AUR|uplink-hib}}). Use suffix {{Ic|-bin}} '''always''' unless you are sure there will never be a source-based package&mdash;its creator would have to ask you (or in worst case TUs) to orphan existing package for him and you both will end up with PKGBUILDs cluttered with additional {{Ic|replaces}} and {{Ic|conflicts}}.<br />
<br />
== File placement ==<br />
Again, analyze existing packages (if present) and decide whether or not you want to conflict with them. Do not place things under {{Ic|/opt}} unless you want to use some ugly hacks like giving ownership {{Ic|root:games}} to the package directory (so users in group {{Ic|games}} running the game can write files in the game's own folder).<br />
<br />
== Missing files ==<br />
For most commercial games there is no way to (legally) download game files, which is the preferable way to get them for normal packages. Even when it is possible to download files after providing a password (like with all [[Wikipedia:Humble Indie Bundle|Humble Indie Bundle]] games) asking user for this password and downloading somewhere in {{Ic|build}} function is not recommended for a variety of reasons (for example, the user may have no Internet access but have all files downloaded and stored locally). The following options should be considered:<br />
<br />
* '''There is only one way to obtain files'''<br />
:* Software is distributed in archive/installer<br />
:Add the required file to {{Ic|sources}} array:<br />
:{{Bc|1=sources=(... "''originalname''::'''file://'''''originalname''")}}<br />
:This way the link to file in AUR web interface will look different from names of files included in source tarball.<br />
:Add following comment on package page:<br />
:{{bc|Need archive/installer to work.}}<br />
:and explain the details in PKGBUILD source.<br />
<br />
:* Software is distributed on compact-disk<br />
:Add installer script and {{Ic|.install}} file to package contents, like in package {{AUR|tsukihime-en}}{{Broken package link|{{aur-mirror|tsukihime-en}}}}.<br />
<br />
* '''There are several ways to obtain files'''<br />
Copying files from disk / downloading from Net / getting from archive during {{Ic|build}} phase may look like a good idea but it is not recommended because it limits the user's possibilities and makes package installation interactive (which is generally discouraged and just annoying). Again, a good installer script and {{Ic|.install}} file can work instead.<br />
<br />
Few examples of various strategies for obtaining files required for package:<br />
* {{AUR|worldofgoo}} &ndash; dependency on user-provided file<br />
* {{AUR|umineko-en}}{{Broken package link|{{aur-mirror|umineko-en}}}} &ndash; combining files from freely available patch and user-provided compact-disk<br />
* {{AUR|worldofgoo-demo}}{{Broken package link|{{aur-mirror|worldofgoo-demo}}}} &ndash; autonomic fetching installer during build phase<br />
* {{AUR|ut2004-anthology}}{{Broken package link|{{aur-mirror|ut2004-anthology}}}} &ndash; searching for disk via mountpoints<br />
<br />
== Advanced topics ==<br />
=== Custom DLAGENTS ===<br />
Some software authors aggressively protect their software from automatic downloading: ban certain "User-Agent" strings, create temporary links to files etc. You can still conveniently download this files by using {{Ic|DLAGENTS}} variable in PKGBUILD (see {{man|5|makepkg.conf}}). This is used by some packages in [[official repositories]], for example {{Pkg|ttf-baekmuk}}.<br />
<br />
Please pay attention, if you want to have a customized user-agent string, if the latter contains spaces, parentheses, or slashes in it (or actually anything that can break parsing), this will not work. There's no workaround, this is the nature of arrays in bash and the way DLAGENTS was designed to be consumed in makepkg. The following example will thus '''not work''':<br />
<br />
DLAGENTS=("http::/usr/bin/curl -A 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)' -fLC - --retry 3 --retry-delay 3 -o %o %u")<br />
<br />
Shorten it to the following which is working:<br />
<br />
DLAGENTS=("http::/usr/bin/curl -A 'Mozilla' -fLC - --retry 3 --retry-delay 3 -o %o %u")<br />
<br />
And following allows to extract temporary link to file from download page:<br />
<br />
DLAGENTS=("http::/usr/bin/wget -r -np -nd -H %u")<br />
<br />
=== Unpacking ===<br />
Many proprietary programs are shipped in nasty installers which sometimes do not even run in Wine. Following tools may be of some help:<br />
* {{Pkg|unzip}} and {{Pkg|unrar}} unpack executable SFX archives, based on this formats<br />
* {{Pkg|cabextract}} can unpack most {{Ic|.cab}} files (including ones with {{Ic|.exe}} extension)<br />
* {{Pkg|unshield}} can extract CAB files from InstallShield installers<br />
* {{Pkg|p7zip}} unpacks not only many archive formats but also [[Wikipedia:NSIS|NSIS]]-based {{Ic|.exe}} installers<br />
** it even can extract single sections from common PE ({{Ic|.exe}} & {{Ic|.dll}}) files!<br />
* {{Pkg|upx}} is sometimes used to compress above-listed executables and can be used for decompressing them as well<br />
* {{Pkg|innoextract}} can unpack {{Ic|.exe}} installers created with [[Wikipedia:Inno Setup|Inno Setup]] (used for example by GOG.com games)<br />
In order to determine exact type of file run {{Ic|file ''file_of_unknown_type''}}.<br />
<br />
=== Getting icons for .desktop files ===<br />
Proprietary software often have no separate icon files, so there is nothing to use in [[.desktop]] file creation. Happily {{Ic|.ico}} files can be easily extracted from executables with programs from {{Pkg|icoutils}} package. You can even do it on fly during {{Ic|build}} phase, for example:<br />
$ wrestool -x --output=''icon.ico'' -t14 ''executable.exe''</div>Calinouhttps://wiki.archlinux.org/index.php?title=PulseAudio/Troubleshooting&diff=528825PulseAudio/Troubleshooting2018-07-04T18:47:24Z<p>Calinou: /* Starting an application interrupts other app's sound */ Grammar fixes</p>
<hr />
<div>[[Category:Sound]]<br />
[[it:PulseAudio/Troubleshooting]]<br />
[[ja:PulseAudio/トラブルシューティング]]<br />
[[ru:PulseAudio/Troubleshooting]]<br />
See [[PulseAudio]] for the main article.<br />
<br />
== Volume ==<br />
<br />
Here you will find some hints on volume issues and why you may not hear anything.<br />
<br />
=== Auto-Mute Mode ===<br />
<br />
Auto-Mute Mode may be enabled. It can be disabled using {{ic|alsamixer}}.<br />
<br />
See http://superuser.com/questions/431079/how-to-disable-auto-mute-mode for more.<br />
<br />
To save your current settings as the default options, run {{ic|alsactl store}} as root.<br />
<br />
=== Muted audio device ===<br />
<br />
If one experiences no audio output via any means while using [[ALSA]], attempt to unmute the sound card. To do this, launch {{ic|alsamixer}} and make sure each column has a green {{ic|00}} under it (this can be toggled by pressing {{ic|m}}):<br />
<br />
$ alsamixer -c 0<br />
<br />
{{Note|alsamixer will not tell you which output device is set as the default. One possible cause of no sound after install is that PulseAudio detects the wrong output device as a default. Install {{Pkg|pavucontrol}} and check if there is any output on the pavucontrol panel when playing a ''.wav'' file.}}<br />
<br />
=== Output stuck muted while Master is toggled ===<br />
<br />
In setups with multiple outputs (e.g. 'Headphone' and 'Speaker') using plain amixer to toggle Master can trigger PulseAudio to mute the active output too, but it does not necessarily unmute it when Master is toggled back to be unmuted. [https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-December/025062.html] To resolve this, amixer must have the device flag set to 'pulse':<br />
<br />
$ amixer -D pulse sset Master toggle<br />
<br />
This will cause amixer to ask PulseAudio to do the toggling rather than toggling it directly.<br />
Because of this, PulseAudio will correctly unmute Master as well as any applicable output.<br />
<br />
=== Muted application ===<br />
<br />
If a specific application is muted or low while all else seems to be in order, it may be due to individual {{ic|sink-input}} settings. With the offending application playing audio, run:<br />
<br />
$ pacmd list-sink-inputs<br />
<br />
Find and make note of the {{ic|index}} of the corresponding {{ic|sink input}}. The {{ic|properties:}} {{ic|application.name}} and {{ic|application.process.binary}}, among others, should help here. Ensure sane settings are present, specifically those of {{ic|muted}} and {{ic|volume}}.<br />
If the sink is muted, it can be unmuted by:<br />
<br />
$ pacmd set-sink-input-mute <index> false<br />
<br />
If the volume needs adjusting, it can be set to 100% by:<br />
<br />
$ pacmd set-sink-input-volume <index> 0x10000<br />
<br />
{{Note|If {{ic|pacmd}} reports {{ic|0 sink input(s)}}, double-check that the application is playing audio. If it is still absent, verify that other applications show up as sink inputs.}}<br />
<br />
=== Volume adjustment does not work properly ===<br />
<br />
Check:<br />
{{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-output.conf.common}}<br />
<br />
If the volume does not appear to increment/decrement properly using {{ic|alsamixer}} or {{ic|amixer}}, it may be due to PulseAudio having a larger number of increments (65537 to be exact). Try using larger values when changing volume (e.g. {{ic|amixer set Master 655+}}).<br />
<br />
=== Per-application volumes change when the Master volume is adjusted ===<br />
<br />
This is because PulseAudio uses flat volumes by default, instead of relative volumes, relative to an absolute master volume. If this is found to be inconvenient, asinine, or otherwise undesireable, relative volumes can be enabled by disabling flat volumes in the PulseAudio daemon's configuration file:<br />
<br />
{{hc|/etc/pulse/daemon.conf or ~/.config/pulse/daemon.conf|<nowiki><br />
flat-volumes = no<br />
</nowiki>}}<br />
<br />
and then restarting PulseAudio by executing<br />
<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
=== Volume gets louder every time a new application is started ===<br />
<br />
Per default, it seems as if changing the volume in an application sets the global system volume to that level instead of only affecting the respective application. Applications setting their volume on startup will therefore cause the system volume to "jump".<br />
<br />
Fix this by disabling flat volumes, as demonstrated in the previous section. When Pulse comes back after a few seconds, applications will not alter the global system volume anymore but have their own volume level again.<br />
<br />
{{Note|A previously installed and removed pulseaudio-equalizer may leave behind remnants of the setup in {{ic|~/.config/pulse/default.pa}} or {{ic|~/.pulse/default.pa}} which can also cause maximized volume trouble. Comment that out as needed.}}<br />
<br />
=== Sound output is only mono on M-Audio Audiophile 2496 sound card ===<br />
<br />
Add the following:<br />
<br />
{{hc|/etc/pulseaudio/default.pa|<nowiki><br />
load-module module-alsa-sink sink_name=delta_out device=hw:M2496 format=s24le channels=10 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7<br />
load-module module-alsa-source source_name=delta_in device=hw:M2496 format=s24le channels=12 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,aux8,aux9<br />
set-default-sink delta_out<br />
set-default-source delta_in<br />
</nowiki>}}<br />
<br />
=== No sound below a volume cutoff ===<br />
<br />
Known issue (won't fix): https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/223133<br />
<br />
If sound does not play when PulseAudio's volume is set below a certain level, try setting {{ic|1=ignore_dB=1}} in {{ic|/etc/pulse/default.pa}}:<br />
{{hc|/etc/pulse/default.pa|<nowiki><br />
load-module module-udev-detect ignore_dB=1<br />
</nowiki>}}<br />
<br />
However, be aware that it may cause another bug preventing PulseAudio to unmute speakers when headphones or other audio devices are unplugged.<br />
<br />
=== Low volume for internal microphone ===<br />
<br />
If you experience low volume on internal notebook microphone, try setting:<br />
{{hc|/etc/pulse/default.pa|<nowiki><br />
set-source-volume 1 300000<br />
</nowiki>}}<br />
<br />
=== Clients alter master output volume (a.k.a. volume jumps to 100% after running application) ===<br />
<br />
If changing the volume in specific applications or simply running an application changes the master output volume this is likely due to flat volumes mode of pulseaudio. Before disabling it, KDE users should try lowering their system notifications volume in ''System Settings -> Application and System Notifications -> Manage Notifications'' under the ''Player Settings'' tab to something reasonable. Changing the ''Event Sounds'' volume in KMix or another volume mixer application will not help here. This should make the flat-volumes mode work out as intended, if it does not work, some other application is likely requesting 100% volume when its playing something. If all else fails, you can try to disable flat-volumes:<br />
<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
flat-volumes = no<br />
</nowiki>}}<br />
<br />
Then restart PulseAudio daemon:<br />
<br />
# pulseaudio -k<br />
# pulseaudio --start<br />
<br />
=== No sound after resume from suspend ===<br />
<br />
If audio generally works, but stops after resume from suspend, try "reloading" PulseAudio by executing:<br />
$ /usr/bin/pasuspender /bin/true<br />
<br />
This is better than completely killing and restarting it ({{ic|pulseaudio -k}} followed by {{ic|pulseaudio --start}}), because it does not break already running applications.<br />
<br />
If the above fixes your problem, you may wish to automate it, by creating a systemd service file.<br />
<br />
1. Create the template service file in {{ic|/etc/systemd/system/resume-fix-pulseaudio@.service}}:<br />
<br />
[Unit]<br />
Description=Fix PulseAudio after resume from suspend<br />
After=suspend.target<br />
<br />
[Service]<br />
User=%I<br />
Type=oneshot<br />
Environment="XDG_RUNTIME_DIR=/run/user/%U"<br />
ExecStart=/usr/bin/pasuspender /bin/true<br />
<br />
[Install]<br />
WantedBy=suspend.target<br />
<br />
2. Enable it for your user account<br />
<br />
# systemctl enable resume-fix-pulseaudio@YOUR_USERNAME_HERE.service<br />
<br />
3. Reload systemd<br />
<br />
# systemctl --system daemon-reload<br />
<br />
=== ALSA channels mute when headphones are plugged/unplugged improperly ===<br />
<br />
If when you unplug your headphones or plug them in the audio remains muted in alsamixer on the wrong channel due to it being set to 0%, you may be able to fix it by opening {{ic|/etc/pulse/default.pa}} and commenting out the line:<br />
<br />
load-module module-switch-on-port-available<br />
<br />
=== Volume resets to 50% every few seconds ===<br />
<br />
Install {{Pkg|alsa-tools}} and use:<br />
<br />
$ hdajackretask<br />
<br />
Set "Not Connected" to everything but the ports you are using. It seems the other unused audio ports on the motherboard interfere with the used ones.<br />
Then if you want use the Boot Override to save this change between reboots. There is a possibility it's the Front Green Headphone that's causing the bug, if you need it override the Front Microphone to Headphone and the Front Green Headphone to "Not Connected" and use the Front Microphone port as your headphone port.<br />
<br />
More info about this problem: [https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1585084].<br />
<br />
== Microphone ==<br />
<br />
=== Microphone not detected by PulseAudio ===<br />
<br />
Determine the card and device number of your mic:<br />
<br />
$ arecord -l<br />
**** List of CAPTURE Hardware Devices ****<br />
card 0: PCH [HDA Intel PCH], device 0: ALC269VC Analog [ALC269VC Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
<br />
In hw:CARD,DEVICE notation, you would specify the above device as {{ic|hw:0,0}}.<br />
<br />
Then, edit {{ic|/etc/pulse/default.pa}} and insert a {{ic|load-module}} line specifying your device as follows:<br />
<br />
load-module module-alsa-source device=hw:0,0<br />
# the line above should be somewhere before the line below<br />
.ifexists module-udev-detect.so<br />
<br />
Finally, restart pulseaudio to apply the new settings:<br />
<br />
$ pulseaudio -k ; pulseaudio -D<br />
<br />
If everything worked correctly, you should now see your mic show up when running {{ic|pavucontrol}} (under the {{ic|Input Devices}} tab).<br />
<br />
=== PulseAudio uses wrong microphone ===<br />
<br />
If PulseAudio uses the wrong microphone, and changing the Input Device with Pavucontrol did not help, take a look at alsamixer. It seems that Pavucontrol does not always set the input source correctly.<br />
<br />
$ alsamixer<br />
<br />
Press {{ic|F6}} and choose your sound card, e.g. HDA Intel. Now press {{ic|F5}} to display all items. Try to find the item: {{ic|Input Source}}. With the up/down arrow keys you are able to change the input source.<br />
<br />
Now try if the correct microphone is used for recording.<br />
<br />
=== No microphone on ThinkPad T400/T500/T420 ===<br />
<br />
Run:<br />
<br />
alsamixer -c 0<br />
<br />
Unmute and maximize the volume of the "Internal Mic".<br />
<br />
Once you see the device with:<br />
<br />
arecord -l<br />
<br />
you might still need to adjust the settings. The microphone and the audio jack are duplexed. Set the configuration of the internal audio in pavucontrol to ''Analog Stereo Duplex''.<br />
<br />
=== No microphone input on Acer Aspire One ===<br />
<br />
Install pavucontrol, unlink the microphone channels and turn down the left one to 0.<br />
<br />
=== Static noise in microphone recording ===<br />
<br />
If we are getting static noise in Skype, gnome-sound-recorder, arecord, etc.'s recordings, then the sound card sample rate is incorrect. That is why there is static noise in Linux microphone recordings. To fix this, we need to set the sampling rate in {{ic|/etc/pulse/daemon.conf}} for the sound hardware.<br />
<br />
In addition to the guide below, since [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ PulseAudio 11] it is possible to set {{ic|1=avoid-resampling = yes}} in [[PulseAudio#daemon.conf|daemon.conf]].<br />
<br />
==== Determine sound cards in the system (1/5) ====<br />
<br />
This requires {{Pkg|alsa-utils}} and related packages to be installed:<br />
{{hc|$ arecord --list-devices|<br />
**** List of CAPTURE Hardware Devices ****<br />
card 0: Intel [HDA Intel], device 0: ALC888 Analog [ALC888 Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 0: Intel [HDA Intel], device 2: ALC888 Analog [ALC888 Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
}}<br />
<br />
Sound card is {{ic|hw:0,0}}.<br />
<br />
==== Determine sampling rate of the sound card (2/5) ====<br />
<br />
We aim to find the highest sample rate supported by the {{ic|hw:0,0}} sound card using a ''trial-and-error'' procedure starting from a low value. When the top value is reached, we got a warning message:<br />
<br />
{{hc|1=arecord -f dat -r 60000 -D hw:0,0 -d 5 test.wav|2=<br />
"Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 60000 Hz, Stereo<br />
Warning: rate is not accurate (requested = 60000Hz, '''got = 44100Hz''')<br />
please, try the plug plugin<br />
}}<br />
<br />
observe, the {{ic|1=got = 44100Hz}}. This is the maximum sampling rate of our card.<br />
<br />
==== Setting the sound card's sampling rate into PulseAudio configuration (3/5) ====<br />
<br />
The default sampling rate in PulseAudio:<br />
{{hc|1=$ grep "default-sample-rate" /etc/pulse/daemon.conf|2=<br />
; default-sample-rate = 48000<br />
}}<br />
<br />
{{ic|48000}} is disabled and needs to be changed to {{ic|44100}}:<br />
# sed 's/; default-sample-rate = 48000/default-sample-rate = 44100/g' -i /etc/pulse/daemon.conf<br />
<br />
==== Restart PulseAudio to apply the new settings (4/5) ====<br />
<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
==== Finally check by recording and playing it back (5/5) ====<br />
<br />
Let us record some voice using a microphone for, say, 10 seconds. Make sure the microphone is not muted and all<br />
<br />
$ arecord -f cd -d 10 test-mic.wav<br />
<br />
After 10 seconds, let us play the recording...<br />
<br />
$ aplay test-mic.wav<br />
<br />
Now hopefully, there is no static noise in microphone recording anymore.<br />
<br />
==== Another Possible Cause ====<br />
<br />
Another possible cause is that your mic has two channels but only one channel can provide a valid sound signal. Some information can be found [https://github.com/MaartenBaert/ssr/issues/323#issuecomment-268230548 here]. The solution is to remap the stereo input to a mono input:<br />
<br />
1. Find your source name from the following command; mine is {{ic|alsa_input.pci-0000_00_1f.3.analog-stereo}}<br />
<br />
pacmd list-sources | grep 'name:.*input'<br />
<br />
2. Edit {{ic|/etc/pulse/default.pa}} and add the following lines, where INPUT_NAME is name of the input source from above step:<br />
<br />
load-module module-remap-source source_name=record_mono master=INPUT_NAME master_channel_map=front-left channel_map=mono<br />
set-default-source record_mono<br />
<br />
3. Restart PulseAudio:<br />
<br />
pulseaudio -k<br />
pulseaudio --start<br />
<br />
Now {{ic|arecord}} hopefully works. You may still need to change the {{ic|RecordStream from}} setting to {{ic|Remapped Built-in Audio Analog Stereo}} of a specific application in the {{ic|Recording}} tab of {{ic|pavucontrol}}.<br />
<br />
==== If using a USB microphone ====<br />
<br />
Try plugging it into a different port (eg: ports at the back rather than front).<br />
<br />
=== No microphone on Steam or Skype with enable-remixing = no ===<br />
<br />
When you set {{ic|1=enable-remixing = no}} on {{ic|/etc/pulse/daemon.conf}} you may find that your microphone has stopped working on certain applications like Skype or Steam. This happens because these applications capture the microphone as mono only and because remixing is disabled, Pulseaudio will no longer remix your stereo microphone to mono.<br />
<br />
To fix this you need to tell Pulseaudio to do this for you:<br />
<br />
1. Find the name of the source <br />
<br />
# pacmd list-sources<br />
<br />
Example output edited for brevity, the name you need is in bold:<br />
<br />
index: 2<br />
name: <'''alsa_input.pci-0000_00_14.2.analog-stereo'''><br />
driver: <module-alsa-card.c><br />
flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY<br />
<br />
2. Add a remap rule to {{ic|/etc/pulse/default.pa}}, use the name you found with the previous command, here we will use '''alsa_input.pci-0000_00_14.2.analog-stereo''' as an example:<br />
<br />
{{hc|/etc/pulse/default.pa|<nowiki><br />
### Remap microphone to mono<br />
load-module module-remap-source master=alsa_input.pci-0000_00_14.2.analog-stereo master_channel_map=front-left,front-right channels=2 channel_map=mono,mono<br />
</nowiki>}}<br />
<br />
3. Restart Pulseaudio<br />
<br />
# pulseaudio -k<br />
<br />
{{Note|Pulseaudio may fail to start if you do not exit a program that was using the microphone (e.g. if you tested on Steam before modifying the file), in which case you should exit the application and manually start Pulseaudio}}<br />
<br />
# pulseaudio --start<br />
<br />
=== Microphone distorted due to automatic adjustment ===<br />
If your microphone volume creeps up automatically and causes the sound to be distorted, you can fix it by disabling mic boost:<br />
<br />
In {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-internal-mic.conf}} and {{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-input-mic.conf}},<br />
<br />
* Under {{ic|[Element Internal Mic Boost]}} set {{ic|volume}} to {{ic|zero}}.<br />
* Under {{ic|[Element Int Mic Boost]}} set {{ic|volume}} to {{ic|zero}}.<br />
* Under {{ic|[Element Mic Boost]}} set {{ic|volume}} to {{ic|zero}}.<br />
<br />
Then restart PulseAudio:<br />
<br />
# pulseaudio -k<br />
<br />
=== Microphone crackling with Realtek ALC892 ===<br />
Sometimes ALC892 chips have crackling sound while recording using a microphone. Some Pulseaudio config changes may help:<br />
<br />
{{hc|head=/etc/pulse/daemon.conf|output=<br />
resample-method = src-sinc-best-quality<br />
default-sample-format = s16le<br />
default-sample-rate = 48000<br />
}}<br />
<br />
and add the {{ic|use_ucm}} option to<br />
<br />
{{hc|head=/etc/pulse/default.conf|output=<br />
load-module module-udev-detect use_ucm=0 tsched=0<br />
}}<br />
<br />
then restart pulseaudio.<br />
<br />
== Audio quality ==<br />
<br />
=== Enable Echo/Noise-Cancellation ===<br />
<br />
Arch does not load the Pulseaudio Echo-Cancellation module by default, therefore, we have to add it in {{ic|/etc/pulse/default.pa}}. First you can test if the module is present with {{ic|pacmd}} and entering {{ic|list-modules}}. If you cannot find a line showing {{ic|name: <module-echo-cancel>}} you have to add <br />
<br />
{{hc|/etc/pulse/default.pa|<br />
### Enable Echo/Noise-Cancellation<br />
<nowiki>load-module module-echo-cancel use_master_format=1 aec_method=webrtc aec_args="analog_gain_control=0 digital_gain_control=1" source_name=echoCancel_source sink_name=echoCancel_sink</nowiki><br />
set-default-source echoCancel_source<br />
set-default-sink echoCancel_sink<br />
}}<br />
<br />
then restart Pulseaudio<br />
<br />
pulseaudio -k<br />
pulseaudio --start<br />
<br />
and check if the module is activated by starting {{ic|pavucontrol}}. Under {{ic|Recoding}} the input device should show {{ic|Echo-Cancel Source Stream from"}}<br />
<br />
<br />
Here is a list of possible 'aec_args' for 'aec_method=webrtc' with their default values [https://github.com/pulseaudio/pulseaudio/blob/master/src/modules/echo-cancel/webrtc.cc][https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index45h3]:<br />
<br />
* {{ic|1=analog_gain_control=1}} - Analog AGC - 'Automatic Gain Control' done over changing the volume directly - Will most likely lead to [[#Microphone distorted due to automatic adjustment|distortions]].<br />
* {{ic|1=digital_gain_control=0}} - Digital AGC - 'Automatic Gain Control' done in post processing (higher CPU load).<br />
* {{ic|1=experimental_agc=0}} - Allow enabling of the webrtc experimental AGC mechanism.<br />
* {{ic|1=agc_start_volume=85}} - Initial volume when using AGC - Possible values 0-255 - A too low initial volume may prevent the AGC algorithm from ever raising the volume high enough [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/9.0/].<br />
* {{ic|1=high_pass_filter=1}} - ?<br />
* {{ic|1=noise_suppression=1}} - Noise suppression.<br />
* {{ic|1=voice_detection=1}} - VAD - Voice activity detection.<br />
* {{ic|1=extended_filter=0}} - The extended filter is more complex and less sensitive to incorrect delay reporting from the hardware than the regular filter. The extended filter mode is disabled by default, because it seemed produce worse results during double-talk [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/9.0/].<br />
* {{ic|1=intelligibility_enhancer=0}} - Some bits for webrtc intelligibility enhancer.<br />
* {{ic|1=drift_compensation=0}} - Drift compensation to allow echo cancellation between different devices (such as speakers on your laptop and the microphone on your USB webcam). - only possible with "mobile=0".<br />
* {{ic|1=beamforming=0}} - See [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#index45h3][https://arunraghavan.net/2016/06/beamforming-in-pulseaudio/]<br />
** {{ic|1=mic_geometry=x1,y1,z1,x2,y2,z2}} - Only with "beamforming=1".<br />
** {{ic|1=target_direction=a,e,r}} - Only with "beamforming=1".<br />
* {{ic|1=mobile=0}} - ?<br />
** {{ic|1=routing_mode=speakerphone}} - Possible Values "quiet-earpiece-or-headset,earpiece,loud-earpiece,speakerphone,loud-speakerphone" - only valid with "mobile=1".<br />
** {{ic|1=comfort_noise=1}} - ? - only valid with "mobile=1".<br />
<br />
<br />
<br />
If you are using the [[#Enable Echo.2FNoise-Cancellation|module-echo-cancel]], you probably don't want other applications to do additional audio post processing.<br><br />
Here is a list for disabling audio post processing in following applications:<br />
<br />
* Mumble:<br><br />
# Configure -> Settings -> Check 'Advanced' check box -> Audio Input<br><br />
# Echo: Select 'Disabled'<br><br />
# Noise Suppression: Set slider to 'Off'<br><br />
# Max. Aplification: Set slider to '1.0'<br />
<br />
* TeamSpeak:<br><br />
# Tools -> Options -> Check 'Advanced Options' check box<br><br />
# Uncheck: 'Echo reduction', 'Echo cancellation', 'Remove background noise' and 'Automatic voice gain control'<br />
<br />
* Firefox:<br><br />
#Is described [[Firefox_tweaks#Disable_WebRTC_audio_post_processing|here]]<br />
<br />
<br />
BEWARE:<br><br />
If you plug in a USB Soundcard/Headset, or you have for example a 5.1 Speaker configuration and plug in a Headset on your front audio connectors after you have loaded the 'module-echo-cancel', you have to manually unload and load the 'module-echo-cancel' again, because unfortunately there is no way to tell the 'module-echo-cancel' that it should automatically switch to the new default 'source_master' and 'source_sink'. See https://bugs.freedesktop.org/show_bug.cgi?id=100403<br />
<br />
=== Glitches, skips or crackling ===<br />
<br />
The newer implementation of the PulseAudio sound server uses timer-based audio scheduling instead of the traditional, interrupt-driven approach. <br />
<br />
Timer-based scheduling may expose issues in some ALSA drivers. On the other hand, other drivers might be glitchy without it on, so check to see what works on your system. <br />
<br />
To turn timer-based scheduling off add {{ic|1=tsched=0}} in {{ic|/etc/pulse/default.pa}}:<br />
{{hc|/etc/pulse/default.pa|2=<br />
load-module module-udev-detect tsched=0<br />
}}<br />
<br />
Then restart the PulseAudio server:<br />
<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
Do the reverse to enable timer-based scheduling, if not already enabled by default.<br />
<br />
If you are using Intel's [[Wikipedia:IOMMU|IOMMU]] and experience glitches and/or skips, add {{ic|1=intel_iommu=igfx_off}} to your kernel command line.<br />
<br />
Some Intel audio cards using the {{ic|snd-hda-intel}} module need the otions {{ic|1=vid=8086 pid=8ca0 snoop=0}}. In order to set them permanently, create/modify the following file including the line below.<br />
{{hc|/etc/modprobe.d/sound.conf|2=<br />
options snd-hda-intel vid=8086 pid=8ca0 snoop=0<br />
}}<br />
<br />
Please report any such cards to [http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/BrokenDrivers/ PulseAudio Broken Sound Driver page]<br />
<br />
=== Static noise when using headphones ===<br />
<br />
If you are encountering static in your headphone jack, one possible culprit may be ALSA's loopback mixing. In addition to setting tsched=0 as documented above, it may be helpful to disable loopback mixing. This can be accomplished trivially with alsamixer, part of {{Pkg|alsa-utils}}. This should not impact audio playback or microphone recording negatively, unless you require loopback mixing.<br />
<br />
=== Setting the default fragment number and buffer size in PulseAudio ===<br />
<br />
{{Style|Copied from Linux mint topic with few additions}}<br />
<br />
==== Disabling timer-based scheduling (0/4) ====<br />
<br />
By default, PulseAudio uses timer-based scheduling. In this mode, fragments are not used at all, and so the default-fragments and default-fragment-size-msec parameters are ignored.<br />
To turn timer-based scheduling off add {{ic|1=tsched=0}} in {{ic|/etc/pulse/default.pa}}:<br />
{{hc|/etc/pulse/default.pa|2=<br />
load-module module-udev-detect tsched=0<br />
}}<br />
<br />
==== Finding out your audio device parameters (1/4) ====<br />
<br />
To find out what your sound card buffering settings are, use the following command and scroll through the output until you find the correct sink entry.<br />
<br />
{{hc|$ pactl list sinks|<nowiki><br />
Sink #1<br />
State: RUNNING<br />
Name: alsa_output.pci-0000_00_1b.0.analog-stereo<br />
Description: Built-in Audio Analog Stereo<br />
Driver: module-alsa-card.c<br />
Sample Specification: s16le 2ch 44100Hz<br />
Channel Map: front-left,front-right<br />
Owner Module: 7<br />
Mute: no<br />
Volume: front-left: 42600 / 65% / -11.22 dB, front-right: 42600 / 65% / -11.22 dB<br />
balance 0.00<br />
Base Volume: 65536 / 100% / 0.00 dB<br />
Monitor Source: alsa_output.pci-0000_00_1b.0.analog-stereo.monitor<br />
Latency: 70662 usec, configured 85000 usec<br />
Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY <br />
Properties:<br />
alsa.resolution_bits = "16"<br />
device.api = "alsa"<br />
device.class = "sound"<br />
alsa.class = "generic"<br />
alsa.subclass = "generic-mix"<br />
alsa.name = "ALC283 Analog"<br />
alsa.id = "ALC283 Analog"<br />
alsa.subdevice = "0"<br />
alsa.subdevice_name = "subdevice #0"<br />
alsa.device = "0"<br />
alsa.card = "1"<br />
alsa.card_name = "HDA Intel PCH"<br />
alsa.long_card_name = "HDA Intel PCH at 0xe111c000 irq 43"<br />
alsa.driver_name = "snd_hda_intel"<br />
device.bus_path = "pci-0000:00:1b.0"<br />
sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card1"<br />
device.bus = "pci"<br />
device.vendor.id = "8086"<br />
device.vendor.name = "Intel Corporation"<br />
device.product.id = "9ca0"<br />
device.product.name = "Wildcat Point-LP High Definition Audio Controller"<br />
device.form_factor = "internal"<br />
device.string = "front:1"<br />
device.buffering.buffer_size = "352800"<br />
device.buffering.fragment_size = "176400"<br />
device.access_mode = "mmap+timer"<br />
device.profile.name = "analog-stereo"<br />
device.profile.description = "Analog Stereo"<br />
device.description = "Built-in Audio Analog Stereo"<br />
alsa.mixer_name = "Realtek ALC283"<br />
alsa.components = "HDA:10ec0283,10ec0283,00100003"<br />
module-udev-detect.discovered = "1"<br />
device.icon_name = "audio-card-pci"<br />
Ports:<br />
analog-output-speaker: Speakers (priority: 10000, not available)<br />
analog-output-headphones: Headphones (priority: 9000, available)<br />
Active Port: analog-output-headphones<br />
Formats:<br />
pcm<br />
...<br />
</nowiki>}}<br />
<br />
Take note the {{ic|buffer_size}} and {{ic|fragment_size}} values for the relevant sound card.<br />
<br />
==== Calculate your fragment size in msecs and number of fragments (2/4) ====<br />
<br />
PulseAudio's default sampling rate and bit depth are set to {{ic|44100Hz}} @ {{ic|16 bits}}.<br />
<br />
With this configuration, the bit rate we need is {{ic|44100}}*{{ic|16}} = {{ic|705600}} bits per second. That is {{ic|1411200 bps}} for stereo.<br />
<br />
Let us take a look at the parameters we have found in the previous step:<br />
<br />
device.buffering.buffer_size = "352800" => 352800/1411200 = 0.25 s = 250 ms<br />
device.buffering.fragment_size = "176400" => 176400/1411200 = 0.125 s = 125 ms<br />
<br />
==== Modify PulseAudio's configuration file (3/4) ====<br />
<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
; default-fragments = X<br />
; default-fragment-size-msec = Y<br />
</nowiki>}}<br />
<br />
In the previous step, we calculated the fragment size parameter.<br />
The number of fragments is simply buffer_size/fragment_size, which in this case ({{ic|250/125}}) is {{ic|2}}:<br />
<br />
{{hc|/etc/pulse/daemon.conf|2=<br />
; default-fragments = '''2'''<br />
; default-fragment-size-msec = '''125'''<br />
}}<br />
<br />
==== Restart the PulseAudio daemon (4/4) ====<br />
<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
For more information, see: [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 Linux Mint topic]<br />
<br />
=== Choppy sound with analog surround sound setup ===<br />
<br />
The low-frequency effects (LFE) or Subwoofer channel is not remixed per default. To enable it the following needs to be set in {{ic|/etc/pulse/daemon.conf}} :<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
enable-lfe-remixing = yes<br />
</nowiki>}}<br />
<br />
You should also consider to set a proper crossover frequency for the LFE- channel.<br />
The crossover frequency is the frequency up to which the audio signal is rerouted to the LFE sink.<br />
The optimal crossover frequency in Hz depends on the size of all your speakers.<br />
<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
lfe-crossover-freq = <40-200><br />
</nowiki>}}<br />
<br />
=== Laggy sound ===<br />
<br />
This issue is due to incorrect buffer sizes. First verify that the variables {{ic|default-fragments}} and {{ic|default-fragment-size-msec}} are not being set to non default values in the file {{ic|/etc/pulse/daemon.conf}}. If the issue is still present, try setting them to the following values:<br />
<br />
{{hc|/etc/pulse/daemon.conf|2=<br />
default-fragments = 5<br />
default-fragment-size-msec = 2<br />
}}<br />
<br />
=== Choppy/distorted sound ===<br />
This can result from an incorrectly set sample rate. Try the following setting:<br />
<br />
{{hc|/etc/pulse/daemon.conf|2=<br />
avoid-resampling = yes #(Needs [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ PA11] or higher)<br />
default-sample-rate = 48000<br />
}}<br />
and restart the PulseAudio server.<br />
<br />
If one experiences choppy sound in applications using [[Wikipedia:OpenAL|OpenAL]], change the sample rate in {{ic|/etc/openal/alsoft.conf}}:<br />
{{hc|/etc/openal/alsoft.conf|2=<br />
frequency = 48000<br />
}}<br />
<br />
Setting the PCM volume above 0 dB can cause [[Wikipedia:Clipping_(audio)|clipping]]. Running {{ic|alsamixer}} will allow you to see if this is the problem and if so fix it. Note that ALSA may not [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PulseAudioStoleMyVolumes/ correctly export] the dB information to PulseAudio. Try the following:<br />
<br />
{{hc|/etc/pulse/default.pa|2=<br />
load-module module-udev-detect ignore_dB=1<br />
}}<br />
<br />
and restart the PulseAudio server. See also [[#No sound below a volume cutoff]].<br />
<br />
=== Sound stuttering when streaming over network ===<br />
When streaming over Wi-Fi using module-native-protocol-tcp you can experience periodic sound stuttering with buffer underruns. As a workaround you can try to use rtp protocol. On sender side create rtp sink:<br />
<br />
{{hc|/etc/pulse/default.pa|2=<br />
load-module module-null-sink sink_name=rtp<br />
load-module module-rtp-send source=rtp.monitor<br />
}}<br />
<br />
and switch to it:<br />
<br />
{{hc|/etc/pulse/default.pa|2=<br />
set-default-sink rtp<br />
}}<br />
<br />
On receiver side load rtp module:<br />
<br />
{{hc|/etc/pulse/default.pa|2=<br />
load-module module-rtp-recv<br />
}}<br />
<br />
== Hardware and Cards ==<br />
<br />
=== No HDMI sound output after some time with the monitor turned off ===<br />
<br />
The monitor is connected via HDMI/DisplayPort, and the audio jack is plugged in the headphone jack of the monitor, but PulseAudio insists that it is unplugged:<br />
<br />
{{hc|pactl list sinks|<br />
...<br />
hdmi-output-0: HDMI / DisplayPort (priority: 5900, not available)<br />
...<br />
}}<br />
<br />
This leads to no sound coming from HDMI output. A workaround for this is to switch to another VT and back again. If that does not work, try: turn off your monitor, switch to another VT, turn on your monitor, and switch back. This problem has been reported by ATI/Nvidia/Intel users.<br />
<br />
Another workaround could be to disable the switch-on-port-available module by commenting it in /etc/pulse/default.pa [https://bugs.freedesktop.org/show_bug.cgi?id=93946#c36]:<br />
<br />
{{hc|/etc/pulse/default.pa|<br />
...<br />
### Should be after module-*-restore but before module-*-detect<br />
#load-module module-switch-on-port-available<br />
...<br />
}}<br />
<br />
=== No HDMI sound using a headless server ===<br />
You might want to use HDMI audio with your a/v receiver but no display. HDMI requires a video signal, which we have from the virtual terminal. <br />
<br />
By default, this signal is turned off after 600 seconds, thus the audio sink gets lost as well.<br />
<br />
To prevent screen blanking, add {{ic|consoleblank&#61;0}} to the kernel command line.<br />
<br />
=== No cards ===<br />
<br />
If PulseAudio starts, run {{ic|pacmd list}}. If no cards are reported, make sure that the ALSA devices are not in use:<br />
<br />
$ fuser -v /dev/snd/*<br />
$ fuser -v /dev/dsp<br />
<br />
Make sure any applications using the pcm or dsp files are shut down before restarting PulseAudio.<br />
<br />
=== Starting an application interrupts other app's sound ===<br />
<br />
If you have trouble with some applications (such as TeamSpeak or Mumble) interrupting sound output of already running applications (such as Deadbeaf), you can solve this by commenting out the line {{ic|load-module module-role-cork}} in {{ic|/etc/pulse/default.pa}} like shown below:<br />
<br />
{{hc|/etc/pulse/default.pa|<br />
### Cork music/video streams when a phone stream is active<br />
# load-module module-role-cork<br />
}}<br />
<br />
Then restart pulseaudo by using your normal user account with<br />
<br />
pulseaudio -k<br />
pulseaudio --start<br />
<br />
=== The only device shown is "dummy output" or newly connected cards are not detected ===<br />
<br />
If the only playback device is the Dummy Output, PulseAudio cannot access your sound devices. It is possible there is an issue with logind giving permissions, see [[General troubleshooting#Session permissions]] for more information.<br />
<br />
An application might also not have been configured to work with PulseAudio. This happens with [[FluidSynth#Conflicting_with_PulseAudio|FluidSynth]] for example. To see which application is responsible for a direct access to the sound card via alsa, run the following command:<br />
<br />
# fuser -v /dev/snd/*<br />
<br />
Try to close these applications. pulseaudio, if running, should take again precedence over these applications and all the applications relying on pulseaudio should work again like expected.<br />
<br />
=== No HDMI 5/7.1 Selection for Device ===<br />
<br />
If you are unable to select 5/7.1 channel output for a working HDMI device, then turning off "stream device reading" in {{ic|/etc/pulse/default.pa}} might help. <br />
<br />
See [[#Fallback device is not respected]].<br />
<br />
=== Failed to create sink input: sink is suspended ===<br />
<br />
If you do not have any output sound and receive dozens of errors related to a suspended sink in your {{ic|journalctl -b}} log, then backup first and then delete your user-specific pulse folders:<br />
<br />
$ rm -r ~/.pulse ~/.pulse-cookie ~/.config/pulse<br />
<br />
=== Simultaneous output to multiple sound cards / devices ===<br />
<br />
Simultaneous output to two different devices can be very useful. For example, being able to send audio to your A/V receiver via your graphics card's HDMI output, while also sending the same audio through the analogue output of your motherboard's built-in audio. This is much less hassle than it used to be (in this example, we are using GNOME desktop).<br />
<br />
Using {{Pkg|paprefs}}, simply select "Add virtual output device for simultaneous output on all local sound cards" from under the "Simultaneous Output" tab. Then, under GNOME's "sound settings", select the simultaneous output you have just created.<br />
<br />
If this does not work, try adding the following to {{ic|~/.asoundrc}}:<br />
<br />
pcm.dsp {<br />
type plug<br />
slave.pcm "dmix"<br />
}<br />
<br />
{{Tip|Simultaneous output can also be achieved manually using alsamixer. Disable "auto mute" item, then unmute other output sources you want to hear and increase their volume.}}<br />
<br />
=== Simultaneous output to multiple sinks on the same sound card not working ===<br />
<br />
This can be useful for users who have multiple sound sources and want to play them on different sinks/outputs. <br />
An example use-case for this would be if you play music and also voice chat and want to output music to speakers (in this case Digital S/PDIF) and voice to headphones. (Analog)<br />
<br />
This is sometimes auto detected by PulseAudio but not always. If you know that your sound card can output to both Analog and S/PDIF at the same time and PulseAudio does not have this option in its profiles in pavucontrol, or veromix then you probably need to create a configuration file for your sound card.<br />
<br />
More in detail you need to create a profile-set for your specific sound card.<br />
This is done in two steps mostly.<br />
* Create udev rule to make PulseAudio choose your PulseAudio configuration file specific to the sound card.<br />
* Create the actual configuration.<br />
<br />
Create a pulseadio udev rule.<br />
<br />
{{Note|This is only an example for Asus Xonar Essence STX.<br />
Read [[udev]] to find out the correct values.}}<br />
<br />
{{Note|Your configuration file should have lower number than the original PulseAudio rule to take effect.}}<br />
<br />
{{hc|/usr/lib/udev/rules.d/90-pulseaudio-Xonar-STX.rules|<br />
ACTION&#61;&#61;"change", SUBSYSTEM&#61;&#61;"sound", KERNEL&#61;&#61;"card*", \<br />
ATTRS&#123;subsystem_vendor&#125;&#61;&#61;"0x1043", ATTRS&#123;subsystem_device&#125;&#61;&#61;"0x835c", ENV&#123;PULSE_PROFILE_SET&#125;&#61;"asus-xonar-essence-stx.conf" <br />
}}<br />
<br />
Now, create a configuration file. If you bother, you can start from scratch and make it saucy. However you can also use the default configuration file, rename it, and then add your profile there that you know works. Less pretty but also faster.<br />
<br />
To enable multiple sinks for Asus Xonar Essence STX you need only to add this in.<br />
<br />
{{Note|{{ic|asus-xonar-essence-stx.conf}} also includes all code/mappings from {{ic|default.conf}}.}}<br />
<br />
{{hc|/usr/share/pulseaudio/alsa-mixer/profile-sets/asus-xonar-essence-stx.conf|<br />
[Profile analog-stereo+iec958-stereo]<br />
description &#61; Analog Stereo Duplex + Digital Stereo Output<br />
input-mappings &#61; analog-stereo<br />
output-mappings &#61; analog-stereo iec958-stereo<br />
skip-probe &#61; yes<br />
}}<br />
<br />
This will auto-profile your Asus Xonar Essence STX with default profiles and add your own profile so you can have multiple sinks.<br />
<br />
You need to create another profile in the configuration file if you want to have the same functionality with AC3 Digital 5.1 output.<br />
<br />
[http://www.freedesktop.org/wiki/Software/PulseAudio/Backends/ALSA/Profiles/ See PulseAudio article about profiles]<br />
<br />
=== Some profiles like SPDIF are not enabled by default on the card ===<br />
<br />
Some profiles like IEC-958 (i.e. S/PDIF) may not be enabled by default on the selected sink. Each time the system starts up, the card profile is disabled and the pulseaudio daemon cannot select it.<br />
You have to add the profile selection to you default.pa file. <br />
Verify the card and profile name with :<br />
<br />
$ pacmd list-cards<br />
Then edit the config to add the profile<br />
{{hc|~/.config/pulse/default.pa|<br />
## Replace with your card name and the profile you want to activate<br />
set-card-profile alsa_card.pci-0000_00_1b.0 output:iec958-stereo+input:analog-stereo<br />
}}<br />
<br />
Pulse audio will add this profile the pool of available profiles<br />
<br />
=== Only S/PDIF output available ===<br />
<br />
This might happen if PulseAudio use the wrong output device. Firstly, set up proper card profile:<br />
<br />
$ pacmd set-card-profile alsa_card.pci-0000_00_1f.3 output:analog-stereo<br />
<br />
or<br />
<br />
$ pacmd set-card-profile alsa_card.pci-0000_00_1f.3 output:analog-stereo+input:analog-stereo<br />
<br />
Replace {{ic|alsa_card.pci-0000_00_1f.3}} with your card, and {{ic|output:analog-stereo}} or {{ic|output:analog-stereo+input:analog-stereo}} with your profile, remember to choose the profile with analog. Using shell auto completion could help you a lot. One could also use check available cards and profiles with:<br />
<br />
$ pacmd list-cards<br />
<br />
One might also need to set sink port by:<br />
<br />
$ pacmd set-sink-port alsa_output.pci-0000_00_1f.3.analog-stereo analog-output-headphones<br />
<br />
Check available sink ports with:<br />
<br />
$ pacmd list-sinks<br />
<br />
To keep these setting, add them to PulseAudio's configuration file {{ic|default.pa}}.<br />
<br />
{{hc|~/.config/pulse/default.pa|<br />
.include /etc/pulse/default.pa<br />
<br />
set-card-profile alsa_card.pci-0000_00_1f.3 output:analog-stereo+input:analog-stereo<br />
set-sink-port alsa_output.pci-0000_00_1f.3.analog-stereo analog-output-headphones<br />
}}<br />
<br />
== Bluetooth ==<br />
<br />
=== Disable Bluetooth support ===<br />
<br />
If you do not use Bluetooth, you may experience the following error in your journal:<br />
<br />
bluez5-util.c: GetManagedObjects() failed: org.freedesktop.DBus.Error.ServiceUnknown: The name org.bluez was not provided by any .service files<br />
<br />
To disable Bluetooth support in PulseAudio, make sure that the following lines are commented out in the configuration file in use ({{ic|~/.config/pulse/default.pa}} or {{ic|/etc/pulse/default.pa}}):<br />
<br />
{{hc|~/.config/pulse/default.pa|<br />
### Automatically load driver modules for Bluetooth hardware<br />
#.ifexists module-bluetooth-policy.so<br />
#load-module module-bluetooth-policy<br />
#.endif<br />
<br />
#.ifexists module-bluetooth-discover.so<br />
#load-module module-bluetooth-discover<br />
#.endif<br />
}}<br />
<br />
=== Bluetooth headset replay problems ===<br />
<br />
Some user [https://bbs.archlinux.org/viewtopic.php?id=117420 reports] huge delays or even no sound when the Bluetooth connection does not send any data. This is due to the {{ic|module-suspend-on-idle}} module, which automatically suspends sinks/sources on idle. As this can cause problems with headset, the responsible module can be deactivated.<br />
<br />
To disable loading of the {{ic|module-suspend-on-idle}} module, comment out the following line in the configuration file in use ({{ic|~/.config/pulse/default.pa}} or {{ic|/etc/pulse/default.pa}}):<br />
<br />
{{hc|~/.config/pulse/default.pa|<br />
### Automatically suspend sinks/sources that become idle for too long<br />
#load-module module-suspend-on-idle<br />
}}<br />
<br />
Finally restart PulseAudio to apply the changes.<br />
<br />
=== Automatically switch to Bluetooth or USB headset ===<br />
<br />
Add the following:<br />
{{hc|/etc/pulse/default.pa|<br />
# automatically switch to newly-connected devices<br />
load-module module-switch-on-connect<br />
}}<br />
<br />
Since [https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/ PulseAudio 11] USB and bluetooth devices are preferred over internal sound cards by default, but as in the above link described, you still need module-switch-on-connect to also moves existing streams to the new sink.<br />
<br />
=== My Bluetooth device is paired but does not play any sound ===<br />
<br />
[[Bluetooth headset#A2DP_not_working_with_PulseAudio|See the article in Bluetooth headset section]]<br />
<br />
Starting from PulseAudio 2.99 and bluez 4.101 you should '''avoid''' using Socket interface. Do NOT use:<br />
<br />
{{hc|/etc/bluetooth/audio.conf|<nowiki><br />
[General]<br />
Enable=Socket<br />
</nowiki>}}<br />
<br />
If you face problems with A2DP and PA 2.99 make sure you have {{Pkg|sbc}} library.<br />
<br />
== Applications ==<br />
<br />
=== Flash content ===<br />
<br />
Since Adobe Flash does not directly support PulseAudio, the recommended way is to [[PulseAudio#ALSA|configure ALSA to use the virtual PulseAudio sound card]].<br />
<br />
If Flash audio is lagging, you may try to have Flash access ALSA directly. See [[PulseAudio#ALSA/dmix without grabbing hardware device]] for details.<br />
<br />
=== Permission errors bug ===<br />
<br />
{{hc|pulseaudio --start|<br />
E: [autospawn] core-util.c: Failed to create secure directory (/run/user/1000/pulse): Operation not permitted<br />
W: [autospawn] lock-autospawn.c: Cannot access autospawn lock.<br />
E: [pulseaudio] main.c: Failed to acquire autospawn lock}}<br />
<br />
Known programs that changes permissions for {{ic|/run/user/''user id''/pulse}} when using [[Polkit]] for root elevation:<br />
<br />
*{{AUR|sakis3g}} <br />
<br />
As a workaround, include {{Pkg|kdesu}} in a [[desktop entry]], or add {{ic|1=''username'' ALL=NOPASSWD: /usr/bin/''program_name''}} to [[sudoers]] to run it with {{Pkg|sudo}} without a password.<br />
<br />
The other workaround is to uncomment and set {{ic|1=daemonize = yes}} in the {{ic|/etc/pulse/daemon.conf}}.<br />
<br />
See also [https://bbs.archlinux.org/viewtopic.php?id=135955].<br />
<br />
=== Audacity ===<br />
<br />
When starting Audacity you may find that your headphones no longer work. This can be because Audacity is trying to use them as a recording device. To fix this, open Audacity, then set its recording device to {{ic|1=pulse:Internal Mic:0}}.<br />
<br />
Under some circumstances, playback may be distorted, very fast, or freeze, as discussed in the [http://wiki.audacityteam.org/wiki/Linux_Issues#ALSA_and_other_sound_systems Audacity Wiki's Linux Issues page].<br />
<br />
The solution proposed in this page may work: start Audacity with:<br />
<br />
$ env PULSE_LATENCY_MSEC=30 audacity<br />
<br />
If the solution above does not fix this issue, one may wish to temporarily disable pulseaudio while running Audacity by using the {{ic|pasuspender}} command:<br />
<br />
$ pasuspender -- audacity<br />
<br />
Then, be sure to select the appropriate ALSA input and output devices in Audacity.<br />
<br />
See also [[#Setting the default fragment number and buffer size in PulseAudio]].<br />
<br />
== Other Issues ==<br />
<br />
=== Bad configuration files ===<br />
<br />
After starting PulseAudio, if the system outputs no sound, it may be necessary to delete the contents of {{ic|~/.config/pulse}} and/or {{ic|~/.pulse}}. PulseAudio will automatically create new configuration files on its next start.<br />
<br />
=== Cannot update configuration of sound device in pavucontrol ===<br />
<br />
{{Pkg|pavucontrol}} is a handy GUI utility for configuring PulseAudio. Under its 'Configuration' tab, you can select different profiles for each of your sound devices e.g. analogue stereo, digital output (IEC958), HDMI 5.1 Surround etc.<br />
<br />
However, you may run into an instance where selecting a different profile for a card results in the pulse daemon crashing and auto restarting without the new selection "sticking". If this occurs, use the other useful GUI tool, {{Pkg|paprefs}}, to check under the "Simultaneous Output" tab for a virtual simultaneous device. If this setting is active (checked), it will prevent you changing any card's profile in pavucontrol. Uncheck this setting, then adjust your profile in pavucontrol prior to re-enabling simultaneous output in paprefs.<br />
<br />
=== Failed to create sink input: sink is suspended ===<br />
<br />
If you do not have any output sound and receive dozens of errors related to a suspended sink in your {{ic|journalctl -b}} log, then backup first and then delete your user-specific pulse folders:<br />
<br />
$ rm -r ~/.pulse ~/.pulse-cookie ~/.config/pulse<br />
<br />
=== Pulse overwrites ALSA settings ===<br />
<br />
PulseAudio usually overwrites the ALSA settings — for example set with alsamixer — at start-up, even when the ALSA daemon is loaded. Since there seems to be no other way to restrict this behaviour, a workaround is to restore the ALSA settings again after PulseAudio has started. Add the following command to {{ic|.xinitrc}} or {{ic|.bash_profile}} or any other [[autostart]] file:<br />
<br />
restore_alsa() {<br />
while [ -z "$(pidof pulseaudio)" ]; do<br />
sleep 0.5<br />
done<br />
alsactl -f /var/lib/alsa/asound.state restore <br />
}<br />
restore_alsa &<br />
<br />
=== Prevent Pulse from restarting after being killed ===<br />
<br />
Sometimes you may wish to temporarily disable Pulse. In order to do so you will have to prevent Pulse from restarting after being killed.<br />
<br />
{{hc|~/.config/pulse/client.conf|2=<br />
# Disable autospawning the PulseAudio daemon<br />
autospawn = no<br />
}}<br />
<br />
=== Daemon startup failed ===<br />
<br />
Try resetting PulseAudio:<br />
<br />
$ rm -rf /tmp/pulse* ~/.pulse* ~/.config/pulse<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
* Check that options for sinks are set up correctly.<br />
<br />
* If you configured in default.pa to load and use the OSS modules then check with {{Pkg|lsof}} that {{ic|/dev/dsp}} device is not used by another application.<br />
<br />
* Set a preferred working resample method. Use {{ic|pulseaudio --dump-resample-methods}} to see a list with all available resample methods you can use.<br />
<br />
* To get details about currently appeared unfixed errors or just get status of daemon use commands like {{ic|pax11publish -d}} and {{ic|pulseaudio -v}} where {{ic|v}} option can be used multiple time to set verbosity of log output equal to the {{ic|1=--log-level[=LEVEL]}} option where LEVEL is from 0 to 4. See the [[#Outputs by PulseAudio error status check utilities]] section.<br />
<br />
See also man pages for {{man|1|pax11publish}} and {{man|1|pulseaudio}} for more details.<br />
<br />
==== Outputs by PulseAudio error status check utilities ====<br />
<br />
If the {{ic|pax11publish -d}} shows error like:<br />
<br />
N: [pulseaudio] main.c: User-configured server at "user", refusing to start/autospawn.<br />
<br />
then run {{ic|pax11publish -r}} command then could be also good to logout and login again. This manual cleanup is always required when using LXDM because it does not restart the X server on logout; see [[LXDM#PulseAudio]]{{Broken section link}}.<br />
<br />
If the {{ic|pulseaudio -vvvv}} command shows error like:<br />
<br />
E: [pulseaudio] module-udev-detect.c: You apparently ran out of inotify watches, probably because Tracker/Beagle took them all away. I wished people would do their homework first and fix inotify before using it for watching whole directory trees which is something the current inotify is certainly not useful for. Please make sure to drop the Tracker/Beagle guys a line complaining about their broken use of inotify.<br />
<br />
This can be resolved temporary by:<br />
$ echo 100000 > /proc/sys/fs/inotify/max_user_watches<br />
<br />
For permanent use save settings in the ''99-sysctl.conf'' file:<br />
<br />
{{hc|/etc/sysctl.d/99-sysctl.conf|2=<br />
# Increase inotify max watchs per user<br />
fs.inotify.max_user_watches = 100000}}<br />
<br />
{{Warning|It may cause much bigger consumption of memory by kernel.}}<br />
<br />
'''See also''' <br />
<br />
* [http://www.linuxinsight.com/proc_sys_fs_inotify.html proc_sys_fs_inotify] and [http://lwn.net/Articles/604686/ dnotify, inotify]- more details about ''inotify/max_user_watches''<br />
* [http://stackoverflow.com/questions/535768/what-is-a-reasonable-amount-of-inotify-watches-with-linux?answertab=votes#tab-top reasonable amount of inotify watches with Linux]<br />
* {{man|7|inotify}} - man page<br />
<br />
=== Daemon already running ===<br />
<br />
On some systems, PulseAudio may be started multiple times. journalctl will report:<br />
<br />
[pulseaudio] pid.c: Daemon already running.<br />
<br />
Make sure to use only one method of autostarting applications. {{Pkg|pulseaudio}} includes these files:<br />
<br />
* {{ic|/etc/X11/xinit/xinitrc.d/pulseaudio}}<br />
* {{ic|/etc/xdg/autostart/pulseaudio.desktop}}<br />
* {{ic|/etc/xdg/autostart/pulseaudio-kde.desktop}}<br />
<br />
Also check user autostart files and directories, such as [[xinitrc]], {{ic|~/.config/autostart/}} etc.<br />
<br />
=== Subwoofer stops working after end of every song ===<br />
<br />
Known issue: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/494099<br />
<br />
To fix this, {{ic|1=enable-lfe-remixing = yes}} must be set as described in [[#Choppy sound with analog surround sound setup]].<br />
<br />
=== Unable to select surround configuration other than "Surround 4.0" ===<br />
<br />
If you are unable to set 5.1 surround output in pavucontrol because it only shows "Analog Surround 4.0 Output", open the ALSA mixer and change the output configuration there to 6 channels. Then restart pulseaudio, and pavucontrol will list many more options.<br />
<br />
=== Realtime scheduling ===<br />
<br />
If rtkit does not work, you can manually set up your system to run PulseAudio with real-time scheduling, which can help performance. To do this, add the following lines to {{ic|/etc/security/limits.conf}}:<br />
<br />
@pulse-rt - rtprio 9<br />
@pulse-rt - nice -11<br />
<br />
Afterwards, you need to add your user to the {{ic|pulse-rt}} group:<br />
<br />
# gpasswd -a <user> pulse-rt<br />
<br />
=== pactl "invalid option" error with negative percentage arguments ===<br />
<br />
{{ic|pactl}} commands that take negative percentage arguments will fail with an 'invalid option' error. Use the standard shell '--' pseudo argument<br />
to disable argument parsing before the negative argument. ''e.g.'' {{ic|pactl set-sink-volume 1 -- -5%}}.<br />
<br />
=== Fallback device is not respected ===<br />
<br />
PulseAudio does not have a true default device. Instead it uses a [http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/DefaultDevice/ "fallback"], which only applies to new sound streams. This means previously run applications are not affected by the newly set fallback device.<br />
<br />
{{Pkg|gnome-control-center}}, {{Pkg|mate-media}} and {{AUR|paswitch}} handle this gracefully. Alternatively: <br />
<br />
1. Move the old streams in {{Pkg|pavucontrol}} manually to the new sound card.<br />
<br />
2. Stop Pulse, erase the "stream-volumes" in {{ic|~/.config/pulse}} and/or {{ic|~/.pulse}} and restart Pulse. This also resets application volumes.<br />
<br />
3. Disable stream device reading. This may be not wanted when using different soundcards with different applications.<br />
<br />
{{hc|/etc/pulse/default.pa|<nowiki><br />
load-module module-stream-restore restore_device=false<br />
</nowiki>}}<br />
<br />
=== RTP/UDP packet flood ===<br />
<br />
In some cases the default configuration might flood the network with UDP packets.[https://bugs.freedesktop.org/show_bug.cgi?id=44777] <br />
To fix this problem, launch {{ic|paprefs}} and disable "Multicast/RTP Sender".[https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/411688/comments/36]</div>Calinouhttps://wiki.archlinux.org/index.php?title=Gaming&diff=522943Gaming2018-05-24T17:49:33Z<p>Calinou: /* Emulators */ Use "legal" instead of "not illegal"</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* Specialized environments (software emulators) – Required for running software designed for other architectures or systems. Check the [[List of applications/Other#Emulators|list of emulators]] for more details.<br />
** [[Wine]] &ndash; allows running of some Windows games, as well as a large amount of Windows software. Performance in Wine varies, the additional CPU overhead will cause slowdown in some games while in some cases games may run faster. Consult [http://appdb.winehq.org/ Wine AppDB] for game-specific compatibility information.<br />
** [http://www.codeweavers.com/ Crossover Games] &ndash; members of the Codeweavers team are prime supporters of Wine. Using Crossover Games makes the installation & setting up of some games easier, more reliable & even possible, when compared to using other methods. Crossover is a paid commercial product, which also provides a [http://www.codeweavers.com/support/forums/ forum] where the developers are very much involved in the community. <br />
** [[DOSBox]] is a minimal virtual machine which runs a full DOS-compatible environment. It can be used to run classic DOS titles.<br />
** {{Pkg|scummvm}} is an all-in-one engine reimplementation of many classic point-and-click adventure games. A full list of compatible titles can be found on the [http://scummvm.org ScummVM website].<br />
** Similar to ScummVM, engine reimplementations and ports exist for specific titles, such as Doom.<br />
* Virtual machines can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/Documentation/vfio.txt "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
A good number are available in the [[official repositories]] / the [[AUR]], see [[List of games]].<br />
<br />
=== Digital distribution ===<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.<br />
|https://store.steampowered.com|{{Pkg|steam}}}}<br />
<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io/|{{AUR|itch}}}}<br />
<br />
* [https://www.gog.com/games/linux GOG.com]<br />
** GOG.com officially only supports Ubuntu and Linux Mint.<br />
** The {{AUR|lgogdownloader}} package can be used to download GOG titles from the command line.<br />
<br />
== Emulators ==<br />
<br />
An emulator is a program which serves to replicate the functions of another platform or system so as to allow applications and games to be run in environments they were not programmed for.<br />
<br />
See also [[:Category:Emulation]] and the [http://emulation.gametechwiki.com/index.php/Main_Page Emulation General wiki].<br />
<br />
{{Note|1=For possibly more up to date selection of emulators, try checking the [https://aur.archlinux.org/packages.php?O=0&K=&do_Search=Go&detail=1&L=0&C=5&SeB=nd&SB=n&SO=a&PP=25 AUR 'emulators' category]{{Dead link|2018|02|03}}}}<br />
<br />
{{Warning|Owning a high-level emulator is legal, but distribution of any type of copyrighted ROMs and unauthorized emulation (without written permission of the copyright holder allowing the user to do so) are '''illegal'''. Consequently, Arch Linux does not distribute this copyrighted content, including game ROMs and ripped console BIOSs. You are fully responsible for whatever usage of the emulators obtained from the [[official repositories]] or the [[Arch User Repository]] you make, as well as any legal repercussion that result. Arch Linux bears no responsibility at all.}}<br />
<br />
=== Consoles ===<br />
<br />
See also [[Wikipedia:List of video game console emulators]].<br />
<br />
* {{App|Citra|Nintendo 3DS emulator.|http://citra-emu.org/|{{AUR|citra-git}}}}<br />
* {{App|DeSmuME|Nintendo DS emulator.|http://desmume.org/|{{Pkg|desmume}}}}<br />
* {{App|[[Dolphin emulator|Dolphin]]|Very capable GameCube and Wii emulator.|http://dolphin-emu.org/|{{Pkg|dolphin-emu}}}}<br />
* {{App|epsxe|Emulator for the PlayStation video game console for x86-based PC hardware.|http://www.epsxe.com/|{{AUR|epsxe}}}}<br />
* {{App|FCEUX|NTSC and PAL 8 bit Nintendo/Famicom emulator that is an evolution of the original FCE Ultra emulator. It is accurate, compatible and actively maintained.|http://fceux.com/|{{Pkg|fceux}}}}<br />
* {{App|Gambatte|Accurate Game Boy Color emulator|https://github.com/sinamas/gambatte|Qt GUI frontend ({{AUR|gambatte-qt}}), SDL CLI frontend ({{AUR|gambatte-sdl}}).}}<br />
* {{App|Gens2|Emulator for Sega Genesis, Sega CD and 32X that is written in assembly language and no longer actively developed.<br />
:* activate OpenGL, set video resolution per custom to 1024×600 for streched full-screen or 800×600 for non-streched;<br />
:* use "Normal" renderer, I couldn't find a visible advantage with the other ones.<br />
|http://www.gens.me/|{{Pkg|gens}}}}<br />
<br />
* {{App|Gens-GS|Gens2, rewritten in C++, combining features from various Gens forks.|http://segaretro.org/Gens/GS|{{Pkg|gens-gs}}}}<br />
* {{App|gngeo|Command-line NeoGeo emulator.|http://gngeo.googlecode.com|{{AUR|gngeo}}}}<br />
* {{App|higan|Multisystem emulator focusing on accuracy, supporting SNES, NES, GB, GBC, GBA.|https://byuu.org/emulation/higan/|{{Pkg|higan}}}}<br />
* {{App|mednafen|Command line driven multi system emulator.|http://mednafen.sourceforge.net/|{{Pkg|mednafen}}}}<br />
* {{App|Mupen64Plus|Highly compatible Nintendo 64 emulator with plugin system.<br />
|http://www.mupen64plus.org/|{{Pkg|mupen64plus}} or a graphical front-end, such as {{AUR|m64py}} or {{AUR|cutemupen}}.}}<br />
* {{App|[[Nestopia]]|Very accurate NES emulator.|http://0ldsk00l.ca/nestopia/|{{Aur|nestopia}} }}<br />
* {{App|pSX|A not plugin-based PlayStation emulator with fairly high compatibility.|http://psxemulator.gazaxian.com/|{{AUR|psx}}}}<br />
* {{App|[[PCSX-Reloaded|PCSXR]] | PlayStation emulator; Debian fork of the abandoned original PCSX|http://pcsxr.codeplex.com/|{{AUR|pcsxr}}}}<br />
* {{App|PCSX2|PlayStation 2 emulator. It is still being maintained and developed. It requires BIOS files.|http://www.pcsx2.net/|{{Pkg|pcsx2}}}}<br />
* {{App|PPSSPP|PlayStation Portable emulator.|http://ppsspp.org/|{{Pkg|ppsspp}}}}<br />
* {{App|Snes9x|Portable, freeware Super Nintendo Entertainment System (SNES) emulator.|http://www.snes9x.com/|{{Pkg|snes9x}}}}<br />
* {{App|[[Visual Boy Advance]]|Game Boy emulator with Game Boy Advance, Game Boy Color, and Super Game Boy support.<br />
|http://vba.ngemu.com/|{{Pkg|vbam-wx}}}}<br />
* {{App|ZSNES|Highly compatible Super Nintendo emulator.<br />
|http://www.zsnes.com/|{{Pkg|zsnes}}}}<br />
<br />
=== Other ===<br />
<br />
* {{App|DOSBox|Open-source DOS emulator which primarily focuses on running DOS Games.|http://www.dosbox.com/|{{Pkg|dosbox}}}}<br />
* {{App|DOSEmu|Open-source DOS emulator.|http://www.dosemu.org/|{{Pkg|dosemu}}}}<br />
* {{App|MAME|Multiple Arcade Machine Emulator.|http://mamedev.org/|{{Pkg|sdlmame}}{{Broken package link|replaced by {{Pkg|mame}}}}}}<br />
* {{App|ResidualVM|Cross-platform 3D game interpreter which allows you to play LucasArts' Lua-based 3D adventures.|http://residualvm.org/|{{AUR|residualvm}}}}<br />
* {{App|[[RetroArch]]|Frontend to libretro (emulation library, using modified versions of existing emulators as plugins).|http://www.libretro.com/|{{Pkg|retroarch}}}}<br />
* {{App|ScummVM|Virtual machine for old school adventures.|http://www.scummvm.org/|{{Pkg|scummvm}}}}<br />
* {{App|X Neko Project II|PC-9801 emulator.|http://www.asahi-net.or.jp/~aw9k-nnk/np2/|{{AUR|xnp2}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
To disable keyboard grabbing at X11 level, install the {{AUR|libx11-nokeyboardgrab}} package.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
$ ~/game.sh xonotic-glx<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Mouse focus in GNOME ===<br />
<br />
{{Merge|GNOME}}<br />
<br />
The 'sloppy' and 'mouse' window-focusing modes in [[GNOME]] are known to cause issues with a variety of games, causing a 'click-through' effect. Users can remedy this problem by switching the focus mode to 'click' (with a tool such as {{Pkg|gnome-tweak-tool}}{{Broken package link|replaced by {{Pkg|gnome-tweaks}}}}), playing in a different desktop environment, or spawing their game in a separate X-session.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-0 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]].<br />
<br />
== Improving framerates and responsiveness with scheduling policies ==<br />
Most every game can benefit if given the correct scheduling policies for the kernel to prioritize the task. However, without the help of a daemon, this rescheduling would have to be carried out manually or through the use of several daemons for each policy. These policies should ideally be set per-thread by the application itself, but not all developers implement these policies. There are several methods for getting them to work anyway:<br />
<br />
=== For Wine programs ===<br />
See [[Wine#Performance]]<br />
<br />
=== For everything else ===<br />
<br />
For programs which do not implement scheduling policies on their own, one tool known as '''schedtool''', and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
First and foremost, setting the scheduling policy to {{ic|SCHED_ISO}} will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. <br />
{{ic|SCHED_ISO}} requires [[Linux-ck]] to operate, as it has only been implemented in that kernel. [[Linux-ck]] itself provides a hefty latency reduction, and should ideally be installed <br />
Most if not all games will benefit from this:<br />
bit.trip.runner -I<br />
For users not using [[Linux-ck]], {{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is reccommended for most multimedia tasks, including games:<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. In any case where they both attempt it, it causes drops in framerate and crashes. Examples of this include a number of modern games, and any Wine program which is running without [[Wikipedia:OpenGL Shading Language|GLSL]] disabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.: <br />
bit.trip.runner -a 0x1<br />
uses first core.<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
bit.trip.runner -a 0x5<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since rarely consumes the whole CPU and needs higher prioritization when possible.<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Using alternate kernels ==<br />
<br />
{{Note|Many users report inconsistant framerate and other performance hits when using [[Linux-ck]], even if the overall framerate is sometimes higher. You may wish to try using {{Pkg|linux-zen}} if you just want BFQ.}}<br />
<br />
The stock Arch kernel provides a very good baseline for general usage. However, if your system has less than 16 cores and is intended for use primarily as a workstation, you can sacrifice a small amount of throughput on batch workloads and gain a significant boost to interactivity by using [[Linux-ck]]. Using a pre-optimized kernel will most definitely offset any loss of throughput that may have occurred as a result, so be sure to select the appropriate kernel for your architecture.<br />
<br />
=== Using BFQ ===<br />
<br />
BFQ is an io-scheduler that comes as a feature of {{Pkg|linux-zen}} and [[Linux-ck]], and is optimized to be much more simplistic, but provides better interactivity and throughput for non-server workloads. To enable, simply add the kernel parameter ''elevator=bfq'' to your [[bootloader]]. It is important to note that although most guides recommend using either ''noop'' or ''deadline'' for SSDs for their raw throughput, they are actually detrimental to interactivity when more than one thread is attempting to access the device. It is best to use ''bfq'' unless you desperately need the throughput advantage.</div>Calinouhttps://wiki.archlinux.org/index.php?title=Gaming&diff=522942Gaming2018-05-24T17:47:52Z<p>Calinou: Mention source ports as well (since Doom has source ports, not really engine reimplementations)</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* Specialized environments (software emulators) – Required for running software designed for other architectures or systems. Check the [[List of applications/Other#Emulators|list of emulators]] for more details.<br />
** [[Wine]] &ndash; allows running of some Windows games, as well as a large amount of Windows software. Performance in Wine varies, the additional CPU overhead will cause slowdown in some games while in some cases games may run faster. Consult [http://appdb.winehq.org/ Wine AppDB] for game-specific compatibility information.<br />
** [http://www.codeweavers.com/ Crossover Games] &ndash; members of the Codeweavers team are prime supporters of Wine. Using Crossover Games makes the installation & setting up of some games easier, more reliable & even possible, when compared to using other methods. Crossover is a paid commercial product, which also provides a [http://www.codeweavers.com/support/forums/ forum] where the developers are very much involved in the community. <br />
** [[DOSBox]] is a minimal virtual machine which runs a full DOS-compatible environment. It can be used to run classic DOS titles.<br />
** {{Pkg|scummvm}} is an all-in-one engine reimplementation of many classic point-and-click adventure games. A full list of compatible titles can be found on the [http://scummvm.org ScummVM website].<br />
** Similar to ScummVM, engine reimplementations and ports exist for specific titles, such as Doom.<br />
* Virtual machines can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/Documentation/vfio.txt "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
A good number are available in the [[official repositories]] / the [[AUR]], see [[List of games]].<br />
<br />
=== Digital distribution ===<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.<br />
|https://store.steampowered.com|{{Pkg|steam}}}}<br />
<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io/|{{AUR|itch}}}}<br />
<br />
* [https://www.gog.com/games/linux GOG.com]<br />
** GOG.com officially only supports Ubuntu and Linux Mint.<br />
** The {{AUR|lgogdownloader}} package can be used to download GOG titles from the command line.<br />
<br />
== Emulators ==<br />
<br />
An emulator is a program which serves to replicate the functions of another platform or system so as to allow applications and games to be run in environments they were not programmed for.<br />
<br />
See also [[:Category:Emulation]] and the [http://emulation.gametechwiki.com/index.php/Main_Page Emulation General wiki].<br />
<br />
{{Note|1=For possibly more up to date selection of emulators, try checking the [https://aur.archlinux.org/packages.php?O=0&K=&do_Search=Go&detail=1&L=0&C=5&SeB=nd&SB=n&SO=a&PP=25 AUR 'emulators' category]{{Dead link|2018|02|03}}}}<br />
<br />
{{Warning|Owning a high-level emulator is not illegal, but distribution of any type of copyrighted ROMs and unauthorized emulation (without written permission of the copyright holder allowing the user to do so) are '''illegal'''. Consequently, Arch Linux does not distribute this copyrighted content, including game ROMs and ripped console BIOSs. You are fully responsible for whatever usage of the emulators obtained from the [[official repositories]] or the [[Arch User Repository]] you make, as well as any legal repercussion that result. Arch Linux bears no responsibility at all.}}<br />
<br />
=== Consoles ===<br />
<br />
See also [[Wikipedia:List of video game console emulators]].<br />
<br />
* {{App|Citra|Nintendo 3DS emulator.|http://citra-emu.org/|{{AUR|citra-git}}}}<br />
* {{App|DeSmuME|Nintendo DS emulator.|http://desmume.org/|{{Pkg|desmume}}}}<br />
* {{App|[[Dolphin emulator|Dolphin]]|Very capable GameCube and Wii emulator.|http://dolphin-emu.org/|{{Pkg|dolphin-emu}}}}<br />
* {{App|epsxe|Emulator for the PlayStation video game console for x86-based PC hardware.|http://www.epsxe.com/|{{AUR|epsxe}}}}<br />
* {{App|FCEUX|NTSC and PAL 8 bit Nintendo/Famicom emulator that is an evolution of the original FCE Ultra emulator. It is accurate, compatible and actively maintained.|http://fceux.com/|{{Pkg|fceux}}}}<br />
* {{App|Gambatte|Accurate Game Boy Color emulator|https://github.com/sinamas/gambatte|Qt GUI frontend ({{AUR|gambatte-qt}}), SDL CLI frontend ({{AUR|gambatte-sdl}}).}}<br />
* {{App|Gens2|Emulator for Sega Genesis, Sega CD and 32X that is written in assembly language and no longer actively developed.<br />
:* activate OpenGL, set video resolution per custom to 1024x600 for streched full-screen or 800x600 for non-streched;<br />
:* use "Normal" renderer, I couldn't find a visible advantage with the other ones.<br />
|http://www.gens.me/|{{Pkg|gens}}}}<br />
<br />
* {{App|Gens-GS|Gens2, rewritten in C++, combining features from various Gens forks.|http://segaretro.org/Gens/GS|{{Pkg|gens-gs}}}}<br />
* {{App|gngeo|Command-line NeoGeo emulator.|http://gngeo.googlecode.com|{{AUR|gngeo}}}}<br />
* {{App|higan|Multisystem emulator focusing on accuracy, supporting SNES, NES, GB, GBC, GBA.|https://byuu.org/emulation/higan/|{{Pkg|higan}}}}<br />
* {{App|mednafen|Command line driven multi system emulator.|http://mednafen.sourceforge.net/|{{Pkg|mednafen}}}}<br />
* {{App|Mupen64Plus|Highly compatible Nintendo 64 emulator with plugin system.<br />
|http://www.mupen64plus.org/|{{Pkg|mupen64plus}} or a graphical front-end, such as {{AUR|m64py}} or {{AUR|cutemupen}}.}}<br />
* {{App|[[Nestopia]]|Very accurate NES emulator.|http://0ldsk00l.ca/nestopia/|{{Aur|nestopia}} }}<br />
* {{App|pSX|A not plugin-based PlayStation emulator with fairly high compatibility.|http://psxemulator.gazaxian.com/|{{AUR|psx}}}}<br />
* {{App|[[PCSX-Reloaded|PCSXR]] | PlayStation emulator; Debian fork of the abandoned original PCSX|http://pcsxr.codeplex.com/|{{AUR|pcsxr}}}}<br />
* {{App|PCSX2|PlayStation 2 emulator. It is still being maintained and developed. It requires BIOS files.|http://www.pcsx2.net/|{{Pkg|pcsx2}}}}<br />
* {{App|PPSSPP|PlayStation Portable emulator.|http://ppsspp.org/|{{Pkg|ppsspp}}}}<br />
* {{App|Snes9x|Portable, freeware Super Nintendo Entertainment System (SNES) emulator.|http://www.snes9x.com/|{{Pkg|snes9x}}}}<br />
* {{App|[[Visual Boy Advance]]|Game Boy emulator with Game Boy Advance, Game Boy Color, and Super Game Boy support.<br />
|http://vba.ngemu.com/|{{Pkg|vbam-wx}}}}<br />
* {{App|ZSNES|Highly compatible Super Nintendo emulator.<br />
|http://www.zsnes.com/|{{Pkg|zsnes}}}}<br />
<br />
=== Other ===<br />
<br />
* {{App|DOSBox|Open-source DOS emulator which primarily focuses on running DOS Games.|http://www.dosbox.com/|{{Pkg|dosbox}}}}<br />
* {{App|DOSEmu|Open-source DOS emulator.|http://www.dosemu.org/|{{Pkg|dosemu}}}}<br />
* {{App|MAME|Multiple Arcade Machine Emulator.|http://mamedev.org/|{{Pkg|sdlmame}}{{Broken package link|replaced by {{Pkg|mame}}}}}}<br />
* {{App|ResidualVM|Cross-platform 3D game interpreter which allows you to play LucasArts' Lua-based 3D adventures.|http://residualvm.org/|{{AUR|residualvm}}}}<br />
* {{App|[[RetroArch]]|Frontend to libretro (emulation library, using modified versions of existing emulators as plugins).|http://www.libretro.com/|{{Pkg|retroarch}}}}<br />
* {{App|ScummVM|Virtual machine for old school adventures.|http://www.scummvm.org/|{{Pkg|scummvm}}}}<br />
* {{App|X Neko Project II|PC-9801 emulator.|http://www.asahi-net.or.jp/~aw9k-nnk/np2/|{{AUR|xnp2}}}}<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
To disable keyboard grabbing at X11 level, install the {{AUR|libx11-nokeyboardgrab}} package.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
$ ~/game.sh xonotic-glx<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Mouse focus in GNOME ===<br />
<br />
{{Merge|GNOME}}<br />
<br />
The 'sloppy' and 'mouse' window-focusing modes in [[GNOME]] are known to cause issues with a variety of games, causing a 'click-through' effect. Users can remedy this problem by switching the focus mode to 'click' (with a tool such as {{Pkg|gnome-tweak-tool}}{{Broken package link|replaced by {{Pkg|gnome-tweaks}}}}), playing in a different desktop environment, or spawing their game in a separate X-session.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-0 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]].<br />
<br />
== Improving framerates and responsiveness with scheduling policies ==<br />
Most every game can benefit if given the correct scheduling policies for the kernel to prioritize the task. However, without the help of a daemon, this rescheduling would have to be carried out manually or through the use of several daemons for each policy. These policies should ideally be set per-thread by the application itself, but not all developers implement these policies. There are several methods for getting them to work anyway:<br />
<br />
=== For Wine programs ===<br />
See [[Wine#Performance]]<br />
<br />
=== For everything else ===<br />
<br />
For programs which do not implement scheduling policies on their own, one tool known as '''schedtool''', and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
First and foremost, setting the scheduling policy to {{ic|SCHED_ISO}} will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. <br />
{{ic|SCHED_ISO}} requires [[Linux-ck]] to operate, as it has only been implemented in that kernel. [[Linux-ck]] itself provides a hefty latency reduction, and should ideally be installed <br />
Most if not all games will benefit from this:<br />
bit.trip.runner -I<br />
For users not using [[Linux-ck]], {{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is reccommended for most multimedia tasks, including games:<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. In any case where they both attempt it, it causes drops in framerate and crashes. Examples of this include a number of modern games, and any Wine program which is running without [[Wikipedia:OpenGL Shading Language|GLSL]] disabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.: <br />
bit.trip.runner -a 0x1<br />
uses first core.<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
bit.trip.runner -a 0x5<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since rarely consumes the whole CPU and needs higher prioritization when possible.<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5<br />
<br />
== Using alternate kernels ==<br />
<br />
{{Note|Many users report inconsistant framerate and other performance hits when using [[Linux-ck]], even if the overall framerate is sometimes higher. You may wish to try using {{Pkg|linux-zen}} if you just want BFQ.}}<br />
<br />
The stock Arch kernel provides a very good baseline for general usage. However, if your system has less than 16 cores and is intended for use primarily as a workstation, you can sacrifice a small amount of throughput on batch workloads and gain a significant boost to interactivity by using [[Linux-ck]]. Using a pre-optimized kernel will most definitely offset any loss of throughput that may have occurred as a result, so be sure to select the appropriate kernel for your architecture.<br />
<br />
=== Using BFQ ===<br />
<br />
BFQ is an io-scheduler that comes as a feature of {{Pkg|linux-zen}} and [[Linux-ck]], and is optimized to be much more simplistic, but provides better interactivity and throughput for non-server workloads. To enable, simply add the kernel parameter ''elevator=bfq'' to your [[bootloader]]. It is important to note that although most guides recommend using either ''noop'' or ''deadline'' for SSDs for their raw throughput, they are actually detrimental to interactivity when more than one thread is attempting to access the device. It is best to use ''bfq'' unless you desperately need the throughput advantage.</div>Calinouhttps://wiki.archlinux.org/index.php?title=Steam&diff=502899Steam2017-12-16T16:38:57Z<p>Calinou: Typo/grammar fix</p>
<hr />
<div>[[Category:Gaming]]<br />
[[ja:Steam]]<br />
[[ru:Steam]]<br />
[[zh-hans:Steam]]<br />
{{Related articles start}}<br />
{{Related|Steam/Wine}}<br />
{{Related|Steam/Troubleshooting}}<br />
{{Related|Steam/Game-specific troubleshooting}}<br />
{{Related|Gamepad}}<br />
{{Related|Games}}<br />
{{Related|List of games}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Steam (software)|Wikipedia]]:<br />
:Steam is a digital distribution, digital rights management, multiplayer and communications platform developed by Valve Corporation. It is used to distribute games and related media online, from small independent developers to larger software houses.<br />
<br />
[http://store.steampowered.com/about/ Steam] is best known as the platform needed to play Source Engine games (e.g. Half-Life 2, Counter-Strike). Today it offers many games from many other developers.<br />
<br />
== Installation ==<br />
<br />
{{Note|Arch Linux is '''not''' officially supported, the only officially supported distribution is Ubuntu. [https://support.steampowered.com/kb_article.php?ref&#61;1504-QHXN-8366]}}<br />
<br />
Enable the [[Multilib]] repository and [[install]] the {{Pkg|steam}} package.<br />
<br />
The following fixes are needed to get Steam functioning properly on Arch Linux:<br />
<br />
* You need to install the 32-bit version of your [[Xorg#Driver installation|graphics driver]] (the package in the ''OpenGL (Multilib)'' column).<br />
* Steam may fail to start due to broken/missing libraries. See [[Steam/Troubleshooting#Steam runtime issues]].<br />
* Steam makes heavy usage of the Arial font. A decent Arial font to use is {{Pkg|ttf-liberation}} or [[Steam/Troubleshooting#Text is corrupt or missing|the fonts provided by Steam]]. Asian languages require {{Pkg|wqy-zenhei}} to display properly.<br />
* Several games have dependencies which may be missing from your system. If a game fails to launch (often without error messages) then make sure all of the libraries listed in [[Steam/Game-specific troubleshooting]] are installed.<br />
* In case that you are using Arch Linux in your local language, make sure that you also have properly generated en_US locales (see [[Locale#Generating locales]]), otherwise, the Steam client won't start with an '''invalid pointer''' error.<br />
<br />
=== SteamCMD ===<br />
<br />
For the [https://developer.valvesoftware.com/wiki/SteamCMD SteamCMD], a command-line version of the Steam client,<br />
that is primarily used to install and update dedicated servers, [[install]] the {{AUR|steamcmd}} package.<br />
<br />
{{Note|The AUR package installs files owned by root, so you must be root to update SteamCMD itself.}}<br />
<br />
=== Alternative Flatpak installation ===<br />
<br />
Steam can also be installed with [[Flatpak]] as {{ic|com.valvesoftware.Steam}} from [https://flathub.org/ Flathub].<br />
<br />
pacman -S flatpak<br />
<br />
<br />
flatpak install --from https://flathub.org/repo/appstream/com.valvesoftware.Steam.flatpakref<br />
<br />
<br />
The Flatpak application currently does not support themes. Also you currently can't run games via {{ic|optirun}}/{{ic|primusrun}}, see [https://github.com/flatpak/flatpak/issues/869 Issue#869] for more details.<br />
<br />
By default Steam won't be able to access your home directory, you can run the following command to allow it, so that it behaves like on Ubuntu or SteamOS:<br />
<br />
flatpak override com.valvesoftware.Steam --filesystem=/home/$USER<br />
<br />
Note: Some games don't work fully or at all. May be wise to use a flatpak steam install, as a backup way to access steam, in case an arch update prevents Steam from launching correctly.<br />
<br />
== Usage ==<br />
<br />
To start Steam simply run {{ic|steam}}.<br />
<br />
* {{ic|-bigpicture}} to start in Big Picture Mode<br />
* {{ic|-silent}} don't open the main window<br />
<br />
== Tips and tricks ==<br />
<br />
=== Directory structure ===<br />
<br />
{{ic|~/.steam/}} by default contains the following symlinks:<br />
<br />
bin -> ~/.steam/bin32<br />
bin32 -> ~/.local/share/Steam/ubuntu12_32<br />
bin64 -> ~/.local/share/Steam/ubuntu12_64<br />
root -> ~/.local/share/Steam<br />
sdk32 -> ~/.local/share/Steam/linux32<br />
sdk64 -> ~/.local/share/Steam/linux64<br />
steam -> ~/.local/share/Steam<br />
<br />
As you can see Steam stores its files in {{ic|~/.local/share/Steam/}} by default. You can change where Steam stores its content by moving {{ic|~/.local/share/Steam/}} and starting Steam, which will prompt you if you have moved your Steam content. You can then browse to the new location and Steam will update the symlinks in {{ic|~/.steam/}}.<br />
<br />
Games are installed in {{ic|~/.steam/root/steamapps/common/}}.<br />
<br />
=== Launch options ===<br />
<br />
To set custom launch options for a game, right-click on it in your library, select Properties and click on the Set Launch Options button.<br />
<br />
When your launch options contain {{ic|%command%}} Steam will replace it with the game's launch command, otherwise Steam will prefix the launch command to your launch options.<br />
The resulting command is then run in a [[Bash]] shell, allowing you to set environment variables before {{ic|%command%}}.<br />
<br />
=== Big Picture Mode without a window manager ===<br />
<br />
To start Steam in Big Picture Mode from a [[Display manager]], create a {{ic|/usr/share/xsessions/steam-big-picture.desktop}} file with the following contents: <br />
<br />
{{hc|/usr/share/xsessions/steam-big-picture.desktop|<nowiki><br />
[Desktop Entry]<br />
Name=Steam Big Picture Mode<br />
Comment=Start Steam in Big Picture Mode<br />
Exec=/usr/bin/steam -bigpicture<br />
TryExec=/usr/bin/steam<br />
Icon=<br />
Type=Application</nowiki>}}<br />
<br />
=== Steam skins ===<br />
<br />
The Steam interface can be customized using skins. Skins can overwrite interface-specific files in {{ic|~/.steam/steam}}.<br />
<br />
To install a skin:<br />
<br />
# Place its directory in {{ic|~/.local/share/Steam/skins}}.<br />
# Open ''Steam > Settings > Interface'' and select it.<br />
# Restart Steam.<br />
<br />
An extensive list of skins can be found in [http://forums.steampowered.com/forums/showthread.php?t=1161035 this Steam forums post].<br />
<br />
{{Note|Using an outdated skin may cause visual errors.}}<br />
<br />
==== Creating skins ====<br />
<br />
Nearly all Steam styles are defined in {{ic|~/.steam/steam/resource/styles/steam.styles}} (the file is over 3,500 lines long). For a skin to be recognized it needs its own {{ic|resource/styles/steam.styles}}.<br />
When a Steam update changes the official {{ic|steam.styles}} your skin may become outdated, potentially resulting in visual errors.<br />
<br />
See {{ic|~/.local/share/Steam/skins/skins_readme.txt}} for a primer on how to create skins.<br />
<br />
=== Changing the Steam notification position ===<br />
<br />
The default Steam notification position is bottom right.<br />
<br />
You can change the Steam notification position by altering {{ic|Notifications.PanelPosition}} in<br />
<br />
* {{ic|resource/styles/steam.styles}} for desktop notifications, and<br />
* {{ic|resource/styles/gameoverlay.styles}} for in-game notifications<br />
<br />
Both files are overwritten by Steam on startup and {{ic|steam.styles}} is only read on startup.<br />
<br />
{{Note|Some games do not respect the setting in {{ic|gameoverlay.styles}} e.g. XCOM: Enemy Unknown.}}<br />
<br />
==== Use a skin ====<br />
<br />
You can create a skin to change the notification position to your liking. For example to change the position to top right:<br />
<br />
$ cd ~/.local/share/Steam/skins<br />
$ mkdir -p Top-Right/resource<br />
$ cp -r ~/.steam/steam/resource/styles Top-Right/resource<br />
$ sed -i '/Notifications.PanelPosition/ s/"[A-Za-z]*"/"TopRight"/' Top-Right/resource/styles/*<br />
<br />
==== Live patching ====<br />
<br />
{{ic|gameoverlay.styles}} can be overwritten while Steam is running, allowing you to have game-specific notification positions.<br />
<br />
{{hc|~/.steam/notifpos.sh|<br />
sed -i "/Notifications.PanelPosition/ s/\"[A-Za-z]*\"/\"$1\"/" ~/.steam/steam/resource/styles/gameoverlay.styles<br />
}}<br />
<br />
And the [[#Launch options]] should be something like:<br />
<br />
~/.steam/notifpos.sh TopLeft && %command%<br />
<br />
=== In-Home Streaming ===<br />
<br />
Steam has built-in support for [http://store.steampowered.com/streaming/ In-Home Streaming].<br />
<br />
See [https://steamcommunity.com/sharedfiles/filedetails/?id=680514371 this Steam Community guide] on how to setup a headless In-Home Streaming server on Linux.<br />
<br />
=== Finding a games AppID ===<br />
<br />
Every Steam application has a unique AppID.<br />
<br />
To find the AppID of an installed game:<br />
<br />
# Right click on the game in your library, select create desktop shortcut.<br />
# Open the created file {{ic|~/Desktop/<game>.desktop}} with a text editor.<br />
# Find the AppID in the Exec command {{ic|1=Exec=steam steam://rungameid/<appid>}}.<br />
<br />
Alternatively find the game's [http://store.steampowered.com/ Steam Store] page and check out the URL:<br />
<br />
<nowiki>http://store.steampowered.com/app/<appid>/<name>/</nowiki><br />
<br />
== Troubleshooting ==<br />
<br />
See [[Steam/Troubleshooting]].<br />
<br />
== See also ==<br />
<br />
* [https://wiki.gentoo.org/wiki/Steam Gentoo Wiki article]<br />
* [https://pcgamingwiki.com/wiki/The_Big_List_of_DRM-Free_Games_on_Steam The Big List of DRM-Free Games on Steam] at PCGamingWiki<br />
* [http://steam.wikia.com/wiki/List_of_DRM-free_games List of DRM-free games] at Wikia<br />
* [http://store.steampowered.com/browse/linux Steam Linux store]</div>Calinouhttps://wiki.archlinux.org/index.php?title=Systemd-nspawn&diff=478196Systemd-nspawn2017-05-24T15:14:59Z<p>Calinou: Replace example Ubuntu codenames with more recent, supported ones, improve wording</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Virtualization]]<br />
[[ja:Systemd-nspawn]]<br />
[[ru:Systemd-nspawn]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Linux Containers}}<br />
{{Related|systemd-networkd}}<br />
{{Related|Docker}}<br />
{{Related|Lxc-systemd}}<br />
{{Related articles end}}<br />
<br />
''systemd-nspawn'' is like the [[chroot]] command, but it is a ''chroot on steroids''.<br />
<br />
''systemd-nspawn'' may be used to run a command or OS in a light-weight namespace container. It is more powerful than [[chroot]] since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host and domain name.<br />
<br />
''systemd-nspawn'' limits access to various kernel interfaces in the container to read-only, such as {{ic|/sys}}, {{ic|/proc/sys}} or {{ic|/sys/fs/selinux}}. Network interfaces and the system clock may not be changed from within the container. Device nodes may not be created. The host system cannot be rebooted and kernel modules may not be loaded from within the container.<br />
<br />
This mechanism differs from [[Lxc-systemd]] or [[Libvirt]]-lxc, as it is a much simpler tool to configure.<br />
<br />
== Installation ==<br />
<br />
''systemd-nspawn'' is part of and packaged with {{Pkg|systemd}}. <br />
<br />
== Examples ==<br />
<br />
=== Create and boot a minimal Arch Linux distribution in a container ===<br />
<br />
First install {{Pkg|arch-install-scripts}}.<br />
<br />
Next, create a directory to hold the container. In this example we will use {{ic|~/MyContainer}}. <br />
<br />
Next, we use pacstrap to install a basic arch-system into the container. At minimum we need to install the {{Grp|base}} group. <br />
<br />
# pacstrap -i -c -d ~/MyContainer base [additional pkgs/groups]<br />
<br />
{{Tip|The {{ic|-i}} option will '''avoid''' auto-confirmation of package selection. As you do not need to install the Linux kernel in the container, you can remove it from the package list selection to save space. See [[Pacman#Usage]].}}<br />
<br />
{{Note|The package {{Pkg|linux-firmware}} required by {{Pkg|linux}}, which is included in the {{Grp|base}} group and isn't necessary to run the container, causes some issues to {{ic|systemd-tmpfiles-setup.service}} during the booting process with {{ic|systemd-nspawn}}. It's possible to install the {{Grp|base}} group but excluding the {{Pkg|linux}} package and its dependencies when building the container with {{ic|# pacstrap -c -d ~/MyContainer base --ignore linux [additional pkgs/groups]}}. The {{ic|--ignore}} flag will be simply passed to {{Pkg|pacman}}. See {{Bug|46591}} for more information.}}<br />
<br />
Once your installation is finished, boot into the container:<br />
<br />
# systemd-nspawn -b -D ~/MyContainer<br />
<br />
The {{ic|-b}} option will boot the container (i.e. run {{ic|systemd}} as PID=1), instead of just running a shell, and {{ic|-D}} specifies the directory that becomes the container's root directory.<br />
<br />
After the container starts, log in as "root" with no password.<br />
<br />
The container can be powered off by running {{ic|poweroff}} from within the container. From the host, containers can be controlled by the [[#machinectl|machinectl]] tool.<br />
<br />
{{Note|To terminate the ''session'' from within the container, hold {{ic|Ctrl}} and rapidly press {{ic|]}} three times. Non-US keyboard users should use {{ic|%}} instead of {{ic|]}}}}.<br />
<br />
==== Bootstrap Arch Linux i686 inside x86_64 host ====<br />
<br />
It is possible to install a minimal i686 Arch Linux inside a subdirectory and use it as systemd-nspawn container instead of [[chroot]] or [[virtualization]]. This is useful for testing {{ic|PKGBUILD}} compilation for i686 and other tasks. Make sure you use a {{ic|pacman.conf}} '''without''' {{ic|multilib}} repository.<br />
<br />
# pacman_conf=/tmp/pacman.conf # this is pacman.conf without multilib<br />
# mkdir /mnt/i686-archlinux<br />
# linux32 pacstrap -C "$pacman_conf" -di /mnt/i686-archlinux base base-devel<br />
<br />
You may deselect {{ic|linux}} from {{ic|base}} group, since the resulting bootstrap directory is not meant to be booted on real or virtualized hardware.<br />
<br />
To start the resulting i686 Arch Linux systemd-nspawn instance, just issue the following command.<br />
<br />
# linux32 systemd-nspawn -D /mnt/i686-archlinux<br />
<br />
=== Create a Debian or Ubuntu environment ===<br />
<br />
Install {{Pkg|debootstrap}}, {{Aur|gnupg1}}, and one or both of {{Aur|debian-archive-keyring}} and {{Aur|ubuntu-keyring}} (obviously install the keyrings for the distros you want).<br />
<br />
{{Note|''systemd-nspawn'' requires that the operating system in the container has systemd running as PID 1 and ''systemd-nspawn'' is installed in the container. This means Ubuntu before 15.04 will not work out of the box and requires additional configuration to switch from upstart to systemd. Also make sure that the {{ic|systemd-container}} package is installed on the container system.}}<br />
<br />
From there it's rather easy to setup Debian or Ubuntu environments:<br />
<br />
# cd /var/lib/machines<br />
# debootstrap <codename> myContainer <repository-url><br />
<br />
For Debian valid code names are either the rolling names like "stable" and "testing" or release names like "stretch" and "sid", for Ubuntu the code name like "xenial" or "zesty" should be used. A complete list of codenames is in {{ic|/usr/share/debootstrap/scripts}}. In case of a Debian image the "repository-url" can be {{ic|http://deb.debian.org/debian/}}.<br />
<br />
Unlike Arch, Debian and Ubuntu will not let you login without a password on first login. To set the root password login without the '-b' option and set a password:<br />
<br />
# systemd-nspawn -D myContainer<br />
# passwd<br />
# logout<br />
<br />
=== Enable container on boot ===<br />
<br />
When using a container frequently, you may want to start it on boot.<br />
<br />
First [[enable]] the {{ic|machines.target}} target, then {{ic|systemd-nspawn@''myContainer''.service}}, where {{ic|myContainer}} is an nspawn container in {{ic|/var/lib/machines}}.<br />
<br />
{{Tip|<br />
* To customize the startup of a container, [[edit]] the {{ic|systemd-nspawn@''myContainer''}} unit instance. See {{ic|systemd-nspawn(1)}} for all options.<br />
}}<br />
<br />
=== Build and test packages ===<br />
<br />
See [[Creating packages for other distributions]] for example uses.<br />
<br />
== Management ==<br />
<br />
=== machinectl ===<br />
<br />
{{Note|The ''machinectl'' tool requires [[systemd]] and {{Pkg|dbus}} to be installed in the container. See [https://github.com/systemd/systemd/issues/685] for detailed discussion.}}<br />
<br />
Managing your containers is essentially done with the {{ic|machinectl}} command. See {{ic|machinectl(1)}} for details.<br />
<br />
Examples:<br />
<br />
Spawn a new shell inside a running container: <br />
<br />
$ machinectl login ''MyContainer''<br />
<br />
Show detailed information about a container: <br />
<br />
$ machinectl status ''MyContainer''<br />
<br />
Reboot a container:<br />
<br />
$ machinectl reboot ''MyContainer''<br />
<br />
Poweroff a container:<br />
<br />
$ machinectl poweroff ''MyContainer''<br />
<br />
{{Tip|Poweroff and reboot operations can be performed from within a container session using the ''systemctl'' {{ic|poweroff}} or {{ic|reboot}} commands.}}<br />
<br />
Download an image:<br />
<br />
# machinectl pull-tar ''URL'' ''name''<br />
<br />
=== systemd toolchain ===<br />
<br />
Much of the core systemd toolchain has been updated to work with containers. Tools that do usually provide a {{ic|1=-M, --machine=}} option which will take a container name as argument.<br />
<br />
Examples:<br />
<br />
See journal logs for a particular machine:<br />
<br />
$ journalctl -M ''MyContainer''<br />
<br />
Show control group contents:<br />
<br />
$ systemd-cgls -M ''MyContainer''<br />
<br />
See startup time of container:<br />
<br />
$ systemd-analyze -M ''MyContainer''<br />
<br />
For an overview of resource usage:<br />
<br />
$ systemd-cgtop<br />
<br />
== Tips and tricks ==<br />
<br />
=== Use an X environment ===<br />
<br />
See [[Xhost]] and [[Change root#Run graphical applications from chroot]].<br />
<br />
You will need to set the {{ic|DISPLAY}} environment variable inside your container session to connect to the external X server.<br />
<br />
X stores some required files in the {{ic|/tmp}} directory. In order for your container to display anything, it needs access to those files. To do so, append the {{ic|--bind<nowiki>=</nowiki>/tmp/.X11-unix:/tmp/.X11-unix}} option when starting the container.<br />
<br />
=== Run Firefox ===<br />
<br />
See [[Firefox tweaks#Run Firefox inside an nspawn container|Firefox tweaks]].<br />
<br />
=== Access host filesystem ===<br />
<br />
See {{ic|--bind}} and {{ic|--bind-ro}} in {{ic|man systemd-nspawn}}.<br />
<br />
If both the host and the container are Arch Linux, then one could, for example, share the pacman cache:<br />
<br />
# systemd-nspawn --bind=/var/cache/pacman/pkg<br />
<br />
Or you can specify per-container bind using the file:<br />
<br />
{{hc|/etc/systemd/nspawn/''my-container''.nspawn|<nowiki><br />
[Files]<br />
Bind=/var/cache/pacman/pkg<br />
</nowiki>}}<br />
<br />
See [[#Specify per-container settings]].<br />
<br />
=== Configure networking ===<br />
<br />
{{Style}}<br />
<br />
<br />
For the most simple setup, allowing outgoing connections to the internet, you can use [[systemd-networkd]] for network management and DHCP and {{ic|systemd-resolved}} for DNS.<br />
<br />
# systemctl enable --now systemd-networkd systemd-resolved<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf # let systemd-resolved manage /etc/resolv.conf<br />
<br />
This assumes you have started {{ic|systemd-nspawn}} with the {{ic|-n}} switch, creating a virtual Ethernet link to the host.<br />
<br />
Instead of using {{ic|systemd-resolved}} you can also manually [[textedit|edit]] your container's {{ic|/etc/resolv.conf}} by adding your DNS server's IP address.<br />
<br />
Note the canonical [[systemd-networkd]] host and container .network files are from https://github.com/systemd/systemd/tree/master/network .<br />
<br />
See [[systemd-networkd#Usage with containers]] for more complex examples.<br />
<br />
==== nsswitch.conf ====<br />
<br />
{{Merge|systemd-networkd}}<br />
<br />
To make it easier to connect to a container from the host, you can enable local DNS resolution for container names. In {{ic|/etc/nsswitch.conf}}, add {{ic|mymachines}} to the {{ic|hosts:}} section, e.g.<br />
<br />
hosts: files mymachines dns myhostname<br />
<br />
Then, any DNS lookup for hostname {{ic|foo}} on the host will first consult {{ic|/etc/hosts}}, then the names of local containers, then upstream DNS etc.<br />
<br />
==== Use host networking ====<br />
<br />
To disable private networking used by containers started with {{ic|machinectl start MyContainer}}, [[edit]] the configuration of {{ic|systemd-nspawn@.service}} with {{ic|systemctl edit systemd-nspawn@.service}} and set the {{ic|1=ExecStart=}} option without the {{ic|--network-veth}} parameter unlike the original service:<br />
<br />
{{hc|/etc/systemd/system/systemd-nspawn@.service.d/override.conf|<nowiki><br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --link-journal=try-guest --machine=%I<br />
</nowiki>}}<br />
<br />
The newly started containers will use the hosts networking.<br />
<br />
==== Virtual Ethernet interfaces ====<br />
<br />
If a container is started with {{ic|systemd-nspawn ... -n}}, systemd will automatically create one virtual Ethernet interface on the host, and one in the container, connected by a virtual Ethernet cable.<br />
<br />
If the name of the container is {{ic|foo}}, the name of the virtual Ethernet interface on the host is {{ic|ve-foo}}. The name of the virtual Ethernet interface in the container is always {{ic|host0}}.<br />
<br />
When examining the interfaces with {{ic|ip link}}, interface names will be shown with a suffix, such as {{ic|ve-foo@if2}} and {{ic|host0@if9}}. The {{ic|@ifN}} is not actually part of the name of the interface; instead, {{ic|ip link}} appends this information to indicate which "slot" the virtual Ethernet cable connects to on the other end.<br />
<br />
For example, a host virtual Ethernet interface shown as {{ic|ve-foo@if2}} will connect to container {{ic|foo}}, and inside the container to the second network interface -- the one shown with index 2 when running {{ic|ip link}} inside the container. Similarly, in the container, the interface named {{ic|host0@if9}} will connect to the 9th slot on the host.<br />
<br />
=== Run on a non-systemd system ===<br />
<br />
See [[Init#systemd-nspawn]].<br />
<br />
=== Specify per-container settings ===<br />
<br />
To specify per-container settings and not overrides for all (e.g. bind a directory to only one container)[https://github.com/systemd/systemd/issues/3442#issuecomment-223837408], the ".nspawn" file definition can be used [https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html#]<br />
<br />
man systemd.nspawn<br />
<br />
=== Use Btrfs subvolume as container root ===<br />
<br />
To use a [[Btrfs#Subvolumes|Btrfs subvolume]] as a template for the container's root, use the {{ic|--template}} flag. This takes a snapshot of the subvolume and populates the root directory for the container with it.<br />
<br />
{{Note|If the template path specified is not the root of a subvolume, the '''entire''' tree is copied. This will be very time consuming.}}<br />
<br />
For example, to use a snapshot located at {{ic|/.snapshots/403/snapshot}}:<br />
<br />
# systemd-nspawn --template=/.snapshots/403/snapshots -b -D ''my-container''<br />
<br />
where {{ic|''my-container''}} is the name of the directory that will be created for the container. After powering off, the newly created subvolume is retained.<br />
<br />
=== Use temporary Btrfs snapshot of container ===<br />
<br />
One can use the {{ic|--ephemeral}} or {{ic|-x}} flag to create a temporary btrfs snapshot of the container and use it as the container root. Any changes made while booted in the container will be lost. For example:<br />
<br />
# systemd-nspawn -D ''my-container'' -xb<br />
<br />
where ''my-container'' is the directory of an '''existing''' container or system. For example, if {{ic|/}} is a btrfs subvolume one could create an ephemeral container of the currently running host system by doing:<br />
<br />
# systemd-nspawn -D / -xb <br />
<br />
After powering off the container, the btrfs subvolume that was created is immediately removed.<br />
<br />
== Troubleshooting ==<br />
<br />
=== root login fails ===<br />
<br />
If you get the following error when you try to login (i.e. using {{ic|machinectl login <name>}}):<br />
<br />
arch-nspawn login: root<br />
Login incorrect<br />
<br />
And {{ic|journalctl}} shows:<br />
<br />
pam_securetty(login:auth): access denied: tty 'pts/0' is not secure !<br />
<br />
Add {{ic|pts/0}} to the list of terminal names in {{ic|/etc/securetty}} on the '''container''' filesystem, see [http://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty/41939#41939]. You can also opt to delete {{ic|/etc/securetty}} on the '''container''' to allow root to login to any tty, see [https://github.com/systemd/systemd/issues/852].<br />
<br />
=== Unable to upgrade some packages on the container ===<br />
<br />
It can sometimes be impossible to upgrade some packages on the container, {{Pkg|filesystem}} being a perfect example. The issue is due to {{ic|/sys}} being mounted as Read Only. The workaround is to remount the directory in Read Write when running {{ic|mount -o remount,rw -t sysfs sysfs /sys}}, do the upgrade then reboot the container.<br />
<br />
== See also ==<br />
<br />
* [[Getty#Nspawn_console|Automatic console login]]<br />
* [http://www.freedesktop.org/software/systemd/man/machinectl.html machinectl man page]<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html systemd-nspawn man page]<br />
* [http://lwn.net/Articles/572957/ Creating containers with systemd-nspawn]<br />
* [https://www.youtube.com/results?search_query=systemd-nspawn&aq=f Presentation by Lennart Pottering on systemd-nspawn]<br />
* [http://dabase.com/e/12009/ Running Firefox in a systemd-nspawn container]</div>Calinouhttps://wiki.archlinux.org/index.php?title=GIMP/CMYK_support&diff=433855GIMP/CMYK support2016-05-04T13:08:15Z<p>Calinou: </p>
<hr />
<div>[[Category:Image manipulation]]<br />
{{Related articles start}}<br />
{{Related|Using lprof to profile monitors}}<br />
{{Related articles end}}<br />
This article will show how to enable rudimentary CMYK support in Gimp using the Separate and Separate+ plug-ins, and explain how to use color proof filter to soft-proof your images. It will also cover more general topics on CMYK colors and DTP.<br />
<br />
== Before you read ==<br />
<br />
Before you install the Separate or Separate+ plug-in for Gimp, you need to know if you really need it.<br />
<br />
There has been much debate about the merits of using Gimp. Most of the heated discussions revolve around the fact that Gimp does not support CMYK mode. However, you have to understand that the topic is more important to DTP professionals than other users (photographers, web artists, home users). <br />
<br />
CMYK color model (or CMYK mode) is used mostly by DTP professionals that need to output images intended for commercial printing. For an average home user or even professional photographers, support for separating images using CMYK color is not necessary. <br />
<br />
Even when you see Cyan, Magenta, Yellow, and Black cartridges in your ink-jet or color laser printer, it doesn't mean that you need to feed it a CMYK file. In fact, most of them actually accept only RGB images or convert CMYK images to RGB internally.<br />
<br />
== Limitations ==<br />
<br />
Using the methods below has some limitations in comparison to proprietary tools. Namely, Separate+ and its predecessors have no support for GCR (Grey Component Replacement) and UCR (Undercolor Removal). Also, Separate plugin (not Separate+) has no support for clipping path, and there is no support for opening CMYK files in either Separate or Separate+.<br />
<br />
While undercolor removal is supported by Scribus, grey component replacement is not supported by any graphical tool on Linux as of this writing.<br />
<br />
=== What you will need ===<br />
<br />
You will need Gimp (of course), either Separate or Separate+ plugins, and ICC profiles. All of this can be installed from AUR.<br />
<br />
== About CMYK color model ==<br />
<br />
If you are not interested in the theory, you may skip straight to the heading on [[#About_CMYK_color_and_Gimp|CMYK color support in GIMP]].<br />
<br />
First off, the proper name for ''CMYK mode'', as it is commonly known, is ''[[wikipedia:CMYK|CMYK color model]]''. It is called a ''color model'', because it represents a standard way of describing colors.<br />
<br />
The color model is also called a ''subtractive'' color model, as opposed to ''additive'' (that is RGB) color model. Words additive and subtractive suggest that light, which is essential for perception of color, is either added or subtracted before it reaches the eye. The choice of primary colors is based on belief that the combination of Red, Green, and Blue (for RGB) or Cyan, Magenta, Yellow (for CMYK) produce the greatest range visible colors.<br />
<br />
Subtraction of light occurs when an ink absorbs part of the light that falls on it. The rest is reflected and reaches our eyes. Different inks absorb different parts of the light's spectrum, and the combination of C-M-Y inks yields the greatest range of different colors.<br />
<br />
Ideally, subtraction of all light, that is when Cyan, Magenta, and Yellow are mixed together at their full density, we should get black (i.e., no light reflected, fully absorbed by ink). However, this is usually not true in the real world because the inks are semi-transparent and the white paper below reflects some of the light. The use of additional Black ink in printing (''K'' in ''CMYK'' stands for Key, or blacK) is due to this fact. It adds the necessary density to the image and makes black a ''black''.<br />
<br />
When printing an image on a commercial press, it needs to be printed one primary (or Black) at a time. Therefore the original (usually a digital RGB image, or a printed photograph) needs to be separated into Cyan, Magenta, Yellow, and Black components.<br />
<br />
The lack of support for this kind of separation made Gimp unattractive to DTP professionals.<br />
<br />
== About ICC color profiles ==<br />
<br />
Since reproduction of both RGB and CMYK colors are specific to the device (or inks) used to produce images, a concept of color-spaces was invented. Color-spaces formulate the relationship of physical color and the color model that we use to describe them. Those relationships (functions) can be packaged as a file in the form of ICC profiles.<br />
<br />
The ICC profiles are used to describe the way colors are reproduced in a system, be it a monitor, a scanner, or a printing press. When separating images for press, we use the source profile (the color-space of the image to be separated) and the target profile (the color-space of the printing press the image is intended for).<br />
<br />
== About CMYK color and Gimp ==<br />
<br />
Gimp still lacks full CMYK color model support. The ability to separate and then ''edit'' an image in CMYK mode is still [http://wiki.gimp.org/index.php/Roadmap a long way down the list of features] to be added. However, there is a plug-in called ''Separate'' that offers a partial solution to the problem.<br />
<br />
Separate plugin has following abilities:<br />
<br />
* separate a RGB image<br />
* color management (using ICC profiles and lcms)<br />
* soft-proofing colors<br />
* attach ICC profiles to separated image files<br />
<br />
Separate+ plug-in has the same features as Separate, but it also has:<br />
<br />
* ability to convert from one RGB profile to another<br />
* duotone support<br />
<br />
Gimp itself offers a smaller set of CMYK-related functions:<br />
<br />
* display of CMYK values when using color picker<br />
* soft-proofing colors via Display Filters (not recommended)<br />
* soft-proofing colors via color management settings<br />
<br />
== Getting the software ==<br />
<br />
=== Separate plug-in for Gimp ===<br />
<br />
==== Installing using AUR ====<br />
<br />
Install {{AUR|gimp-plugin-separate}}{{Broken package link|{{aur-mirror|gimp-plugin-separate}}}}.<br />
<br />
==== Installing Separate manually ====<br />
<br />
Once you have obtained the [http://www.blackfiveservices.co.uk/linux_resources/separate-gimp2-0.3_linux.tar.gz source tarball], you can unpack it using the usual tar command:<br />
<br />
tar xvf separate-VERSION.tar.gz<br />
<br />
where VERSION would be the version of Separate plug-in (0.1 at the time of this writing).<br />
<br />
Copy a file called ''separate'' (located inside the extracted ''separate'' directory) into Gimp's plug-in directory:<br />
<br />
cp separate/separate /usr/lib/gimp/GIMPVERSION/plug-ins/<br />
<br />
where GIMPVERSION would be the major version number of Gimp (2.0 at the time of this writing).<br />
<br />
When you start Gimp the Separate will be recognized and reachable through ''Image > Separate'' menu.<br />
<br />
=== Separate+ plug-in ===<br />
<br />
==== Installing binary version from Painters Studio repository ====<br />
<br />
Painters Studio repository hosts binary packages for Separate+ plugin. To obtain the plugin, add one of the following two repositories to your pacman.conf:<br />
<br />
<pre><br />
[pst]<br />
Server = http://pst.brankovukelic.com/$arch<br />
</pre><br />
<br />
Then install the {{AUR|gimp-plugin-separate+}} package.<br />
<br />
==== Installing using AUR ====<br />
<br />
Install the {{AUR|gimp-plugin-separate+}} package.<br />
<br />
==== Installing manually ====<br />
<br />
To install manually, get the zip file from [http://sourceforge.jp/projects/separate-plus/downloads/42977/separate+-0.5.5.zip/ Sourceforge.jp download page], unpack it and issue the following commands:<br />
<br />
make<br />
sudo make install<br />
<br />
If you do not have [[sudo]] on your system, you can build like this:<br />
<br />
make<br />
su<br />
# Enter root password<br />
make install<br />
<br />
When you start Gimp the Separate+ will be reachable through ''Image > Separate'' menu.<br />
<br />
=== Install ICC profiles ===<br />
<br />
If you are using the Separate plug-in package from AUR, you already have the profiles installed. However, if you built Separate yourself, or you are using Separate+, you will need to install ICC profiles.<br />
<br />
==== Installing from AUR ====<br />
<br />
To install ICC profiles from AUR, you need to get {{AUR|eci-icc}} and/or {{AUR|adobe-icc}} packages (and optionally {{AUR|srgb-icc}}{{Broken package link|{{aur-mirror|srgb-icc}}}} package) and install them with [[makepkg]].<br />
<br />
==== Install manually ====<br />
<br />
Before you download and install profiles manually, you need to know that the standard location for ICC profiles is ''/usr/share/color/icc''. You have to create this directory and copy any profiles there. Another standard location is ''~/.color/icc''.<br />
<br />
You can obtain ICC profiles from [http://www.adobe.com/support/downloads/product.jsp?product=62&platform=windows Adobe] and [http://www.eci.org/doku.php?id=en:downloads ECI].<br />
<br />
Extract the downloaded zip file(s) and copy the contents of CMYK and RGB directories into one of the directories we have mentioned above.<br />
<br />
== Separating a RGB image ==<br />
<br />
Open an image in Gimp. From the ''Image'' menu, open the ''Separate'' sub-menu and pick ''Separate (to Colour)''.<br />
<br />
Choose a source (RGB) and destination (target, CMYK) profile and click ''OK''.<br />
<br />
This will open another window with the CMYK color version. You can see that there are 5 layers total.<br />
<br />
Pick ''Save...'' (or ''Export...'' in Separate+) from the ''Separate'' sub-menu and save the file in TIFF format with an attached (embedded) ICC profile.<br />
<br />
You can only separate flattened images, so it is recommended that you save a new copy of the image before you create the CMYK TIFF.<br />
<br />
== Working on a separated image ==<br />
<br />
If you want to work on a separated image you need to be intimately familiar with the way CMYK images work. If you look at Gimp's Layers window after separating an image, you will witness the ingenious way in which the separation is done. However, editing the image is not as simple as with proprietary software like Adobe's Photoshop.<br />
<br />
Basically, you need to work with grayscale values of each primary color (plus Black). All the tools are available, but you only get apply them layer by layer and in grayscale.<br />
<br />
== Soft-proofing with Display Filters ==<br />
<br />
Given the circumstances, the best way to create a solid CMYK image would be to work in RGB mode, but enable soft-proofing. Soft-proofing is the method of adjusting the on-screen display of colors to match the final print. In the newer versions of The GIMP, soft-proofing is made possible via Display Filters.<br />
<br />
Go to the ''View'' menu and pick ''Display Filters...'' option. From the list of available filters, pick ''Color Proof'' (at the bottom in The GIMP version 2.2.13). Click on the right arrow button between the two lists and the ''Color Proof'' filter will be placed into the list of active filters. Click on it (the one in the active filters list) and you will get a few options below.<br />
<br />
Although this seems very convenient, experience has proven that this is '''not''' a reliable method of soft-proofing. Instead of soft-proofing using the display filter, you are advised to properly configure Gimp's color management system and enable the ''Print simulation'' mode.<br />
<br />
=== Intent ===<br />
<br />
The color proof (rendering) intent can be one of the following:<br />
<br />
* perceptual<br />
* relative colorimetric<br />
* saturation<br />
* absolute colorimetric<br />
<br />
''Perceptual'' and ''relative colorimetric'' are most common.<br />
<br />
Perceptual compresses or expands the full color range of source color-space into the full color range of target color-space.<br />
<br />
Relative colorimetric intent adjusts the white (white point) of source space and then adjusts the rest of the source colors accordingly. Source colors outside the target space are mapped to closest reproducible colors. In some software, this is also called ''proof intent''.<br />
<br />
Saturation intent keeps the saturation of the source colors even if the colors get distorted in the target space. This intent is still considered experimental and you may get unexpected (if not undesirable) results.<br />
<br />
Absolute colorimetric leaves overlap of source and target space intact and maps source colors outside the target space are mapped to closest reproducible colors.<br />
<br />
=== Profile ===<br />
<br />
For color proofing, we usually use the profile of the device that image is to be printed on. For testing purposes, you may use any of the Adobe profiles [[#Install ICC profiles|mentioned above]].<br />
<br />
== Soft-proofing with Separate's proof function ==<br />
<br />
Separate itself offers a way of soft-proofing color. This method of soft-proofing is not dynamic: it does not update as you edit the image, but acts more like a one-time preview. However, it is far more accurate than The GIMP's soft-proofing using ''Color Proof'' display filter. Basically, the proof function converts the image to RGB space using ''absolute colorimetric'' intent. It is supposed to offer a side-by-side match to the printed copy.<br />
<br />
To soft-proof with Separate's proof function, you first [[#Separating a RGB image|separate an image]] and then pick ''Proof'' from ''Separate'' sub-menu. Source profile is your minitor's RGB profile (you can use [[Using LPROF to profile monitors|lprof to profile your monitor]] and create an ICC profile). The destination profile is the ICC profile of a your image will be output to.<br />
<br />
Click ''OK'' and you will be presented with an RGB image of how the printed image would look like.<br />
<br />
== Soft-proofing with Separate+'s proof function ==<br />
<br />
Separate+ acts the same way as Separate.<br />
<br />
== What RGB profile to use for images? ==<br />
<br />
Although Adobe RGB is a common profile, sRGB profiles (especially the new v4 version also [https://aur.archlinux.org/packages.php?ID=32999 available in the AUR]) is also used often.<br />
<br />
== See also ==<br />
<br />
* [[wikipedia:CMYK|About CMYK color model (Wikipedia)]]<br />
* [[wikipedia:Color|About color in general (Wikipedia)]]<br />
* [http://www.color.org/ International Color Consortium (ICC home page)]<br />
* [[wikipedia:Color_management|About color management (Wikipedia)]]<br />
* [http://www.color.org/iccprofile.html Introduction to ICC color profile format (ICC home page)]<br />
* [http://www.brankovukelic.com/post/513356271/gimp-color-management-for-dtp Gimp Color Management for DTP (Foxbunny's Journal)]<br />
* [http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm Color Management: Color Space Conversion (Cambridge in Color)]<br />
* [http://graphics.tech.uh.edu/student_work/color_rendering_intent/gcr.html Grey Component Removal (Color Rendering Intent)]<br />
* [http://graphics.tech.uh.edu/student_work/color_rendering_intent/ucr.html Undercolor Removal (Color Rendering Intent)]<br />
<br />
'''Related software:'''<br />
* [http://www.gimp.org/ Gimp (v2.0 and above)]<br />
* [http://www.littlecms.com/ lcms (v1.15)]<br />
* [http://www.blackfiveservices.co.uk/separate.shtml Separate plugin (v0.10 and above)]<br />
* [http://cue.yellowmagic.info/softwares/separate-plus/ Separate+ plugin (v0.5.5)]<br />
* [http://www.blackfiveimaging.co.uk/index.php?article=02Software%2F05CMYKTool cmyktool] is a standalone program for soft-proofing in CMYK which may be useful if you need to send CMYK to a printer (especially where you want to tweak pure black to avoid halos)</div>Calinouhttps://wiki.archlinux.org/index.php?title=Certbot&diff=433584Certbot2016-05-01T20:39:33Z<p>Calinou: ssl -> SSL</p>
<hr />
<div>[[Category:Networking]]<br />
[[Category:Encryption]]<br />
[[ja:Let’s Encrypt]]<br />
[https://letsencrypt.org/ Let’s Encrypt] is a free, automated, and open certificate authority utilizing the ACME protocol. It provides tools to request valid SSL certificates straight from the command line.<br />
<br />
== Installation ==<br />
<br />
To obtain the official client [[install]] the {{Pkg|letsencrypt}} package.<br />
<br />
A minimal client with manual CSR creation is available at {{AUR|acme-tiny}}. More integrated clients suitable for scripts are e.g. {{AUR|simp_le-git}} and {{AUR|letsencrypt-cli}}.<br />
<br />
The official client provides plugins for automated configuration and installation of the issued certificates in web servers:<br />
* The experimental plugin for [[Nginx]] is provided with the {{Pkg|letsencrypt-nginx}} package.<br />
* Although a package {{Pkg|letsencrypt-apache}} exists, automated installation using the [[Apache HTTP Server]] is currently only supported on Debian and derivatives.<br />
<br />
== Configuration ==<br />
<br />
Please consult the [https://letsencrypt.readthedocs.org/en/latest/ Let’s Encrypt client documentation] on how to create and install certificates. This wiki will be expanded as soon as certificate installation methods have been crystallized out.<br />
<br />
=== Manual ===<br />
<br />
{{Note|With this method, you must temporarily stop your web server. You can also run the verification through your already running web server with the [[#Webroot]] method.}}<br />
<br />
If there is no plugin for your web server, use the following command:<br />
# letsencrypt certonly --manual<br />
<br />
This will automatically verify your domain and create a private key and certificate pair. These are placed in {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
You can then manually configure your web server to use the key and certificate in that directory.<br />
<br />
=== Webroot ===<br />
<br />
The webroot method lets the client place a challenge response at {{ic|yourdomain.tld/.well-known/acme-challenge/}}.<br />
You can use it to get/renew certificates with a running webserver (e.g. Apache/nginx).<br />
# letsencrypt certonly --email ''email@example.com'' --webroot -w ''/path/to/html/'' -d ''your.domain''<br />
<br />
Make sure the server configuration for the certificates points to {{ic|/etc/letsencrypt/live/''your.domain''/}}.<br />
<br />
If you use more than one domain or subdomains, the webroot has to be given for every domain. If no new webroot is given, the previous is taken.<br />
<br />
Management of this can be made much easier, if you instruct you map all http requests for {{ic|/.well-known/acme-challenge/}} to a single folder, e.g. {{ic|/var/lib/letsencrypt}}.<br />
For nginx you can achieve this with a location block, placed e.g. in {{ic|ssl.conf}}:<br />
{{hc|ssl.conf|<nowiki><br />
location /.well-known/acme-challenge {<br />
alias /var/lib/letsencrypt;<br />
default_type "text/plain";<br />
try_files $uri =404;<br />
}</nowiki>}}<br />
For apache you can achieve this by creating the file {{ic|httpd-acme.conf}}:<br />
{{hc|/etc/httpd/conf/extra/httpd-acme.conf|<nowiki><br />
Alias /.well-known/acme-challenge/ "/var/lib/letsencrypt/.well-known/acme-challenge/"<br />
<Directory "/var/lib/letsencrypt/"><br />
AllowOverride None<br />
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec<br />
Require method GET POST OPTIONS<br />
</Directory><br />
</nowiki>}}<br />
and including it in {{ic|httpd.conf}}:<br />
{{hc|/etc/httpd/conf/httpd.conf|<nowiki><br />
Include conf/extra/httpd-acme.conf<br />
</nowiki>}}<br />
The chosen path has then to be writable for the chosen letsencrypt client. It also has to be readable by the web server; you can achieve this thereby : {{ic|chgrp http /val/lib/letsencrypt && chmod g+s /var/lib/letsencrypt}}.<br />
<br />
==== Automatic renewal ====<br />
<br />
When running {{ic|letsencrypt certonly}}, letsencrypt stores the domains and webroot directories in {{ic|/etc/letsencrypt/renewal}}, so the certificates can be renewed later automatically by running {{ic|letsencrypt renew}}.<br />
<br />
You can fully automate this by creating the following systemd service file:<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.service|<br />
2=[Unit]<br />
Description=Let's Encrypt renewal<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/letsencrypt renew}}<br />
<br />
Before adding a [[systemd/Timers|timer]], check that the service is working correctly and is not trying to prompt anything.<br />
<br />
Then, you can add a timer to renew the certificates monthly.<br />
<br />
{{hc|1=/etc/systemd/system/letsencrypt.timer|<br />
2=[Unit]<br />
Description=Monthly renewal of Let's Encrypt's certificates<br />
<br />
[Timer]<br />
OnCalendar=monthly<br />
Persistent=true<br />
<br />
[Install]<br />
WantedBy=timers.target}}<br />
<br />
[[Enable]] and [[start]] {{ic|letsencrypt.timer}}.<br />
<br />
You'll probably want your web server to be restarted after each certificate renewal. You can realize that by adding one of these lines to the {{ic|letsencrypt.service}} file:<br />
<br />
* Apache: {{ic|1=ExecStartPost=/bin/systemctl reload httpd.service}}<br />
* nginx: {{ic|1=ExecStartPost=/bin/systemctl restart nginx.service}}<br />
<br />
== See also ==<br />
<br />
* [https://community.letsencrypt.org/t/list-of-client-implementations/2103 List of ACME clients]</div>Calinouhttps://wiki.archlinux.org/index.php?title=NVIDIA&diff=235739NVIDIA2012-11-16T22:22:38Z<p>Calinou: rm. totally wrong warning</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[cs:NVIDIA]]<br />
[[de:Nvidia]]<br />
[[es:NVIDIA]]<br />
[[fa:اِنویدیا]]<br />
[[fr:Nvidia]]<br />
[[it:NVIDIA]]<br />
[[ja:NVIDIA]]<br />
[[nl:NVIDIA]]<br />
[[ru:NVIDIA]]<br />
[[tr:Nvidia]]<br />
[[zh-CN:NVIDIA]]<br />
{{Article summary start}}<br />
{{Article summary text|Information on installing, configuring and troubleshooting the proprietary NVIDIA Drivers.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Nouveau}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary end}}<br />
<br />
This article covers installing and configuring [http://www.nvidia.com NVIDIA]'s ''proprietary'' graphic card driver. For information about the open-source drivers, see [[Nouveau]].<br />
<br />
==Installing==<br />
These instructions are for those using the stock {{Pkg|linux}} package. For custom kernel setup, skip to the [[#Alternate install: custom kernel|next]] subsection.<br />
<br />
{{Tip|It is usually beneficial to install the NVIDIA driver through [[pacman]] rather than through the package provided by the NVIDIA site, this allows the driver to be updated when upgrading the system.}}<br />
<br />
1. Visit NVIDIA's [http://www.nvidia.com/Download/index.aspx?lang=en-us driver download site] to find out the appropriate driver for a given card. You could also check the [http://www.nvidia.com/object/IO_32667.html legacy card list].<br />
<br />
:{{Note|For the very latest GPU models, it may be required to install {{AUR|nvidia-beta}} from the [[Arch User Repository]], since the stable drivers may not support the newly introduced features. Try the stable ones first (see below).}}<br />
<br />
2. Install the appropriate driver for your card:<br />
:* For GeForce 8 series and newer [NVC0 and newer] cards, install {{Pkg|nvidia}} package, available in the [[Official Repositories|official repositories]].<br />
:* For GeForce 6/7 series cards [NV40-NVAF], install {{Pkg|nvidia-304xx}} package, available in the [[Official Repositories|official repositories]].<br />
:* For GeForce 5 FX series cards [NV30-NV38], install {{AUR|nvidia-173xx}} package, available in the [[Arch User Repository|AUR]].<br />
:* For GeForce 2/3/4 MX/Ti series cards [NV11 and NV17-NV28], install {{AUR|nvidia-96xx}} package, available in the [[Arch User Repository|AUR]].<br />
<br />
:The ''nvidia{,-173xx,-96xx}-utils'' package is a dependency and will be pulled in automatically. It may conflict with the ''libgl'' package; this is normal. If pacman asks to remove ''libgl'' and fails due to unsatisfied dependencies, remove it with {{ic|pacman -Rdd libgl}}.<br />
<br />
:The ''nvidia-96xx-utils'' package requires a legacy X.Org server release ({{AUR|xorg-server1.12}}). It conflicts with the ''xorg-server'' from the official repositories.<br />
<br />
:{{Note|For [[multilib|Arch x86_64]] you must also install the equivalent ''lib32'' package (e.g. {{Pkg|lib32-nvidia-utils}} or {{AUR|lib32-nvidia-utils-beta}}).}}<br />
<br />
3. '''Reboot'''. The ''nvidia'' package contains a file which blacklists the ''nouveau'' module, so rebooting is necessary.<br />
<br />
Once the driver has been installed, continue to: [[#Configuring]].<br />
<br />
===Alternate install: custom kernel===<br />
<br />
First of all, it's good to know how the ABS works by reading some of the other articles about it:<br />
<br />
* Main article for [[Arch Build System|ABS]]<br />
* Article on [[makepkg]]<br />
* Article on [[Creating Packages]]<br />
<br />
{{Note|You can also find the {{AUR|nvidia-all}} package in [[Arch User Repository|AUR]] which makes it easier to use with custom kernels and multiple kernels.}}<br />
<br />
The following is a short tutorial for making a custom NVIDIA driver package using [[ABS]]:<br />
<br />
[[Pacman|Install]] {{Pkg|abs}} from the [[Official Repositories|official repositories]] and generate the tree with:<br />
# abs<br />
As a standard user, make a temporary directory for creating the new package:<br />
$ mkdir -p ~/abs<br />
Make a copy of the {{ic|nvidia}} package directory:<br />
$ cp -r /var/abs/extra/nvidia/ ~/abs/<br />
Go into the temporary {{ic|nvidia}} build directory:<br />
$ cd ~/abs/nvidia<br />
It is required to edit the files {{ic|nvidia.install}} and {{ic|PKGBUILD}} file so that they contain the right kernel version variables.<br />
<br />
While running the custom kernel, get the appropriate kernel and local version names:<br />
$ uname -r<br />
# In nvidia.install, replace the {{ic|EXTRAMODULES<nowiki>=</nowiki>'extramodules-3.4-ARCH'}} variable with the custom kernel version, such as {{ic|EXTRAMODULES<nowiki>=</nowiki>'extramodules-3.4.4'}} or {{ic|EXTRAMODULES<nowiki>=</nowiki>'extramodules-3.4.4-custom'}} depending on what the kernel's version is and the local version's text/numbers. Do this for all instances of the version number within this file.<br />
# In PKGBUILD, change the {{ic|_extramodules<nowiki>=</nowiki>extramodules-3.4-ARCH}} variable to match the appropriate version, as above.<br />
# If there are more than one kernels in the system installed in parallel (such as a custom kernel alongside the default -ARCH kernel), change the {{ic|pkgname<nowiki>=</nowiki>nvidia}} variable in the PKGBUILD to a unique identifier, such as nvidia-344 or nvidia-custom. This will allow both kernels to use the nvidia module, since the custom nvidia module has a different package name and will not overwrite the original. You will also need to comment the line in {{ic|package()}} that blacklists the nvidia module in {{ic|/usr/lib/modprobe.d/nvidia.conf}} (no need to do it again).<br />
<br />
Then do:<br />
$ makepkg -ci<br />
The {{ic|-c}} operand tells makepkg to clean left over files after building the package, whereas {{ic|-i}} specifies that makepkg should automatically run pacman to install the resulting package.<br />
<br />
===Automatic re-compilation of the NVIDIA module with every update of any kernel===<br />
<br />
This is possible thanks to {{AUR|nvidia-hook}} from the [[AUR]]. You will need to install the module sources: either {{AUR|nvidia-source}} for the stable drivers or {{AUR|nvidia-source-beta}} for the beta drivers. In '''nvidia-hook''', the 'automatic re-compilation' functionality is done by a '''nvidia hook''' on [[mkinitcpio]] after forcing to update the '''linux-headers''' package. You will need to add 'nvidia' to the HOOKS array in /etc/mkinitcpio.conf as well as 'linux-headers' and your custom kernel(s) headers to the SyncFirst array in /etc/pacman.conf for this to work.<br />
<br />
The hook will call the '''dkms''' command to update the NVIDIA module for the version of your new kernel.<br />
<br />
{{Note|If you are using this functionality it's '''important''' to look at the installation process of the linux (or any other kernel) package. nvidia hook will tell you if anything goes wrong.}}<br />
{{Note|When upgrading kernels, the old modules located in {{ic|/usr/lib/modules}} have to be removed by hand.}}<br />
<br />
==Configuring==<br />
It is possible that after installing the driver it may not be needed to create an Xorg server configuration file. You can run [[Xorg#Running| a test]] to see if the Xorg server will function correctly without a configuration file. However, it may be required to create a {{ic|/etc/X11/xorg.conf}} configuration file in order to adjust various settings. This configuration can be generated by the NVIDIA Xorg configuration tool, or it can be created manually. If created manually, it can be a minimal configuration (in the sense that it will only pass the basic options to the [[Xorg]] server), or it can include a number of settings that can bypass Xorg's auto-discovered or pre-configured options.<br />
:{{Note|Since 1.8.x Xorg uses separate configuration files in {{ic|/etc/X11/xorg.conf.d/}} - check out [[NVIDIA#Advanced:_20-nvidia.conf|advanced configuration]] section.}}<br />
<br />
===Automatic configuration===<br />
The NVIDIA package includes an automatic configuration tool to create an Xorg server configuration file ({{ic|xorg.conf}}) and can be run by:<br />
# nvidia-xconfig<br />
<br />
This command will auto-detect and create (or edit, if already present) the {{ic|/etc/X11/xorg.conf}} configuration according to present hardware.<br />
<br />
If there are instances of DRI, ensure they are commented out:<br />
# Load "dri"<br />
Double check your {{ic| /etc/X11/xorg.conf}} to make sure your default depth, horizontal sync, vertical refresh, and resolutions are acceptable.<br />
<br />
{{Warning| That may still not work properly with Xorg-server 1.8 }}<br />
<br />
===Minimal configuration===<br />
A basic {{ic|xorg.conf}} would look like this:<br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
EndSection<br />
}}<br />
<br />
{{Tip|If upgrading from nouveau make sure to remove "{{ic|nouveau}}" from {{ic|/etc/mkinitcpio.conf}}. See [[NVIDIA#Switching between nvidia and nouveau drivers]], if switching between the open and proprietary drivers often.}}<br />
<br />
=== Multiple monitors ===<br />
:''See [[Multihead]] for more general information''<br />
<br />
To activate dual screen support, you just need to edit the {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}} file which you made before.<br />
<br />
Per each physical monitor, add one Monitor, Device, and Screen Section entry, and then a ServerLayout section to manage it. Be advised that when Xinerama is enabled, the NVIDIA proprietary driver automatically disables compositing. If you desire compositing, you should comment out the {{ic|Xinerama}} line in "{{ic|ServerLayout}}" and use TwinView (see below) instead.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "ServerLayout"<br />
Identifier "DualSreen"<br />
Screen 0 "Screen0"<br />
Screen 1 "Screen1" RightOf "Screen0" #Screen1 at the right of Screen0<br />
Option "Xinerama" "1" #To move windows between screens<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "nvidia"<br />
Screen 0<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device1"<br />
Driver "nvidia"<br />
Screen 1<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Device0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1280x800_75.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "Device1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
====TwinView====<br />
You want only one big screen instead of two. Set the {{ic|TwinView}} argument to {{ic|1}}. This option should be used instead of Xinerama (see above), if you desire compositing.<br />
Option "TwinView" "1"<br />
<br />
TwinView only works on a per card basis: If you have multiple cards (and no SLI?), you'll have to use xinerama or zaphod mode (multiple X screens). You can combine TwinView with zaphod mode, ending up, for example, with two X screens covering two monitors each. Most window managers fail miserably in zaphod mode. The shining exception is Awesome. KDE almost works.<br />
<br />
Example configuration:<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "ServerLayout"<br />
Identifier "TwinLayout"<br />
Screen 0 "metaScreen" 0 0<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
<br />
#refer to the link below for more information on each of the following options.<br />
Option "HorizSync" "DFP-0: 28-33; DFP-1 28-33"<br />
Option "VertRefresh" "DFP-0: 43-73; DFP-1 43-73"<br />
Option "MetaModes" "1920x1080, 1920x1080"<br />
Option "ConnectedMonitor" "DFP-0, DFP-1"<br />
Option "MetaModeOrientation" "DFP-1 LeftOf DFP-0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "metaScreen"<br />
Device "Card0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "True"<br />
SubSection "Display"<br />
Modes "1920x1080"<br />
EndSubSection<br />
EndSection<br />
}}<br />
<br />
[http://us.download.nvidia.com/XFree86/Linux-x86/304.51/README/configtwinview.html Device Option information]<br />
<br />
=====Automatic configuration =====<br />
The NVIDIA package provides Twinview. This tool will help by automatically configuring all the monitors connected to your video card. This only works for multiple monitors on a single card.<br />
To configure Xorg Server with Twinview run:<br />
# nvidia-xconfig --twinview<br />
<br />
=====Manual CLI configuration with xrandr=====<br />
If the latest solutions doesn't works for you, you can use the ''autostart'' trick of your window manager to run a {{ic|xrandr}} command like this one :<br />
<br />
xrandr --output DVI-I-0 --auto --primary --left-of DVI-I-1<br />
<br />
or<br />
<br />
xrandr --output DVI-I-1 --pos 1440x0 --mode 1440x900 --rate 75.0<br />
<br />
When:<br />
<br />
* {{ic|--output}} is used to indicate to which "monitor" set the options.<br />
* {{ic|DVI-I-1}} is the name of the second monitor.<br />
* {{ic|--pos}} is the position of the second monitor respect to the first.<br />
* {{ic|--mode}} is the resolution of the second monitor.<br />
* {{ic|--rate}} is the Hz refresh rate.<br />
<br />
You must adapt the {{ic|xrandr}} options with the help of the output of the command {{ic|xrandr}} run alone in a terminal.<br />
<br />
====Using NVIDIA Settings====<br />
You can also use the {{ic|nvidia-settings}} tool provided by {{Pkg|nvidia-utils}}. With this method, you will use the proprietary software NVIDIA provides with their drivers. Simply run {{ic|nvidia-settings}} as root, then configure as you wish, and then save the configuration to {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
<br />
====ConnectedMonitor====<br />
If the driver doesn't properly detect a second monitor, you can force it to do so with ConnectedMonitor. <br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
VendorName "Panasonic"<br />
ModelName "Panasonic MICRON 2100Ex"<br />
HorizSync 30.0 - 121.0 # this monitor has incorrect EDID, hence Option "UseEDIDFreqs" "false"<br />
VertRefresh 50.0 - 160.0<br />
Option "DPMS"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor2"<br />
VendorName "Gateway"<br />
ModelName "GatewayVX1120"<br />
HorizSync 30.0 - 121.0<br />
VertRefresh 50.0 - 160.0<br />
Option "DPMS"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device1"<br />
Driver "nvidia"<br />
Option "NoLogo"<br />
Option "UseEDIDFreqs" "false"<br />
Option "ConnectedMonitor" "CRT,CRT"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce 6200 LE"<br />
BusID "PCI:3:0:0"<br />
Screen 0<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device2"<br />
Driver "nvidia"<br />
Option "NoLogo"<br />
Option "UseEDIDFreqs" "false"<br />
Option "ConnectedMonitor" "CRT,CRT"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce 6200 LE"<br />
BusID "PCI:3:0:0"<br />
Screen 1<br />
EndSection<br />
<br />
}}<br />
<br />
The duplicated device with {{ic|Screen}} is how you get X to use two monitors on one card without {{ic|TwinView}}. Note that {{ic|nvidia-settings}} will strip out any {{ic|ConnectedMonitor}} options you have added.<br />
<br />
==Tweaking==<br />
<br />
===GUI: nvidia-settings===<br />
The NVIDIA package includes the {{ic|nvidia-settings}} program that allows adjustment of several additional settings.<br />
<br />
For the settings to be loaded on login, run this command from the terminal:<br />
$ nvidia-settings --load-config-only<br />
<br />
Or add it to the the desktop environment's auto-startup method.<br />
<br />
For a dramatic 2D graphics performance increase in pixmap-intensive applications, e.g. Firefox, set the {{ic|InitialPixmapPlacement}} parameter to 2:<br />
<br />
$ nvidia-settings -a InitialPixmapPlacement=2<br />
<br />
This is documented in [http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/src/libXNVCtrl/NVCtrl.h?id=b27db3d10d58b821e87fbe3f46166e02dc589855#n2797 nvidia-settings source code]. For this setting to persist, this command needs to be run on every startup or added to your {{ic|~/.nvidia-settings-rc}}.<br />
<br />
{{Tip | On rare occasions the {{ic|~/.nvidia-settings-rc}} may become corrupt. If this happens, the Xorg server may crash and the file will have to be deleted to fix the issue.}}<br />
<br />
===Enabling MSI (Message Signaled Interrupts)===<br />
By default, the graphics card uses a shared interrupt system. To give a small performance boost, edit {{ic|/etc/modprobe.d/modprobe.conf}} and add:<br />
options nvidia NVreg_EnableMSI=1<br />
Be warned, as this has been known to damage some systems running older hardware! <br />
<br />
To confirm, run:<br />
# cat /proc/interrupts | grep nvidia<br />
43: 0 49 4199 86318 PCI-MSI-edge nvidia<br />
<br />
===Advanced: 20-nvidia.conf===<br />
Edit {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}}, and add the option to the correct section. The Xorg server will need to be restarted before any changes are applied.<br />
<br />
* See [http://http.download.nvidia.com/XFree86/Linux-x86/304.51/README/ NVIDIA Accelerated Linux Graphics Driver README and Installation Guide] for additional details and options.<br />
====Enabling desktop composition====<br />
As of NVIDIA driver version 180.44, support for GLX with the Damage and Composite X extensions is enabled by default. Refer to [[Xorg#Composite]] for detailed instructions.<br />
<br />
====Disabling the logo on startup====<br />
Add the {{ic|"NoLogo"}} option under section {{ic|Device}}:<br />
Option "NoLogo" "1"<br />
<br />
====Enabling hardware acceleration====<br />
{{Note|RenderAccel is enabled by default since drivers version 97.46.xx}}<br />
Add the {{ic|"RenderAccel"}} option under section {{ic|Device}}:<br />
Option "RenderAccel" "1"<br />
<br />
====Overriding monitor detection====<br />
The {{ic|"ConnectedMonitor"}} option under section {{ic|Device}} allows to override monitor detection when X server starts, which may save a significant amount of time at start up. The available options are: {{ic|"CRT"}} for analog connections, {{ic|"DFP"}} for digital monitors and {{ic|"TV"}} for televisions.<br />
<br />
The following statement forces the NVIDIA driver to bypass startup checks and recognize the monitor as DFP:<br />
Option "ConnectedMonitor" "DFP"<br />
{{Note| Use "CRT" for all analog 15 pin VGA connections, even if the display is a flat panel. "DFP" is intended for DVI digital connections only.}}<br />
<br />
====Enabling triple buffering====<br />
Enable the use of triple buffering by adding the {{ic|"TripleBuffer"}} Option under section {{ic|Device}}:<br />
Option "TripleBuffer" "1"<br />
<br />
Use this option if the graphics card has plenty of ram (equal or greater than 128MB). The setting only takes effect when syncing to vblank is enabled, one of the options featured in nvidia-settings.<br />
<br />
{{Note|This option may introduce full-screen tearing and reduce performance. As of the R300 drivers, vblank is enabled by default.}}<br />
<br />
====Using OS-level events====<br />
Taken from the NVIDIA driver's [http://http.download.nvidia.com/XFree86/Linux-x86/304.51/README/xconfigoptions.html README] file: ''"[...] Use OS-level events to efficiently notify X when a client has performed direct rendering to a window that needs to be composited."'' It may help improving performance, but it is currently incompatible with SLI and Multi-GPU modes.<br />
<br />
Add under section {{ic|Device}}:<br />
Option "DamageEvents" "1"<br />
{{Note|This option is enabled by default in newer driver versions.}}<br />
<br />
====Enabling power saving====<br />
Add under section {{ic|Monitor}}:<br />
Option "DPMS" "1"<br />
<br />
====Enabling Brightness Control====<br />
Add under section {{ic|Device}}:<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
<br />
====Enabling SLI====<br />
{{Warning|As of May 7, 2011, you may experience sluggish video performance in GNOME 3 after enabling SLI.}}<br />
<br />
Taken from the NVIDIA driver's [http://http.download.nvidia.com/XFree86/Linux-x86/304.51/README/xconfigoptions.html README] appendix: ''This option controls the configuration of SLI rendering in supported configurations.'' A "supported configuration" is a computer equipped with an SLI-Certified Motherboard and 2 or 3 SLI-Certified GeForce GPUs. See NVIDIA's [http://www.slizone.com/page/home.html SLI Zone] for more information.<br />
<br />
Find the first GPU's PCI Bus ID using {{ic|lspci}}:<br />
$ lspci | grep VGA<br />
<br />
This will return something similar to:<br />
03:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
05:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GTS 512] (rev a2)<br />
<br />
Add the BusID (3 in the previous example) under section {{ic|Device}}:<br />
BusID "PCI:3:0:0"<br />
<br />
{{Note|The format is important. The BusID value must be specified as {{ic|"PCI:<BusID>:0:0"}}}}<br />
<br />
Add the desired SLI rendering mode value under section {{ic|Screen}}:<br />
Option "SLI" "SLIAA"<br />
<br />
The following table presents the available rendering modes.<br />
<br />
{| border="1"<br />
! Value !! Behavior<br />
|-<br />
| 0, no, off, false, Single || Use only a single GPU when rendering.<br />
|-<br />
| 1, yes, on, true, Auto || Enable SLI and allow the driver to automatically select the appropriate rendering mode.<br />
|-<br />
| AFR || Enable SLI and use the alternate frame rendering mode.<br />
|-<br />
| SFR || Enable SLI and use the split frame rendering mode.<br />
|-<br />
| SLIAA || Enable SLI and use SLI antialiasing. Use this in conjunction with full scene antialiasing to improve visual quality.<br />
|}<br />
<br />
Alternatively, you can use the {{ic|nvidia-xconfig}} utility to insert these changes into {{ic|xorg.conf}} with a single command:<br />
# nvidia-xconfig --busid=PCI:3:0:0 --sli=SLIAA<br />
<br />
To verify that SLI mode is enabled from a shell:<br />
$ nvidia-settings -q all | grep SLIMode<br />
Attribute 'SLIMode' (arch:0.0): AA <br />
'SLIMode' is a string attribute.<br />
'SLIMode' is a read-only attribute.<br />
'SLIMode' can use the following target types: X Screen.<br />
<br />
====Forcing Powermizer performance level (for laptops)====<br />
Add under section {{ic|Device}}:<br />
# Force Powermizer to a certain level at all times<br />
# level 0x1=highest<br />
# level 0x2=med<br />
# level 0x3=lowest<br />
<br />
# AC settings:<br />
Option "RegistryDwords" "PowerMizerLevelAC=0x3"<br />
# Battery settings:<br />
Option "RegistryDwords" "PowerMizerLevel=0x3"<br />
Settings are better explained in [http://tutanhamon.com.ua/technovodstvo/NVIDIA-UNIX-driver/ NVIDIA Driver for X.org:Performance and Power Saving Hints].<br />
<br />
=====Letting the GPU set its own performance level based on temperature=====<br />
Add under section {{ic|Device}}:<br />
Option "RegistryDwords" "PerfLevelSrc=0x3333"<br />
<br />
====Disable vblank interrupts (for laptops)====<br />
When running the interrupt detection utility [[powertop]], it can be observed that the Nvidia driver will generate an interrupt for every vblank. To disable, place in the {{ic|Device}} section:<br />
Option "OnDemandVBlankInterrupts" "1"<br />
This will reduce interrupts to about one or two per second.<br />
<br />
====Enabling overclocking====<br />
{{Warning|Please note that overclocking may damage hardware and that no responsibility may be placed on the authors of this page due to any damage to any information technology equipment from operating products out of specifications set by the manufacturer.}}<br />
To enable GPU and memory overclocking, place the following line in the {{ic|Device}} section:<br />
Option "Coolbits" "1"<br />
<br />
This will enable on-the-fly overclocking within an X session by running:<br />
$ nvidia-settings<br />
{{Note|GTX 4xx/5xx series Fermi cores cannot currently be overclocked using <br />
the Coolbits method. The alternative is to edit and reflash the GPU BIOS either under DOS (preferred), or within a Win32 environment by way of [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,127/orderby,2/page,1/ nvflash] and [http://www.mvktech.net/component/option,com_remository/Itemid,26/func,select/id,135/orderby,2/page,1/ NiBiTor 6.0]. The advantage of BIOS flashing is that not only can voltage limits be raised, but stability is generally improved over software overclocking methods such as Coolbits.}}<br />
<br />
===== Setting static 2D/3D clocks =====<br />
Set the following string in the {{ic|Device}} section to enable PowerMizer at its maximum performance level:<br />
Option "RegistryDwords" "PerfLevelSrc=0x2222"<br />
Set one of the following two strings in the {{ic|Device}} section to enable manual GPU fan control within {{ic|nvidia-settings}}:<br />
Option "Coolbits" "4"<br />
<br />
Option "Coolbits" "5"<br />
<br />
==Tips and tricks==<br />
===Enabling Pure Video HD (VDPAU/VAAPI)===<br />
'''Hardware Required:''' <br />
<br />
At least a video card with second generation PureVideo HD [http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs]<br />
<br />
'''Software Required:'''<br />
<br />
Nvidia video cards with the proprietary driver installed will provide video decoding capabilities with the VDPAU interface at different levels according to PureVideo generation.<br />
<br />
You can also add support for the VA-API interface with:<br />
# pacman -S libva-vdpau-driver<br />
<br />
Check VA-API support with:<br />
$ vainfo<br />
<br />
To take full advantage of the hardware decoding capability of your video card you will need a media player that supports VDPAU or VA-API.<br />
<br />
To enable hardware acceleration in [[MPlayer]] edit {{ic|~/.mplayer/config}}<br />
<br />
vo=vdpau<br />
vc=ffmpeg12vdpau,ffwmv3vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau,<br />
<br />
To enable hardware acceleration in [[VLC media player|VLC]] go:<br />
<br />
{{ic|'''Tools'''}} -> {{ic|'''Preferences'''}} -> {{ic|'''Input & Codecs'''}} -> check {{ic|'''Use GPU accelerated decoding'''}}<br />
<br />
To enable hardware acceleration in '''smplayer''' go:<br />
<br />
{{ic|'''Options'''}} -> {{ic|'''Preferences'''}} -> {{ic|'''General'''}} -> {{ic|'''Video Tab'''}} -> select {{ic|vdpau}} as {{ic|'''output driver'''}}<br />
<br />
To enable hardware acceleration in '''gnome-mplayer''' go:<br />
<br />
{{ic|'''Edit'''}} -> {{ic|'''Preferences'''}} -> set {{ic|'''video output'''}} to {{ic|vdpau}}<br />
<br />
'''Playing HD movies on cards with low memory:'''<br />
<br />
If your graphic card does not have a lot of memory (>512MB?), you can experience glitches when watching 1080p or even 720p movies.<br />
To avoid that start simple window manager like TWM or MWM.<br />
<br />
Additionally increasing the MPlayer's cache size in {{ic|~/.mplayer/config}} can help, when your hard drive is spinning down when watching HD movies.<br />
<br />
===Hardware accelerated video decoding with XvMC===<br />
Accelerated decoding of MPEG-1 and MPEG-2 videos via [[XvMC]] are supported on GeForce4, GeForce 5 FX, GeForce 6 and GeForce 7 series cards. To use it, create a new file {{ic|/etc/X11/XvMCConfig}} with the following content:<br />
libXvMCNVIDIA_dynamic.so.1<br />
<br />
See how to configure [[XvMC#Supported software|supported software]].<br />
<br />
===Using TV-out===<br />
A good article on the subject can be found [http://en.wikibooks.org/wiki/NVidia/TV-OUT here]<br />
<br />
===X with a TV (DFP) as the only display===<br />
The X server falls back to CRT-0 if no monitor is automatically detected. This can be a problem when using a DVI connected TV as the main display, and X is started while the TV is turned off or otherwise disconnected.<br />
<br />
To force nvidia to use DFP, store a copy of the EDID somewhere in the filesystem so that X can parse the file instead of reading EDID from the TV/DFP.<br />
<br />
To acquire the EDID, start nvidia-settings. It will show some information in tree format, ignore the rest of the settings for now and select the GPU (the corresponding entry should be titled "GPU-0" or similar), click the {{ic|DFP}} section (again, {{ic|DFP-0}} or similar), click on the {{ic|Acquire Edid}} Button and store it somewhere, for example, {{ic|/etc/X11/dfp0.edid}}.<br />
<br />
Edit {{ic|xorg.conf}} by adding to the {{ic|Device}} section:<br />
Option "ConnectedMonitor" "DFP"<br />
Option "CustomEDID" "DFP-0:/etc/X11/dfp0.edid"<br />
The {{ic|ConnectedMonitor}} option forces the driver to recognize the DFP as if it were connected. The {{ic|CustomEDID}} provides EDID data for the device, meaning that it will start up just as if the TV/DFP was connected during X the process.<br />
<br />
This way, one can automatically start a display manager at boot time and still have a working and properly configured X screen by the time the TV gets powered on.<br />
<br />
===Check the power state===<br />
NVIDIA X.org driver can detect power source. To see the current state check 'GPUPowerSource' read-only parameter (0 - AC, 1 - battery):<br />
<br />
$ nvidia-settings -q GPUPowerSource -t<br />
1<br />
<br />
For it to be able to detect this you need to have [[acpid]] installed. Make sure to include acpid on DAEMONS array in rc.conf or this warning will appear on system log:<br />
ACPI: failed to connect to the ACPI event daemon; the daemon<br />
may not be running or the "AcpidSocketPath" X<br />
configuration option may not be set correctly. When the<br />
ACPI event daemon is available, the NVIDIA X driver will<br />
try to use it to receive ACPI event notifications. For<br />
details, please see the "ConnectToAcpid" and<br />
"AcpidSocketPath" X configuration options in Appendix B: X<br />
Config Options in the README.<br />
<br />
===Displaying GPU temperature in the shell===<br />
====Method 1 - nvidia-settings====<br />
{{Note|This method requires that you are using X. Use Method 2 or Method 3 if you are not. Also note that Method 3 currently does not not work with newer nvidia cards such as the G210/220 as well as embedded GPUs such as the Zotac IONITX's 8800GS.}}<br />
<br />
To display the GPU temp in the shell, use {{ic|nvidia-settings}} as follows:<br />
$ nvidia-settings -q gpucoretemp<br />
<br />
This will output something similar to the following:<br />
Attribute 'GPUCoreTemp' (hostname:0.0): 41.<br />
'GPUCoreTemp' is an integer attribute.<br />
'GPUCoreTemp' is a read-only attribute.<br />
'GPUCoreTemp' can use the following target types: X Screen, GPU.<br />
<br />
The GPU temps of this board is 41 C.<br />
<br />
In order to get just the temperature for use in utils such as {{ic|rrdtool}} or {{ic|conky}}, among others:<br />
$ nvidia-settings -q gpucoretemp -t<br />
41<br />
<br />
====Method 2 - nvidia-smi====<br />
<br />
Use nvidia-smi which can read temps directly from the GPU without the need to use X at all. This is important for a small group of users who do not have X running on their boxes, perhaps because the box is headless running server apps. <br />
To display the GPU temp in the shell, use nvidia-smi as follows:<br />
<br />
$ nvidia-smi<br />
<br />
This should output something similar to the following:<br />
{{bc|<nowiki>$ nvidia-smi<br />
Fri Jan 6 18:53:54 2012 <br />
+------------------------------------------------------+ <br />
| NVIDIA-SMI 2.290.10 Driver Version: 290.10 | <br />
|-------------------------------+----------------------+----------------------+<br />
| Nb. Name | Bus Id Disp. | Volatile ECC SB / DB |<br />
| Fan Temp Power Usage /Cap | Memory Usage | GPU Util. Compute M. |<br />
|===============================+======================+======================|<br />
| 0. GeForce 8500 GT | 0000:01:00.0 N/A | N/A N/A |<br />
| 30% 62 C N/A N/A / N/A | 17% 42MB / 255MB | N/A Default |<br />
|-------------------------------+----------------------+----------------------|<br />
| Compute processes: GPU Memory |<br />
| GPU PID Process name Usage |<br />
|=============================================================================|<br />
| 0. ERROR: Not Supported |<br />
+-----------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Only for Temp:<br />
{{bc|<nowiki><br />
$ nvidia-smi -q -d TEMPERATURE<br />
<br />
==============NVSMI LOG==============<br />
<br />
Timestamp : Fri Jan 6 18:50:57 2012<br />
<br />
Driver Version : 290.10<br />
<br />
Attached GPUs : 1<br />
<br />
GPU 0000:01:00.0<br />
Temperature<br />
Gpu : 62 C<br />
<br />
</nowiki>}}<br />
<br />
In order to get just the temperature for use in utils such as rrdtool or conky, among others:<br />
<br />
$ nvidia-smi -q -d TEMPERATURE | grep Gpu | cut -c35-36<br />
<br />
62<br />
<br />
Reference: http://www.question-defense.com/2010/03/22/gpu-linux-shell-temp-get-nvidia-gpu-temperatures-via-linux-cli<br />
<br />
====Method 3 - nvclock====<br />
Use nvclock which is available from the [extra] repo.<br />
{{Note|{{ic|nvclock}} cannot access thermal sensors on newer NVIDIA cards such as the G210/220.}}<br />
<br />
There can be significant differences between the temperatures reported by nvclock and nvidia-settings/nv-control. According to [http://sourceforge.net/projects/nvclock/forums/forum/67426/topic/1906899 this post] by the author (thunderbird) of nvclock, the nvclock values should be more accurate.<br />
<br />
===Set Fan Speed at Login===<br />
You can adjust the fan speed on your graphics card with {{ic|nvidia-settings}}'s console interface. First ensure that your Xorg configuration sets the Coolbits option to {{ic|4}} or {{ic|5}} in your {{ic|Device}} section to enable fan control.<br />
<br />
Option "Coolbits" "4"<br />
<br />
{{Note|GTX 4xx/5xx series cards cannot currently set fan speeds at login using this method. This method only allows for the setting of fan speeds within the current X session by way of nvidia-settings.}}<br />
<br />
Place the following line in your [[xinitrc|{{ic|~/.xinitrc}}]] file to adjust the fan when you launch Xorg. Replace {{ic|<n>}} with the fan speed percentage you want to set.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=<n>"<br />
<br />
You can also configure a second GPU by incrementing the GPU and fan number.<br />
<br />
nvidia-settings -a "[gpu:0]/GPUFanControlState=1" \ <br />
-a "[gpu:1]/GPUFanControlState=1" \<br />
-a "[fan:0]/GPUCurrentFanSpeed=<n>" \<br />
-a [fan:1]/GPUCurrentFanSpeed=<n>" &<br />
<br />
If you use a login manager such as GDM or KDM, you can create a desktop entry file to process this setting. Create {{ic|~/.config/autostart/nvidia-fan-speed.desktop}} and place this text inside it. Again, change {{ic|<n>}} to the speed percentage you want.<br />
<br />
[Desktop Entry]<br />
Type=Application<br />
Exec=nvidia-settings -a "[gpu:0]/GPUFanControlState=1" -a "[fan:0]/GPUCurrentFanSpeed=<n>"<br />
X-GNOME-Autostart-enabled=true<br />
Name=nvidia-fan-speed<br />
<br />
===Order of install/deinstall for changing drivers===<br />
Where the old driver is nvidiaO and the new driver is nvidiaN.<br />
remove nvidiaO<br />
install nvidia-utilsN<br />
install nvidiaN<br />
install lib32-nvidia-utils-N (if required)<br />
<br />
===Switching between nvidia and nouveau drivers===<br />
If you are switching between the nvidia and nouveau driver often, you can use these two scripts to make it easier (both need to be ran as root):<br />
<br />
#!/bin/bash<br />
# nvidia -> nouveau<br />
<br />
sed -i 's/#*options nouveau modeset=1/options nouveau modeset=1/' /etc/modprobe.d/modprobe.conf<br />
sed -i 's/#*MODULES="nouveau"/MODULES="nouveau"/' /etc/mkinitcpio.conf<br />
<br />
pacman -Rdds --noconfirm nvidia{,-utils}<br />
pacman -S --noconfirm nouveau-dri xf86-video-nouveau<br />
<br />
#cp {10-monitor,20-nouveau}.conf /etc/X11/xorg.conf.d/<br />
<br />
mkinitcpio -p linux<br />
<br />
#!/bin/bash<br />
# nouveau -> nvidia<br />
<br />
sed -i 's/options nouveau modeset=1/#options nouveau modeset=1/' /etc/modprobe.d/modprobe.conf<br />
sed -i 's/MODULES="nouveau"/#MODULES="nouveau"/' /etc/mkinitcpio.conf<br />
<br />
pacman -Rdds --noconfirm nouveau-dri xf86-video-nouveau libgl<br />
pacman -S --noconfirm nvidia{,-utils}<br />
<br />
#rm /etc/X11/xorg.conf.d/{10-monitor,20-nouveau}.conf<br />
<br />
mkinitcpio -p linux<br />
<br />
A reboot is needed to complete the switch.<br />
<br />
Adjust the scripts accordingly, if using other NVIDIA drivers (e.g. nvidia-173xx).<br />
<br />
If using xorg-server older than 1.10.2, uncomment the lines that copy and remove {{ic|{10-monitor,20-nouveau}.conf}}. Since 1.10.2 X loads nouveau automatically.<br />
<br />
==Troubleshooting==<br />
<br />
===Bad performance, e.g. slow repaints when switching tabs in Chrome===<br />
<br />
On some machines, recent nvidia drivers introduce a bug(?) that causes X11 to redraw pixmaps really slow. Switching tabs in Chrome/Chromium (while having more than 2 tabs opened) takes 1-2 seconds, instead of a few milliseconds.<br />
<br />
It seems that setting the variable '''InitialPixmapPlacement''' to '''0''' solves that problem, although (like described some paragraphs above) '''InitialPixmapPlacement=2''' should actually be the faster method.<br />
<br />
The variable can be (temporarily) set with the command<br />
<br />
nvidia-settings -a InitialPixmapPlacement=0<br />
<br />
To make this permanent, this call can be placed in a startup script.<br />
<br />
===Gaming using Twinview===<br />
In case you want to play fullscreen games when using Twinview, you will notice that games recognize the two screens as being one big screen. While this is technically correct (the virtual X screen really is the size of your screens combined), you probably do not want to play on both screens at the same time. <br />
<br />
To correct this behavior for SDL, try:<br />
export SDL_VIDEO_FULLSCREEN_HEAD=1<br />
<br />
For OpenGL, add the appropiate Metamodes to your xorg.conf in section {{ic|Device}} and restart X:<br />
Option "Metamodes" "1680x1050,1680x1050; 1280x1024,1280x1024; 1680x1050,NULL; 1280x1024,NULL;"<br />
<br />
Another method that may either work alone or in conjunction with those mentioned above is [[Gaming#Starting_games_in_a_separate_X_server|starting games in a separate X server]].<br />
<br />
===Vertical sync using TwinView===<br />
If you're using TwinView and vertical sync (the "Sync to VBlank" option in {{ic|nvidia-settings}}), you will notice that only one screen is being properly synced, unless you have two identical monitors. Although {{ic|nvidia-settings}} does offer an option to change which screen is being synced (the "Sync to this display device" option), this does not always work. A solution is to add the following environment variables at startup:<br />
nano /etc/profile<br />
Add to the end of the file:<br />
export __GL_SYNC_TO_VBLANK=1<br />
export __GL_SYNC_DISPLAY_DEVICE=DFP-0<br />
export __VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE=DFP-0<br />
You can change {{ic|DFP-0}} with your preferred screen ({{ic|DFP-0}} is the DVI port and {{ic|CRT-0}} is the VGA port).<br />
<br />
===Old Xorg Settings===<br />
If upgrading from an old installation, please remove old {{ic|/usr/X11R6/}} paths as it can cause trouble during installation.<br />
<br />
===Corrupted screen: "Six screens" issue===<br />
For some users using Geforce GT 100M's, the screen turns out corrupted after X starts; divided into 6 sections with a resolution limited to 640x480.<br />
The same problem has been recently reported with Quadro 2000 and hi-res displays.<br />
<br />
To solve this problem, enable the Validation Mode {{ic|NoTotalSizeCheck}} in section {{ic|Device}}:<br />
Section "Device"<br />
...<br />
Option "ModeValidation" "NoTotalSizeCheck"<br />
...<br />
EndSection<br />
==='/dev/nvidia0' Input/Output error===<br />
{{Accuracy|verify that the BIOS related suggestions work and are not coincidentally set while troubleshooting.|section='/dev/nvidia0' Input/Output error... suggested fixes}}<br />
This error can occur for several different reasons, and the most common solution given for this error is to check for group/file permissions, which in almost every case is ''not'' the issue. The NVIDIA documentation does not talk in detail on what you should<br />
do to correct this problem but there are a few things that have worked for some people. The problem can be a IRQ conflict with another device or bad routing by either the kernel or your BIOS.<br />
<br />
First thing to try is to remove other video devices such as video capture cards and see if the problem goes away. If there are too many video processors on the same system it can lead into the kernel being unable to start them because of memory allocation problems with the video controller. In particular on systems with low video memory this can occur even if there is only one video processor. In such case you should find out the amount of your system's video memory (e.g. with {{ic|lspci -v}}) and pass allocation parameters to the kernel, e.g.:<br />
vmalloc=64M<br />
or<br />
vmalloc=256M<br />
<br />
If running a 64bit kernel, a driver defect can cause the nvidia module to fail initializing when IOMMU is on. Turning it off in the BIOS has been confirmed to work for some users. [http://www.nvnews.net/vbulletin/showthread.php?s=68bb2fabadcb53b10b286aa42d13c5bc&t=159335][https://wiki.archlinux.org/index.php/User:Clickthem#nvidia_module]<br />
<br />
Another thing to try is to change your BIOS IRQ routing from {{ic|Operating system controlled}} to {{ic|BIOS controlled}} or the other way around. The first one can be passed as a kernel parameter:<br />
PCI=biosirq<br />
<br />
The {{ic|noacpi}} kernel parameter has also been suggested as a solution but since it disables ACPI completely it should be used with caution. Some hardware are easily damaged by overheating.<br />
<br />
{{Note|The kernel parameters can be passed either through the kernel command line or the bootloader configuration file. See your bootloader Wiki page for more information.}}<br />
<br />
==='/dev/nvidiactl' errors===<br />
Trying to start an opengl application might result in errors such as:<br />
Error: Could not open /dev/nvidiactl because the permissions are too<br />
restrictive. Please see the {{ic|FREQUENTLY ASKED QUESTIONS}} <br />
section of {{ic|/usr/share/doc/NVIDIA_GLX-1.0/README}} <br />
for steps to correct.<br />
<br />
Solve by adding the appropiate user to the {{ic|video}} group and relogin:<br />
# gpasswd -a username video<br />
<br />
===32 bit applications do not start===<br />
Under 64 bit systems, installing {{ic|lib32-nvidia-utils}} that corresponds to the same version installed for the 64 bit driver fixes the issue.<br />
<br />
===Errors after updating the kernel===<br />
If a custom build of NVIDIA's module is used instead of the package from [extra], a recompile is required every time the kernel is updated. Rebooting is generally recommended after updating kernel and graphic drivers.<br />
<br />
===Crashing in general===<br />
* Try disabling {{ic|RenderAccel}} in xorg.conf.<br />
* If Xorg outputs an error about "conflicting memory type" or "failed to allocate primary buffer: out of memory", add {{ic|nopat}} at the end of the {{ic|kernel}} line in {{ic|/boot/grub/menu.lst}}.<br />
* If the NVIDIA compiler complains about different versions of GCC between the current one and the one used for compiling the kernel, add in {{ic|/etc/profile}}:<br />
export IGNORE_CC_MISMATCH=1<br />
* If Xorg is crashing with a "Signal 11" while using nvidia-96xx drivers, try disabling PAT. Pass the argument {{ic|nopat}} to the {{ic|kernel}} line in {{ic|menu.lst}}.<br />
More information about troubleshooting the driver can be found in the [http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14 NVIDIA forums.]<br />
<br />
===Bad performance after installing a new driver version===<br />
If FPS have dropped in comparison with older drivers, first check if direct rendering is turned on:<br />
$ glxinfo | grep direct<br />
If the command prints:<br />
direct rendering: No<br />
then that could be an indication for the sudden FPS drop.<br />
<br />
A possible solution could be to regress to the previously installed driver version and rebooting afterwards.<br />
<br />
===CPU spikes with 400 series cards===<br />
If you are experiencing intermittent CPU spikes with a 400 series card, it may be caused by PowerMizer constantly changing the GPU's clock frequency. Switching PowerMizer's setting from Adaptive to Performance, add the following to the {{ic|Device}} section of your Xorg configuration:<br />
<br />
Option "RegistryDwords" "PowerMizerEnable=0x1; PerfLevelSrc=0x3322; PowerMizerDefaultAC=0x1"<br />
<br />
===Laptops: X hangs on login/out, worked around with Ctrl+Alt+Backspace===<br />
If while using the legacy NVIDIA drivers Xorg hangs on login and logout (particularly with an odd screen split into two black and white/gray pieces), but logging in is still possible via Ctrl-Alt-Backspace (or whatever the new "kill X" keybind is), try adding this in {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
options nvidia NVreg_Mobile=1<br />
<br />
One user had luck with this instead, but it makes performance drop significantly for others:<br />
options nvidia NVreg_DeviceFileUID=0 NVreg_DeviceFileGID=33 NVreg_DeviceFileMode=0660 NVreg_SoftEDIDs=0 NVreg_Mobile=1<br />
<br />
Note that {{ic|NVreg_Mobile}} needs to be changed according to the laptop:<br />
* 1 for Dell laptops.<br />
* 2 for non-Compal Toshiba laptops.<br />
* 3 for other laptops.<br />
* 4 for Compal Toshiba laptops.<br />
* 5 for Gateway laptops.<br />
<br />
See [http://http.download.nvidia.com/XFree86/Linux-x86/1.0-7182/README/readme.txt NVIDIA Driver's Readme:Appendix K] for more information.<br />
<br />
===Refresh rate not detected properly by XRandR dependant utilities===<br />
The XRandR X extension is not presently aware of multiple display devices on a single X screen; it only sees the {{ic|MetaMode}} bounding box, which may contain one or more actual modes. This means that if multiple MetaModes have the same bounding box, XRandR will not be able to distinguish between them.<br />
<br />
In order to support {{ic|DynamicTwinView}}, the NVIDIA driver must make each MetaMode appear to be unique to XRandR. Presently, the NVIDIA driver accomplishes this by using the refresh rate as a unique identifier.<br />
<br />
Use {{ic|nvidia-settings -q RefreshRate}} to query the actual refresh rate on each display device.<br />
<br />
The XRandR extension is currently being redesigned by the X.Org community, so the refresh rate workaround may be removed at some point in the future.<br />
<br />
This workaround can also be disabled by setting the {{ic|DynamicTwinView}} X configuration option to {{ic|false}}, which will disable NV-CONTROL support for manipulating MetaModes, but will cause the XRandR and XF86VidMode visible refresh rate to be accurate.<br />
<br />
===No screens found on a laptop / NVIDIA Optimus===<br />
On a laptop, if the NVIDIA driver cannot find any screens, you may have an NVIDIA Optimus setup : an Intel chipset connected to the screen and the video outputs, and a NVIDIA card that does all the hard work and writes to the chipset's video memory.<br />
<br />
Check if<br />
lspci | grep VGA<br />
outputs something similar to<br />
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)<br />
01:00.0 VGA compatible controller: nVidia Corporation Device 0df4 (rev a1)<br />
<br />
NVIDIA has [http://www.phoronix.com/scan.php?page=news_item&px=MTE3MzY announced plans] to support Optimus in their Linux drivers at some point in the future.<br />
<br />
You need to install the [[Intel Graphics|Intel]] driver to handle the screens, then if you want 3D software you should run them through [[Bumblebee]] to tell them to use the NVIDIA card.<br />
<br />
'''Possible Workaround'''<br />
<br />
On my Lenovo W520 with a Quadro 1000M and Nvidia Optimus, I entered the BIOS and changed my default graphics setting from 'Optimus' to 'Discrete' and the pacman Nvidia drivers(295.20-1 at time of writing) recognized the screens.<br />
<br />
Steps:<br />
-Enter BIOS<br />
-Find Graphics Settings(For me it's in the Config Tab, then Display submenu)<br />
-Change 'Graphics Device' to 'Discrete Graphics'(Disables Intel integrated graphics)<br />
-Change OS Detection for Nvidia Optimus to 'Disabled'<br />
-Save and Exit<br />
<br />
===Screen(s) found, but none have a usable configuration===<br />
On a laptop, sometimes NVIDIA driver cannot find the active screen.<br />
It may be caused because you own a graphic card with vga/tv outs.<br />
You should examine Xorg.0.log to see what is wrong.<br />
<br />
Another thing to try is adding invalid {{ic|"ConnectedMonitor" Option}} to {{ic|Section "Device"}}<br />
to force Xorg throws error and shows you how correct it.<br />
[http://http.download.nvidia.com/XFree86/Linux-x86/304.51/README/xconfigoptions.html Here]<br />
more about ConnectedMonitor setting.<br />
<br />
After re-run X see Xorg.0.log to get valid CRT-x,DFP-x,TV-x values.<br />
<br />
{{ic|nvidia-xconfig --query-gpu-info}} could be helpful.<br />
<br />
===No brightness control on laptops===<br />
Try to add the following line on 20-nvidia.conf<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
If it still not working, you can try install [https://aur.archlinux.org/packages.php?ID=25467 nvidia-bl] or [https://aur.archlinux.org/packages.php?ID=50749 nvidiabl].<br />
<br />
===Black Bars while watching full screen flash videos with twinview===<br />
Follow the instructions presented here:<br />
[http://al.robotfuzz.com/content/workaround-fullscreen-flash-linux-multiheaded-desktops link]<br />
<br />
===Backlight is not turning off in some occasions===<br />
<br />
By default, DPMS should turn off backlight with the timeouts set or by running xset. However, probably due to a bug in the proprietary Nvidia drivers the result is a blank screen with no powersaving whatsoever. To workaround it, until the bug has been fixed you can use the {{ic|vbetool}} as root.<br />
<br />
Install the {{pkg|vbetool}} package.<br />
<br />
Turn off your screen on demand and then by pressing a random key backlight turns on again:<br />
<br />
vbetool dpms off && read -n1; vbetool dpms on<br />
<br />
Alternatively, xrandr is able to disable and re-enable monitor outputs without requiring root.<br />
<br />
xrandr --output DP-1 --off; read -n1; xrandr --output DP-1 --auto<br />
<br />
===Blue tint on videos with Flash===<br />
<br />
An issue with {{Pkg|flashplugin}} versions 11.2.202.228-1 and 11.2.202.233-1 causes it to send the U/V panes in the incorrect order resulting in a blue tint on certain videos. There are a few potential fixes for this bug:<br />
<br />
* Install the latest {{Pkg|libvdpau}}.<br />
* Patch {{ic|vdpau_trace.so}} with [https://bbs.archlinux.org/viewtopic.php?pid=1078368#p1078368 this makepkg].<br />
* Right click on a video, select "Settings..." and uncheck "Enable hardware acceleration". Reload the page for it to take affect. Note that this disables GPU acceleration.<br />
* [[Downgrading Packages|Downgrade]] the {{Pkg|flashplugin}} package to version 11.1.102.63-1 at most.<br />
* Use {{AUR|google-chrome}} with the new [https://aur.archlinux.org/packages/?O=0&K=chromium-pepper-flash Pepper API].<br />
* Try one of the few Flash alternatives.<br />
<br />
The merits of each are discussed in [https://bbs.archlinux.org/viewtopic.php?id=137877 this thread]. To summarize: if you want all flash sites (YouTube, Vimeo, etc) to work properly in non-Chrome browsers, without feature regressions (such as losing hardware acceleration), without crashes/instability (enabling hardware decoding), without security concerns (multiple CVEs against older flash versions) and without breaking the vdpau tracing library from its intended purpose, the LEAST objectionable is to install {{AUR|libvdpau-git-flashpatch}}.<br />
<br />
===Bleeding overlay with Flash===<br />
<br />
This bug is due to the incorrect colour key being used by the {{Pkg|flashplugin}} version 11.2.202.228-1 and causes the flash content to "leak" into other pages or solid black backgrounds. To avoid this issue simply install the latest {{Pkg|libvdpau}} or export {{ic|1=VDPAU_NVIDIA_NO_OVERLAY=1}} within either your shell profile (E.g. {{ic|~/.bash_profile}} or {{ic|~/.zprofile}}) or {{ic|~/.xinitrc}}<br />
<br />
===Full system freeze using flash===<br />
<br />
If you experience occasional full system freezes (only the mouse is moving) using flashplugin<br />
and get <br />
<br />
# /var/log/errors.log<br />
NVRM: Xid (0000:01:00): 31, Ch 00000007, engmask 00000120, intr 10000000<br />
<br />
a possible workaround is to switch off Hardware Acceleration in flash, setting<br />
<br />
# /etc/adobe/mms.cfg<br />
EnableLinuxHWVideoDecode=0<br />
<br />
===XOrg fails to Load or Red Screen of Death===<br />
If you get a red screen and use grub2 disable the grub2 framebuffer by editing /etc/defaults/grub and uncomment GRUB_TERMINAL_OUTPUT. For more information see [[Grub#Disable_framebuffer]].<br />
<br />
==See also==<br />
* [http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14 NVIDIA forums]<br />
* [http://http.download.nvidia.com/XFree86/Linux-x86/1.0-7182/README/readme.txt Official readme for NVIDIA drivers]</div>Calinou