https://wiki.archlinux.org/api.php?action=feedcontributions&user=Slowbro&feedformat=atomArchWiki - User contributions [en]2024-03-29T01:15:06ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=RVM&diff=599299RVM2020-02-27T08:28:21Z<p>Slowbro: rvm uses (~/.profile, ~/.mkshrc, ~/.bashrc, ~/.zshrc) for PATH and (~/.profile, ~/.bash_profile, ~/.zlogin) for the 'rvm' script now.</p>
<hr />
<div>[[Category:Development]]<br />
[[de:RVM]]<br />
[[ja:RVM]]<br />
{{Related articles start}}<br />
{{Related|Rbenv}}<br />
{{Related|Chruby}}<br />
{{Related|Ruby}}<br />
{{Related articles end}}<br />
[http://rvm.io/ RVM] (Ruby Version Manager) is a command line tool which allows us to easily install, manage and work with multiple [[Ruby]] environments from interpreters to sets of gems.<br />
<br />
There exists a similar application that you may also want to consider: [[rbenv]].<br />
<br />
== Installing RVM ==<br />
<br />
The install process is very easy, and is the same for any distro, including Arch Linux. You have two choices, one system-wide, another as a user. The first is for production servers, or if you are alone on your machine, you'll need root privileges. The second is recommended for multiple users on the same machine (like a development test box). If you do not know which to choose then start with a single user installation.<br />
<br />
The upstream instructions for installing RVM should just work. The install script is aware enough to tell you what packages you need to install on Arch Linux to make different rubies work. This usually involves gcc and some other stuff needed to compile ruby.<br />
<br />
As an observation, '''installing RVM with gem is not recommended anymore'''. This article uses the [http://rvm.io/rvm/install/ recommended documentation] with minor tweaks to make it work on Arch Linux.<br />
<br />
=== Pre-requisites ===<br />
<br />
Before starting, you will need to [[install]] the {{pkg|git}} and {{pkg|curl}} packages.<br />
<br />
=== Single-user installation ===<br />
<br />
{{Note|This will install to your home directory only (~/.rvm), and won't touch the standard Arch ruby package, which is in /usr.}}<br />
<br />
For most purposes, the recommended installation method is single-user, which is a self-contained RVM installation in a user's home directory.<br />
<br />
Use the script that rvm docs recommends to install. Make sure to run this script as the user for whom you want RVM installed (i.e. your normal user that you use for development).<br />
<br />
To check the script before running it, do:<br />
<br />
$ curl -L get.rvm.io > rvm-install<br />
<br />
Inspect the file, and then run it with:<br />
<br />
$ bash < ./rvm-install<br />
<br />
Now, close out your current shell or terminal session and open a new one to set up your PATH and the rvm function. You may attempt reloading your ~/.bash_profile with the following command:<br />
<br />
$ source ~/.bash_profile<br />
<br />
However, closing out your current shell or terminal and opening a new one is the preferred way for initial installations.)<br />
<br />
=== Multi-user installation ===<br />
<br />
{{Note|This will install to /usr/local/rvm, and won't touch the standard Arch ruby package, which is in /usr. }}<br />
<br />
System-wide installation is a similar procedure to the single user install. However, instead run the install script with sudo. '''Do not run the installer directly as root!'''<br />
<br />
$ sudo bash -s stable<br />
<br />
(to install a specific version replace ''stable'' with, for example, ''-- --version 1.13.0'')<br />
<br />
After the script has finished, add yourself and your users to the 'rvm' group. (The installer does not auto-add any users to the rvm group. Admins must do this.) For each one, repeat:<br />
<br />
# usermod -a -G rvm <user><br />
<br />
'''Group memberships are only evaluated at login time'''. Log the users out, then back in. You too: close out your current shell or terminal session and open a new one. (You may attempt reloading your ~/.bash_profile with the following command:<br />
<br />
$ source ~/.bash_profile<br />
<br />
However, closing out your current shell or terminal and opening a new one is the preferred way for initial installations. Alternatively, you can use the "newgrp rvm" command and check with "id" to see whether the shell has picked up the new group membership of your user)<br />
<br />
{{Note|Remember to change the line [ [ -s $HOME/.rvm/scripts/rvm ] ] && source $HOME/.rvm/scripts/rvm to the system-wide location changing $HOME to /usr/local/}}<br />
<br />
RVM will be automatically configured for every user on the system (in opposite to the single-user installation); this is accomplished by loading /etc/profile.d/rvm.sh on login. Arch Linux defaults to parsing /etc/profile which contains the logic to load all files residing in the /etc/profile.d/ directory.<br />
<br />
Before installing gems with multi-user rvm, make sure that /etc/gemrc does not have the line "gem: --user-install". If it does you need to comment it out otherwise the gems will install to the wrong place.<br />
<br />
'''You only use the sudo command during the install process'''. In multi-user configurations, any operations which require sudo access must use the ''rvmsudo'' command which preserves the RVM environment and passes this on to sudo. There are very few cases where rvmsudo is required once the core install is completed, except for when updating RVM itself. There is never a reason to use sudo post-install. rvmsudo should only be needed for updating with<br />
<br />
$ rvmsudo rvm get head<br />
<br />
===== A cautionary action =====<br />
<br />
In order to prevent the installation breakage by this cause, you may add this configuration to your /etc/sudoers file with command: {{ic|#su -c visudo}}<br />
<br />
{{bc|1=<br />
## Cmnd alias specification<br />
Cmnd_Alias RVM = /usr/local/rvm/rubies/<ruby_interpreter>/bin/gem, \<br />
/usr/local/rvm/rubies/<another_ruby_interpreter>/bin/gem, \<br />
/usr/local/rvm/bin/rvm<br />
<br />
## User privilege specification<br />
root ALL=(ALL) ALL<br />
<br />
## Uncomment to allow members of group wheel to execute any command<br />
%wheel ALL=(ALL) ALL, !RVM<br />
}}<br />
<br />
Where ''<ruby_interpreter>'' would be —for example— ruby-1.9.2-p290.<br />
<br />
== Post Installation ==<br />
<br />
After the installation, check everything worked with this command:<br />
<br />
$ type rvm | head -n1<br />
<br />
The response should be:<br />
<br />
$ rvm is a function<br />
<br />
If you receive rvm: not found, you may need to source your ~/.bash_profile (or wherever you put the line above):<br />
<br />
$ . ~/.bash_profile<br />
<br />
Check if the rvm function is working:<br />
<br />
$ rvm notes<br />
<br />
Finally, see if there are any dependency requirements for your installation by running:<br />
<br />
$ rvm requirements<br />
<br />
(Follow the returned instructions if any.)<br />
<br />
'''Very important''': whenever you upgrade RVM in the future, you should always run ''rvm notes'' and ''rvm requirements'' as this is usually where you will find details on any major changes and/or additional requirements '''to ensure your installation stays working'''.<br />
<br />
=== Some extras ===<br />
<br />
You may put in your ~/.bashrc the following lines to get some useful features:<br />
{{bc|1=<br />
# Display the current RVM ruby selection<br />
PS1="\$(/usr/local/rvm/bin/rvm-prompt) $PS1"<br />
<br />
# RVM bash completion<br />
<nowiki>[[ -r /usr/local/rvm/scripts/completion ]]</nowiki> && . /usr/local/rvm/scripts/completion<br />
}}<br />
<br />
Or if you're running as a single user:<br />
{{bc|1=<br />
# RVM bash completion<br />
<nowiki>[[ -r "$HOME/.rvm/scripts/completion" ]]</nowiki> && source "$HOME/.rvm/scripts/completion"<br />
}}<br />
<br />
== Using RVM ==<br />
<br />
The RVM documentation is ''quite'' comprehensive and explanatory. However, here are some RVM usage examples to get you started.<br />
<br />
=== Rubies ===<br />
<br />
==== Installing environments ====<br />
<br />
To see what Ruby environments are available to install, run:<br />
<br />
$ rvm list known<br />
<br />
To install one, run:<br />
<br />
$ rvm install <ruby_version><br />
<br />
For example, to install Ruby 1.9.2 one would run the following command:<br />
<br />
$ rvm install 1.9.2<br />
<br />
This should download, configure and install Ruby 1.9.2 in the place you installed RVM. For example, if you did a single user install, it will be in ~/.rvm/rubies/1.9.2.<br />
<br />
You can define a default ruby interpreter by doing:<br />
<br />
$ rvm use <ruby_version> --default<br />
<br />
If not, the default environment will be the system ruby in /usr —if you have installed one using pacman— or none.<br />
<br />
==== Switching environments ====<br />
<br />
To switch from one environment to another simply run:<br />
<br />
$ rvm use <ruby_version><br />
<br />
For example to switch to Ruby 1.8.7 one would run the following command:<br />
<br />
$ rvm 1.8.7<br />
<br />
(As you see, the flag ''use'' is not really necessary.)<br />
<br />
You should get a message telling you the switch worked. It can be confirmed by running:<br />
<br />
$ ruby --version<br />
<br />
Note that this environment will only be used in the current shell. You can open another shell and select a different environment for that one in parallel.<br />
<br />
In case you have set a default interpreter as explained above, you can do the switch with:<br />
<br />
$ rvm default<br />
<br />
==== System ruby ====<br />
<br />
If you wish the ruby interpreter that is outside RVM (i.e. the one installed in /usr by the standard Arch Linux package), you can switch to it using:<br />
<br />
$ rvm system<br />
<br />
==== Listing environments ====<br />
<br />
To see all installed Ruby environments, run the following command:<br />
<br />
$ rvm list<br />
<br />
If you've installed a few rubies, this might generate a list like so:<br />
<br />
rvm Rubies<br />
=> ruby-1.8.7-p249 [ x86_64 ]<br />
ruby-1.9.2-head [ x86_64 ]<br />
System Ruby<br />
system [ x86_64 ]<br />
<br />
The ASCII arrow indicates which environment is currently enabled. In this case, it is Ruby 1.8.7. This could be confirmed by running:<br />
<br />
$ ruby --version<br />
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]<br />
<br />
=== Gemsets ===<br />
<br />
RVM has a valued feature called gemsets which enables you to store different sets of gems in compartmentalized independent ruby setups. This means that ruby, gems and irb are all separate and self-contained from the system and each other.<br />
<br />
==== Creating ====<br />
<br />
Gemsets must be created before being used. To create a new gemset for the current ruby, do this:<br />
<br />
$ rvm use <ruby_version><br />
$ rvm gemset create <gemset_name><br />
<br />
Alternatively, if you prefer the shorthand syntax offered by rvm use, employ the --create option like so:<br />
<br />
$ rvm use <ruby_version>@<gemset_name> --create<br />
<br />
You can also specify a default gemset for a given ruby interpreter, by doing:<br />
<br />
$ rvm use <ruby_version>@<gemset_name> --default<br />
<br />
==== Using ====<br />
<br />
Tip: remove gems that reside in system prior to the RVM installation with:<br />
$ gem list --local --no-version | awk '{print "gem uninstall " $1}' | bash<br />
<br />
and check what's left:<br />
<br />
$ gem list --local<br />
<br />
To use a gemset:<br />
<br />
$ rvm gemset use <gemset_name><br />
<br />
You can switch to a gemset as you start to use a ruby, by appending @<gemset_name> to the end of the ruby selector string:<br />
<br />
$ rvm use <ruby_version>@<gemset_name><br />
<br />
===== Notes =====<br />
<br />
When you install a ruby environment, it comes with two gemsets out of the box, their names are ''default'' and ''global''. You will usually find in the latter some pre-installed common gems, while the former always starts empty. <br />
<br />
A little bit about where the default and global gemsets differ: When you do not use a gemset at all, you get the gems in the default set. If you use a specific gemset (say @testing), it will inherit gems from that ruby's @global. The global gemset is to allow you to share gems to all your gemsets.<br />
<br />
==== Gems ====<br />
<br />
Within a gemset, you can utilize usual RubyGems commands<br />
$ gem install <gem><br />
to add,<br />
$ gem uninstall <gem><br />
to remove gems, and<br />
$ gem list<br />
to view installed ones.<br />
<br />
If you are deploying to a server, or you do not want to wait around for rdoc and ri to install for each gem, you can disable them for gem installs and updates. Just add these two lines to your ~/.gemrc or /etc/gemrc:<br />
<br />
install: --no-document<br />
update: --no-document<br />
<br />
==== Listing ====<br />
<br />
To see the name of the current gemset:<br />
<br />
$ rvm gemset name<br />
<br />
To list all named gemsets for the current ruby interpreter:<br />
<br />
$ rvm gemset list<br />
<br />
To list all named gemsets for all interpreters:<br />
<br />
$ rvm gemset list_all<br />
<br />
==== Deleting ====<br />
<br />
This action removes the current gemset:<br />
<br />
$ rvm gemset use <gemset_name><br />
$ rvm gemset delete <gemset_name><br />
<br />
By default, rvm deletes gemsets from the currently selected Ruby interpreter. To delete a gemset from a different interpreter, say 1.9.2, run your command this way:<br />
<br />
$ rvm 1.9.2 do gemset delete <gemset_name><br />
<br />
==== Emptying ====<br />
<br />
This action removes all gems installed in the gemset:<br />
<br />
$ rvm gemset use <gemset_name><br />
$ rvm gemset empty <gemset_name><br />
<br />
=== RVM ===<br />
<br />
==== Updating ====<br />
<br />
To upgrade to the most recent release version:<br />
<br />
$ rvm get latest<br />
<br />
Upgrading to the latest repository source version (the most bugfixes):<br />
<br />
$ rvm get head<br />
<br />
Remember to use rvmsudo for multi-user setups. Update often!<br />
<br />
==== Uninstalling ====<br />
<br />
Executing<br />
<br />
$ rvm implode<br />
<br />
is going to wipe out the RVM installation —cleanly—.<br />
<br />
=== Further Reading ===<br />
<br />
This is just a simple introduction to switching ruby versions with RVM and managing different set of gems in different environments. There is lots more that you can do with it! For more information, consult the very comprehensive RVM documentation. [https://rvm.beginrescueend.com/rvm/basics/ This page] is a good place to start.<br />
<br />
== Troubleshooting ==<br />
<br />
Unfortunately, some ruby patchlevels just do not play nicely with Arch Linux, and many times RVM does not choose the latest patchlevel version to install. So, you'll need to manually check on the [http://www.ruby-lang.org/en/news/ ruby website], and force RVM to install it.<br />
<br />
==== "data definition has no type or storage class" ====<br />
<br />
This appears to be specific to 1.8.7, but if you get this error while compiling the following steps will fix your problem:<br />
<br />
$ cd src/ruby-1.8.7-p334/ext/dl<br />
$ rm callback.func<br />
$ touch callback.func<br />
$ ruby mkcallback.rb >> callback.func<br />
$ rm cbtable.func<br />
$ touch cbtable.func<br />
$ ruby mkcbtable.rb >> cbtable.func<br />
<br />
Naturally, substitute the actual build path to your source, which will be something like ~/.rvm/src/.<br />
<br />
==== Ruby 1.8.x won't compile with RVM ====<br />
<br />
This is a known issue on Arch Linux, and is caused by a problem with openssl. Arch uses openssl 1.0, lower patchlevels of 1.8.7 assumes 0.9. <br />
<br />
Certain patch levels may not build (p352 for example), p299 should work fine and can be installed using the following command:<br />
<br />
$ rvm remove 1.8.7<br />
$ rvm install 1.8.7-p299<br />
<br />
Another approach is to install local openssl via RVM:<br />
<br />
$ rvm pkg install openssl<br />
$ rvm remove 1.8.7<br />
$ rvm install 1.8.7 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
It may be necessary to patch 1.8.7:<br />
<br />
$ wget https://gist.githubusercontent.com/waseem/0e8607e443bcd0b3e60cfad56cd9999b/raw/2083ae1cc7643174bb291fce8c25b1b643d91af7/ssl.patch<br />
$ rvm remove 1.8.7<br />
$ rvm install --patch ./ssl.patch ruby-1.8.7-p352<br />
<br />
==== Ruby 1.9.1 won't compile with RVM ====<br />
<br />
Like with 1.8.x, earlier patchlevels do not like the OpenSSL 1.0. Then you can use the very same solution above, by installing openssl locally on RVM.<br />
<br />
$ rvm pkg install openssl<br />
$ rvm remove 1.9.1<br />
$ rvm install 1.9.1 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
The patchlevels >p378 have a problem with gem paths, when $GEM_HOME is set. The problem is known and fixed in 1.9.2. (http://redmine.ruby-lang.org/issues/3584). If you really need 1.9.1 please use p378.<br />
<br />
$ rvm install 1.9.1-p378 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
==== Ruby 2.2.2 won't compile with RVM ====<br />
<br />
Like with 1.8.x and 1.9.1, earlier patchlevels do not like the OpenSSL 1.0. Then you can use the very same solution above, by installing openssl locally on RVM.<br />
<br />
$ rvm pkg install openssl<br />
$ rvm remove 2.2.2<br />
$ rvm install 2.2.2 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
==== Ruby 2.3.1 won't compile with RVM ====<br />
<br />
Like with 1.8.x, 1.9.1 and 2.2.2, earlier patchlevels do not like the OpenSSL 1.0. Then you can use the very same solution above, by installing openssl locally on RVM.<br />
<br />
$ rvm pkg install openssl<br />
$ rvm remove 2.3.1<br />
$ rvm install 2.3.1 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
==== RVM uses wrong OpenSSL version ====<br />
<br />
Ruby versions older than 2.4 require OpenSSL 1.0 but RVM will try to build them with OpenSSL 1.1. You know this is the case if you find this line in the ~/.rvm/log/XYZ/make.log file:<br />
<br />
/usr/include/openssl/asn1_mac.h:10:2: error: #error "This file is obsolete; please update your software."<br />
<br />
First [[install]] {{Pkg|openssl-1.0}} if not already installed.<br />
<br />
You can point it to the correct version like this:<br />
<br />
$ rvm remove <ruby-version><br />
$ PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig:/usr/lib/pkgconfig rvm install <ruby-version><br />
<br />
if the above doesn't work, try changing the last command to:<br />
<br />
PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig \<br />
CFLAGS+=" -I/usr/include/openssl-1.0" \<br />
LDFLAGS+=" -L/usr/lib/openssl-1.0 -lssl" \<br />
rvm install <ruby-version><br />
<br />
Alternatively you could also use RVM to install OpenSSL as above:<br />
<br />
$ rvm pkg install openssl<br />
$ rvm remove 2.3.4<br />
$ rvm install 2.3.4 -C --with-openssl-dir=$HOME/.rvm/usr<br />
<br />
== See Also ==<br />
<br />
* [http://rvm.io/ RVM project website].<br />
* [[RubyOnRails#The Perfect Rails Setup|The Perfect Rails Setup]].</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=599283Unofficial user repositories2020-02-26T23:13:01Z<p>Slowbro: adding slowbro signed repository for linux-vfio</p>
<hr />
<div>[[Category:Package management]]<br />
[[Category:Lists]]<br />
[[ja:非公式ユーザーリポジトリ]]<br />
[[zh-hans:Unofficial user repositories]]<br />
{{Related articles start}}<br />
{{Related|pacman-key}}<br />
{{Related|Official repositories}}<br />
{{Related articles end}}<br />
This article lists binary repositories freely created and shared by the community, often providing pre-built versions of PKGBUILDS found in the [[AUR]].<br />
<br />
In order to use these repositories, add them to {{ic|/etc/pacman.conf}}, as explained in [[pacman#Repositories and mirrors]]. If a repository is signed, you must obtain and locally sign the associated key, as explained in [[pacman/Package signing#Adding unofficial keys]].<br />
<br />
If you want to create your own custom repository, follow [[pacman/Tips and tricks#Custom local repository]].<br />
<br />
{{Warning|The official Arch Linux Developers and the Trusted Users do not perform tests of any sort to verify the contents of these repositories. You must decide whether to trust their maintainers and you take full responsibility for any consequences of using any unofficial repository.}}<br />
<br />
== Adding your repository to this page ==<br />
<br />
If you have your own repository, please add it to this page, so that all the other users will know where to find your packages. Please keep the following rules when adding new repositories:<br />
<br />
* Keep the lists in alphabetical order.<br />
* Include some information about the maintainer: include at least a (nick)name and some form of contact information (web site, email address, user page on ArchWiki or the forums, etc.).<br />
* If the repository is of the ''signed'' variety, please include a key-id, possibly using it as the anchor for a link to its keyserver; if the key is not on a keyserver, include a link to the key file.<br />
* Include some short description (e.g. the category of packages provided in the repository).<br />
* If there is a page (either on ArchWiki or external) containing more information about the repository, include a link to it.<br />
* If possible, avoid using comments in code blocks. The formatted description is much more readable. Users who want some comments in their {{ic|pacman.conf}} can easily create it on their own.<br />
<br />
Some repositories may also have packages for architectures beside x86_64. The {{ic|$arch}} variable will be set automatically by pacman.<br />
<br />
== Signed ==<br />
<br />
=== alerque ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/caleb Caleb Maclennan]<br />
* '''Description:''' Typesetting and publishing related tools such as SILE, CaSILE, fonts, and related dependencies including many Lua Rocks. Also mattermost, asterisk, and many of the [https://aur.archlinux.org/packages/?O=0&SeB=M&K=caleb&outdated=&SB=n&SO=a&PP=250&do_Search=Go AUR packages I (co-)maintain].<br />
* '''Key-ID:''' [https://pgp.mit.edu/pks/lookup?op=get&search=0x63CC496475267693 63CC496475267693]<br />
<br />
{{bc|<nowiki><br />
[alerque]<br />
https://arch.alerque.com/$arch<br />
</nowiki>}}<br />
<br />
=== andontie-aur ===<br />
<br />
* '''Maintainer:''' Holly M.<br />
* '''Description:''' A repo containing the most popular AUR packages, as well as some I use all the time. New packages can be requested on the upstream website.<br />
* '''Key-ID:''' EA50C866329648EE<br />
* '''Upstream page:''' https://aur.andontie.net<br />
<br />
{{bc|<nowiki><br />
[andontie-aur]<br />
Server = https://aur.andontie.net/$arch<br />
</nowiki>}}<br />
<br />
=== AniNIX ===<br />
* '''Maintainer:''' [http://foundation.aninix.net/DarkFeather DarkFeather]<br />
* '''Description:''' Self-written and AUR packages to support open-source cybersecurity research<br />
* ''''Key-ID:''' 904DE6275579CB589D85720C1CC1E3F4ED06F296<br />
* '''Upstream page:''' https://aninix.net<br />
* '''Git and issue tracking:''' https://foundation.aninix.net/<br />
* '''Contact:''' ircs://aninix.net:6697/#lobby<br />
<br />
{{bc|<nowiki><br />
[AniNIX]<br />
Server = https://maat.aninix.net/<br />
<br />
[aur]<br />
Server = https://maat.aninix.net/aur/<br />
</nowiki>}}<br />
<br />
=== arcanisrepo ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#arcanis arcanis]<br />
* '''Description:''' A repository with some AUR packages including packages from VCS<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[arcanisrepo]<br />
Server = https://repo.arcanis.me/repo/$arch<br />
</nowiki>}}<br />
<br />
(It is also available via FTP with the same URL.)<br />
<br />
=== arch4edu ===<br />
<br />
* '''Maintainers:''' [https://github.com/petronny Jingbei Li (petronny)], and [https://github.com/arch4edu/arch4edu/graphs/contributors others]<br />
* '''Description:''' arch4edu is a community repository for Archlinux and ArchlinuxARM that strives to provide the latest versions of most software used by college students.<br />
* '''Git Repo:''' https://github.com/arch4edu/arch4edu<br />
* '''Issue tracking:''' https://github.com/arch4edu/arch4edu/issues for packaging issues, out-of-date notifications, package requests, and related questions<br />
* '''Mirrors:''' https://github.com/arch4edu/arch4edu/wiki/Add-arch4edu-to-your-Archlinux<br />
* '''Key-ID:''' 7931B6D628C8D3BA<br />
<br />
{{bc|<nowiki><br />
[arch4edu]<br />
Server = https://mirrors.tuna.tsinghua.edu.cn/arch4edu/$arch<br />
## or other mirrors in https://github.com/arch4edu/arch4edu/wiki/Add-arch4edu-to-your-Archlinux<br />
</nowiki>}}<br />
<br />
=== archlinuxcn ===<br />
<br />
* '''Maintainers:''' [https://plus.google.com/+PhoenixNemo/ Phoenix Nemo (phoenixlzx)], [https://www.archlinux.org/people/developers/#fyan Felix Yan (felixonmars, dev)], [https://twitter.com/lilydjwg lilydjwg], [https://www.archlinux.org/people/trusted-users/#farseerfc farseerfc (TU)], and [https://github.com/archlinuxcn/repo/graphs/contributors others]<br />
* '''Description:''' Packages by the Chinese Arch Linux community, all signed. Be aware that i686 packages are not fully maintained and tested, create an issue if you find some problems.<br />
* '''Git Repo:''' https://github.com/archlinuxcn/repo<br />
* '''Issue tracking:''' https://github.com/archlinuxcn/repo/issues for packaging issues, out-of-date notifications, package requests, and related questions<br />
* '''Mirrors:''' https://github.com/archlinuxcn/mirrorlist-repo (Mostly for users in mainland China), or install ''archlinuxcn-mirrorlist-git'' from the repo.<br />
* '''Key-ID:''' Once the repo is added, ''archlinuxcn-keyring'' package must be installed before any other so you do not get errors about PGP signatures. ''archlinuxcn-keyring'' package itself is signed by TU.<br />
<br />
{{bc|<nowiki><br />
[archlinuxcn]<br />
Server = http://repo.archlinuxcn.org/$arch<br />
## or install archlinuxcn-mirrorlist-git and use the mirrorlist<br />
#Include = /etc/pacman.d/archlinuxcn-mirrorlist<br />
</nowiki>}}<br />
<br />
=== archstrike ===<br />
<br />
* '''Maintainer:''' [https://archstrike.org/team The ArchStrike Team]<br />
* '''Description:''' A repository for security professionals and enthusiasts<br />
* '''Upstream page:''' https://archstrike.org/<br />
* '''Key-ID:''' 9D5F1C051D146843CDA4858BDE64825E7CBC0D51<br />
<br />
{{Note|ArchStrike specific instructions can be found at https://archstrike.org/wiki/setup}}<br />
<br />
{{bc|<nowiki><br />
[archstrike]<br />
Server = https://mirror.archstrike.org/$arch/$repo<br />
</nowiki>}}<br />
<br />
=== archzfs ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/minextu Jan Houben (minextu)]<br />
* '''Description:''' Packages for ZFS on Arch Linux.<br />
* '''Upstream page:''' https://github.com/archzfs/archzfs<br />
* '''Key-ID:''' F75D9D76<br />
<br />
{{bc|<nowiki><br />
[archzfs]<br />
Server = http://archzfs.com/$repo/x86_64<br />
</nowiki>}}<br />
<br />
=== archzfs-kernels ===<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/endre/ Endre Szabo]<br />
* '''Description:''' Official kernel packages matching the most recent [[# archzfs|ZFS packages]] kernel version dependencies. Use this to be able to upgrade your kernel package every time whilst using ZFS packages above :)<br />
* '''Upstream page:''' https://end.re/archzfs-kernels/<br />
* '''Key-ID:''' Not needed as packages are from core repos and signed officially.<br />
<br />
{{bc|<nowiki><br />
[archzfs-kernels]<br />
Server = http://end.re/$repo/<br />
</nowiki>}}<br />
<br />
=== ashleyis ===<br />
<br />
* '''Maintainer:''' Ashley Towns ([https://aur.archlinux.org/account/ashleyis/ ashleyis])<br />
* '''Description:''' Debug versions of SDL, chipmunk, libtmx and other misc game libraries. also swift-lang and some other AUR packages <br />
* '''Key-ID:''' B1A4D311<br />
<br />
{{bc|<nowiki><br />
[ashleyis]<br />
Server = http://arch.ashleytowns.id.au/repo/$arch<br />
</nowiki>}}<br />
<br />
=== Bennix Repo ===<br />
<br />
* '''Maintainer:''' Ben P. Dorsi-Todaro ([https://techmeout.org Tech Me Out])<br />
* '''Description:''' Packages [http://ben-dorsi-todaro.com/ Ben P. Dorsi-Todaro] uses and are not listed in repos, or packages built by [http://www.bigbenshosting.com/ Big Ben's Web Hosting] <br />
* '''Key-ID:''' F14BB858F6253DA0<br />
<br />
{{bc|<nowiki><br />
[bigben-repo]<br />
SigLevel = Optional TrustAll<br />
Server = http://bennix.net/bigben-repo/<br />
</nowiki>}}<br />
<br />
=== blackeagle-pre-community ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#idevolder Ike Devolder]<br />
* '''Description:''' testing of the by me maintaned packages before moving to ''community'' repository<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[blackeagle-pre-community]<br />
Server = https://repo.herecura.be/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== chaotic-aur ===<br />
<br />
* '''Maintainer:''' [https://github.com/pedrohlc PedroHLC], and [https://github.com/librewish Librewish]<br />
* '''Description:''' Auto builds AUR packages the maintainer uses, update them hourly (a few are daily). Hosted in São Carlos, SP, Brazil. Has two mirrors (Germany and USA). x86_64 only. Has over 1600 packages.<br />
* '''Key-ID:''' [http://pool.sks-keyservers.net/pks/lookup?search=0x3056513887B78AEB&fingerprint=on&op=index], fingerprint {{ic|EF92 5EA6 0F33 D0CB 85C4 4AD1 3056 5138 87B7 8AEB }}<br />
* '''Note:''' See [https://lonewolf.pedrohlc.com/chaotic-aur maintainer's notes].<br />
{{bc|<nowiki><br />
[chaotic-aur]<br />
Server = http://lonewolf-builder.duckdns.org/$repo/x86_64<br />
Server = http://chaotic.bangl.de/$repo/x86_64<br />
Server = https://repo.kitsuna.net/x86_64<br />
</nowiki>}}<br />
<br />
=== catalyst ===<br />
<br />
* '''Maintainer:''' [[User:Vi0L0|Vi0l0]]<br />
* '''Description:''' ATI Catalyst proprietary drivers.<br />
* '''Key-ID:''' 653C3094<br />
<br />
{{bc|<nowiki><br />
[catalyst]<br />
Server = http://167.86.114.169/arch/catalyst/$arch<br />
</nowiki>}}<br />
<br />
=== catalyst-hd234k ===<br />
<br />
* '''Maintainer:''' [[User:Vi0L0|Vi0l0]]<br />
* '''Description:''' ATI Catalyst proprietary drivers.<br />
* '''Key-ID:''' 653C3094<br />
<br />
{{bc|<nowiki><br />
[catalyst-hd234k]<br />
Server = http://167.86.114.169/arch/catalyst-hd234k/$arch<br />
</nowiki>}}<br />
<br />
=== city ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#bgyorgy Balló György]<br />
* '''Description:''' Experimental/unpopular packages.<br />
* '''Upstream page:''' https://pkgbuild.com/~bgyorgy/city.html<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[city]<br />
Server = https://pkgbuild.com/~bgyorgy/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
=== coderkun-aur ===<br />
<br />
{{Out of date|Repository does not seem available anymore.}}<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with random software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://www.suruatoel.xyz/arch<br />
* '''Key-ID:''' 39E27199A6BEE374<br />
* '''Keyfile:''' [https://www.suruatoel.xyz/coderkun.asc https://www.suruatoel.xyz/coderkun.asc]{{Dead link|2020|02|26}}<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur]<br />
Server = http://arch.suruatoel.xyz/$repo/$arch/<br />
</nowiki>}}<br />
<br />
=== coderkun-aur-audio ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/coderkun/ coderkun]<br />
* '''Description:''' AUR packages with audio-related (realtime kernels, lv2-plugins, …) software. Supporting package deltas and package and database signing.<br />
* '''Upstream page:''' https://www.suruatoel.xyz/arch<br />
* '''Key-ID:''' 39E27199A6BEE374<br />
* '''Keyfile:''' [https://www.suruatoel.xyz/coderkun.key https://www.suruatoel.xyz/coderkun.key]<br />
<br />
{{bc|<nowiki><br />
[coderkun-aur-audio]<br />
Server = http://arch.suruatoel.xyz/$repo/$arch/<br />
</nowiki>}}<br />
<br />
=== devkitpro ===<br />
<br />
* '''Maintainer:''' [https://devkitpro.org/ wintermute]<br />
* '''Description:''' Provides Homebrew toolchains for the Nintendo Wii, Gamecube, DS, GBA, Gamepark gp32 and Nintendo Switch<br />
* '''Upstream page:''' https://devkitpro.org/wiki/devkitPro_pacman<br />
* '''Key-ID:''' F7FD5492264BB9D0<br />
<br />
{{Note|Repository has its own additional keyring at https://downloads.devkitpro.org/devkitpro-keyring-r1.787e015-2-any.pkg.tar.xz.}}<br />
<br />
{{bc|<nowiki><br />
[dkp-libs]<br />
Server = https://downloads.devkitpro.org/packages<br />
[dkp-linux]<br />
Server = https://downloads.devkitpro.org/packages/linux<br />
</nowiki>}}<br />
<br />
=== disastrousaur ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/TheGoliath TheGoliath]<br />
* '''Description:''' Well known AUR package managers, many of the most popular packages available on the AUR, as well as those that I favor myself<br />
* '''Upstream page:''' https://mirror.repohost.de/disastrousaur<br />
* '''Key-ID:''' CBAE582A876533FD<br />
* '''Keyfile:''' [https://mirror.repohost.de/disastrousaur.key https://mirror.repohost.de/disastrousaur.key]<br />
{{Warning|disastrousaur and disastrousarm have now been merged under the disastrousaur name Please make sure you have changed the Server URL for your repos accordingly. Builds for other architectures may come out as I got enough time getting things running. }}<br />
{{bc|<nowiki><br />
[disastrousaur]<br />
Server = https://mirror.repohost.de/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== dvzrv ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/developers/#dvzrv David Runge]<br />
* '''Description:''' [[Realtime kernel patchset]] (aka. {{AUR|linux-rt}} and {{AUR|linux-rt-lts}})<br />
* '''Key-ID:''' Not needed, as maintainer is a developer/TU<br />
<br />
{{bc|<nowiki><br />
[dvzrv]<br />
Server = https://pkgbuild.com/~dvzrv/repo/$arch<br />
</nowiki>}}<br />
<br />
=== ear ===<br />
<br />
* '''Maintainer:''' [https://wardsegers.be Ward Segers], <br />
* '''Description:''' Editicalu's ArchLinux Repository. Contains precompiled AUR packages (mostly the ones maintained by editicalu)<br />
* '''Homepage:''' https://ear.wardsegers.be/<br />
* '''Upstream page:''' https://gitlab.com/editicalu/ear<br />
* '''Keyfile:''' https://ear.wardsegers.be/signingkey.asc<br />
* '''Key-ID:''' A9C4E7734638ACF8<br />
<br />
{{Note|Instructions can be found at https://ear.wardsegers.be}}<br />
<br />
{{bc|<nowiki><br />
[ear]<br />
Server = https://ear.wardsegers.be/$arch<br />
</nowiki>}}<br />
<br />
=== eatabrick ===<br />
<br />
* '''Maintainer:''' bentglasstube<br />
* '''Description:''' Packages for software written by (and a few just compiled by) bentglasstube.<br />
<br />
{{bc|<nowiki><br />
[eatabrick]<br />
Server = http://repo.eatabrick.org/$arch<br />
</nowiki>}}<br />
<br />
=== eschwartz ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#eschwartz Eli Schwartz]<br />
* '''Description:''' Personal repo with AUR packages and some core packages from git (including glibc and pacman). Contains debug packages.<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[eschwartz]<br />
Server = https://pkgbuild.com/~eschwartz/repo/$arch<br />
</nowiki>}}<br />
<br />
=== ffy00 ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#FFY00 Filipe Laíns]<br />
* '''Description:''' Personal repo. Contains some packages related to the D language.<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[ffy00]<br />
Server = https://pkgbuild.com/~ffy00/repo<br />
</nowiki>}}<br />
<br />
=== fusion809 ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/fusion809|Brenton Horne]] (brentonhorne77 at gmail dot com).<br />
* '''Description:''' Provides a few AUR and other packages I like. Like CodeLite and bleeding-edge (latest release within 1 day of its release) GVim (GTK 2 interface).<br />
* '''Package list:''' http://download.opensuse.org/repositories/home:/fusion809/Arch_Extra/x86_64/<br />
* '''Key-ID:''' 03264DDCD606DC98<br />
* '''Keyfile:''' https://download.opensuse.org/repositories/home:/fusion809/Arch_Extra/x86_64/home_fusion809_Arch_Extra.key<br />
<br />
{{bc|<nowiki><br />
[home_fusion809_Arch_Extra]<br />
Server = https://download.opensuse.org/repositories/home:/fusion809/Arch_Extra/$arch<br />
</nowiki>}}<br />
<br />
=== grawlinson ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/grawlinson George Rawlinson]<br />
* '''Description:''' AUR packages maintained by the user as well as some experimental packages.<br />
* '''Package list:''' https://repo.nullpointer.io<br />
* '''Key-ID:''' 25EA6900D9EA5EBC<br />
* '''Keyfile:''' https://repo.nullpointer.io/grawlinson.key<br />
<br />
{{bc|<nowiki><br />
[grawlinson]<br />
Server = https://repo.nullpointer.io<br />
</nowiki>}}<br />
<br />
=== gnome-devel ===<br />
<br />
* '''Maintainer:''' [https://plus.google.com/+AndresFernandezperonista Andres Fernandez], [https://plus.google.com/+FernandoFernandezBerel Fernando Fernandez]<br />
* '''Description:''' GNOME development releases. For testing purposes only.<br />
* '''Package list:''' https://softwareperonista.com.ar/repo/archlinux/gnome-devel/x86_64/<br />
* '''Key-ID:''' DDCE9FD63370080B<br />
<br />
{{Note|Must be put above {{ic|[testing]}} repository.}}<br />
<br />
{{bc|<nowiki><br />
[gnome-devel]<br />
Server = https://softwareperonista.com.ar/repo/archlinux/gnome-devel/$arch<br />
</nowiki>}}<br />
<br />
=== herecura ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#idevolder Ike Devolder]<br />
* '''Description:''' additional packages not found in the ''community'' repository<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[herecura]<br />
Server = https://repo.herecura.be/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== holo ===<br />
<br />
* '''Maintainer:''' Stefan Majewsky <holo-pacman@posteo.de> (please prefer to report issues at [https://github.com/majewsky/holo-pacman-repo/issues Github])<br />
* '''Description:''' Packages for [https://holocm.org Holo configuration management], including compatible plugins and tools.<br />
* '''Upstream page:''' https://github.com/majewsky/holo-pacman-repo<br />
* '''Package list:''' https://repo.holocm.org/archlinux/x86_64<br />
* '''Key-ID:''' 0xF7A9C9DC4631BD1A<br />
<br />
{{bc|<nowiki><br />
[holo]<br />
Server = https://repo.holocm.org/archlinux/x86_64<br />
</nowiki>}}<br />
<br />
=== ivasilev ===<br />
<br />
* '''Maintainer:''' [https://ivasilev.net Ianis G. Vasilev]<br />
* '''Description:''' A variety of packages, mostly my own software and AUR builds.<br />
* '''Upstream page:''' https://ivasilev.net/pacman<br />
* '''Key-ID:''' [https://pgp.mit.edu/pks/lookup?op=vindex&search=0xB77A3C8832838F1F80ADFD7E1D0507B417DAB671 17DAB671]<br />
<br />
{{bc|<nowiki><br />
[ivasilev]<br />
Server = https://ivasilev.net/pacman/$arch<br />
</nowiki>}}<br />
<br />
=== jlk ===<br />
<br />
* '''Maintainer:''' [[User:Lahwaacz|Jakub Klinkovský]]<br />
* '''Description:''' Various packages from the ABS and AUR. Modified packages are in the {{ic|modified}} group.<br />
* '''Upstream page:''' https://jlk.fjfi.cvut.cz/arch/repo/README.html<br />
* '''Key-ID:''' 932BA3FA0C86812A32D1F54DAB5964AEB9FEDDDC<br />
<br />
{{bc|<nowiki><br />
[jlk]<br />
Server = https://jlk.fjfi.cvut.cz/arch/repo<br />
</nowiki>}}<br />
<br />
=== markzz ===<br />
<br />
* '''Maintainer:''' [[User:Markzz|Mark Weiman (markzz)]]<br />
* '''Description:''' Packages that markzz maintains or uses on the AUR; this includes Linux with the vfio patchset ({{AUR|linux-vfio}} and {{AUR|linux-vfio-lts}}), and packages for analysis of network data.<br />
* '''Key ID:''' DEBB9EE4<br />
<br />
{{Note|If you want to add the key by installing the ''markzz-keyring'' package, temporarily add {{ic|1=SigLevel = Never}} into the repository section.}}<br />
<br />
{{bc|<nowiki><br />
[markzz]<br />
Server = https://repo.markzz.com/arch/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== maximbaz ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#maximbaz Maxim Baz]<br />
* '''Description:''' Personal repo with AUR packages.<br />
* '''Key-ID:''' Not needed, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[maximbaz]<br />
Server = https://pkgbuild.com/~maximbaz/repo/<br />
</nowiki>}}<br />
<br />
=== me176c ===<br />
<br />
* '''Maintainer:''' [https://github.com/lambdadroid lambdadroid]<br />
* '''Description:''' Packages for [[ASUS MeMO Pad 7 (ME176C(X))]]<br />
* '''Key-ID:''' 2B1138A8BB59D786A3BF42AAD996DA70572407FB<br />
<br />
{{bc|<nowiki><br />
[me176c]<br />
Server = https://me176c.uber.space/archlinux<br />
</nowiki>}}<br />
<br />
=== miffe ===<br />
<br />
* '''Maintainer:''' [https://bbs.archlinux.org/profile.php?id=4059 miffe]<br />
* '''Description:''' AUR packages maintained by miffe, e.g. linux-mainline<br />
* '''Key ID:''' 313F5ABD<br />
<br />
{{bc|<nowiki><br />
[miffe]<br />
Server = https://arch.miffe.org/$arch/<br />
</nowiki>}}<br />
<br />
=== mikelpint ===<br />
<br />
* '''Maintainer:''' [[User:Mikelpint|Mikel Pintado (Mikelpint)]]<br />
* '''Description:''' Packages that mikelpint maintains in the AUR.<br />
* '''Key ID:''' 5CA78FC65B189E2B<br />
<br />
{{bc|<nowiki><br />
[mikelpint]<br />
Server = https://mikelpint.github.io/repository/archlinux/repo<br />
</nowiki>}}<br />
<br />
=== Minerva W Science ===<br />
<br />
* '''Maintainer:''' Minerva W<br />
* '''Description:''' [[OpenFOAM]] packages.<br />
* '''Key-ID:''' 3FF21B78117507DA<br />
* '''Keyfile:''' https://download.opensuse.org/repositories/home:/Minerva_W:/Science/Arch_Extra/x86_64/home_Minerva_W_Science_Arch_Extra.key<br />
<br />
{{bc|<nowiki><br />
[home_Minerva_W_Science_Arch_Extra]<br />
Server = https://download.opensuse.org/repositories/home:/Minerva_W:/Science/Arch_Extra/$arch <br />
</nowiki>}}<br />
<br />
=== mobile ===<br />
<br />
* '''Maintainer:''' [https://keybase.io/farwayer farwayer]<br />
* '''Description:''' React Native and Android development<br />
* '''Upstream page:''' https://keybase.pub/farwayer/arch/mobile/<br />
* '''Key ID:''' 7943315502A936D7<br />
<br />
{{bc|<nowiki><br />
[mobile]<br />
Server = https://farwayer.keybase.pub/arch/$repo<br />
</nowiki>}}<br />
<br />
=== nah ===<br />
<br />
* '''Maintainer:''' [https://yeah.nah.nz phillid]<br />
* '''Description:''' Pre-built versions of the (slow-to-build) graph-tool python libraries, mingw-w64<br />
* '''Key ID:''' 7BF3D17D0884BF5B<br />
<br />
{{bc|<nowiki><br />
[nah]<br />
Server = https://repo.nah.nz/$repo<br />
</nowiki>}}<br />
<br />
=== nickcao ===<br />
<br />
* '''Maintainer:''' [https://nichi.co/ NickCao]<br />
* '''Description:''' Some (useful for some) packages from me, and some aur packages I personally use.<br />
* '''Key-ID:''' 09CC69622E8D4EE343B4E8954D0BA456DF028C15<br />
<br />
{{bc|<nowiki><br />
[nickcao]<br />
Server = https://repo.nichi.co/$arch<br />
</nowiki>}}<br />
<br />
=== origincode ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/OriginCode OriginCode]<br />
* '''Description:''' A few staging or testing packages from [[#archlinuxcn]], and some daily use packages.<br />
* '''Key-ID:''' 0A5BAD445D80C1CC & 62BF97502AE10D22<br />
<br />
{{bc|<nowiki><br />
[origincode]<br />
Server = https://repo.origincode.me/repo/$arch<br />
</nowiki>}}<br />
<br />
=== oscloud ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/bionade24 bionade24]<br />
* '''Description:''' ROS Melodic packages and needed dependencies from the AUR.<br />
* '''Key-ID:''' 289AD6AA32857A04ABA587417EAC11ACDBCFBCEB<br />
<br />
{{bc|<nowiki><br />
[oscloud]<br />
Server = http://repo.oscloud.info/<br />
</nowiki>}}<br />
<br />
=== pkgbuilder ===<br />
<br />
* '''Maintainer:''' [https://chriswarrick.com/ Chris Warrick]<br />
* '''Description:''' A repository for PKGBUILDer, a Python AUR helper.<br />
* '''Upstream page:''' https://github.com/Kwpolska/pkgbuilder<br />
* '''Key-ID:''' 5EAAEA16<br />
<br />
{{bc|<nowiki><br />
[pkgbuilder]<br />
Server = https://pkgbuilder-repo.chriswarrick.com/<br />
</nowiki>}}<br />
<br />
=== post-factum kernels ===<br />
<br />
* '''Maintainer''': [https://aur.archlinux.org/account/post-factum Oleksandr Natalenko aka post-factum]<br />
* '''Upstream page''': https://gitlab.com/post-factum/pf-kernel/wikis/README<br />
* '''Description''': [[Kernel#Major_patchsets|pf-kernel]] packages by its developer, post-factum<br />
* '''Key-ID:''': 95C357D2AF5DA89D<br />
* '''Keyfile''': https://download.opensuse.org/repositories/home:/post-factum:/kernels/Arch/x86_64/home_post-factum_kernels_Arch.key<br />
<br />
{{bc|<nowiki><br />
[home_post-factum_kernels_Arch]<br />
Server = https://download.opensuse.org/repositories/home:/post-factum:/kernels/Arch/$arch<br />
</nowiki>}}<br />
<br />
=== QOwnNotes ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/pbek Patrizio Bekerle] (pbek), QOwnNotes author<br />
* '''Description:''' QOwnNotes is a open source notepad and todo list manager with markdown support and [[ownCloud]] integration.<br />
* '''Key-ID:''' FFC43FC94539B8B0<br />
* '''Keyfile:''' https://download.opensuse.org/repositories/home:/pbek:/QOwnNotes/Arch_Extra/x86_64/home_pbek_QOwnNotes_Arch_Extra.key<br />
<br />
{{bc|<nowiki><br />
[home_pbek_QOwnNotes_Arch_Extra]<br />
Server = https://download.opensuse.org/repositories/home:/pbek:/QOwnNotes/Arch_Extra/$arch<br />
</nowiki>}}<br />
<br />
=== qt-debug ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/The-Compiler The Compiler]<br />
* '''Description:''' Qt/PyQt builds with debug symbols<br />
* '''Upstream page:''' https://github.com/qutebrowser/qt-debug-pkgbuild<br />
* '''Key-ID:''' D6A1C70FE80A0C82<br />
<br />
{{bc|<nowiki><br />
[qt-debug]<br />
Server = https://qutebrowser.org/qt-debug/$arch<br />
</nowiki>}}<br />
<br />
=== quarry ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/developers/#anatolik anatolik]<br />
* '''Description:''' Arch binary repository for [http://rubygems.org/ Rubygems] packages. See [https://bbs.archlinux.org/viewtopic.php?id=182729 forum announcement] for more information.<br />
* '''Sources:''' https://github.com/anatol/quarry<br />
* '''Key-ID:''' Not needed, as maintainer is a developer<br />
<br />
{{bc|<nowiki><br />
[quarry]<br />
Server = https://pkgbuild.com/~anatolik/quarry/x86_64/<br />
</nowiki>}}<br />
<br />
=== repo-ck ===<br />
<br />
Kernel and modules with Brain Fuck Scheduler and all the goodies in the ck1 patch set.<br />
<br />
See [[/Repo-ck]].<br />
<br />
=== seblu ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/developers/#seblu Sébastien Luttringer]<br />
* '''Description:''' All seblu useful pre-built packages, some homemade (linux-seblu-meta, zfs-dkms, spotify, masterpdfeditor, etc).<br />
* '''Key-ID:''' Not required, as maintainer is a Developer<br />
<br />
{{bc|<nowiki><br />
[seblu]<br />
Server = https://al1.seblu.net/$repo/$arch<br />
Server = https://al2.seblu.net/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== seiichiro ===<br />
<br />
* '''Maintainer:''' [https://www.seiichiro0185.org Stefan Brand (seiichiro0185)]<br />
* '''Description:''' AUR-packages I use frequently<br />
* '''Key-ID:''' 805517CC<br />
<br />
{{bc|<nowiki><br />
[seiichiro]<br />
Server = https://www.seiichiro0185.org/repo/$arch<br />
</nowiki>}}<br />
<br />
=== selinux ===<br />
<br />
* '''Maintainer:''' [https://github.com/swordfeng swordfeng]<br />
* '''Description:''' Unofficial (personal) builds for [[SELinux]] packages. PKGBUILDs are taken from AUR instead of the upstream GitHub repo.<br />
* '''Upstream page:''' https://github.com/archlinuxhardened/selinux<br />
* '''Key-ID:''' 7691FA63FE91CAFDD42A4AF08323B00E97DF0E6D (subkey B988167F59A3AF8368D55D65A7862FD48B72D83B is specifically used for signing packages)<br />
* '''Keyfile:''' https://repo.taiho.moe/key.asc<br />
<br />
{{bc|<nowiki><br />
[selinux]<br />
Server = https://repo.taiho.moe/$repo<br />
</nowiki>}}<br />
<br />
=== sergej-repo ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#spupykin Sergej Pupykin]<br />
* '''Description:''' psi-plus, owncloud-git, ziproxy, android, MySQL, and other stuff. Some packages also available for armv7h.<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[sergej-repo]<br />
Server = http://repo.p5n.pp.ru/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
=== siosm-aur ===<br />
<br />
* '''Maintainer:''' [https://tim.siosm.fr/about/ Timothee Ravier]<br />
* '''Description:''' packages also available in the Arch User Repository, sometimes with minor fixes<br />
* '''Upstream page:''' https://tim.siosm.fr/repositories/<br />
* '''Key-ID:''' 78688F83<br />
<br />
{{bc|<nowiki><br />
[siosm-aur]<br />
Server = http://siosm.fr/repo/$repo/<br />
</nowiki>}}<br />
<br />
=== slowbro ===<br />
<br />
* '''Maintainer:''' Katelyn Schiesser (slowbro)<br />
* '''Description:''' binary packages for {{AUR|linux-vfio}}<br />
* '''Key-ID:''' [http://pool.sks-keyservers.net/pks/lookup?op=get&search=0xAB3139C285186206 85186206]<br />
<br />
{{bc|<nowiki><br />
[slowbro]<br />
Server = http://www.slowbro.org/arch/$arch/<br />
</nowiki>}}<br />
<br />
=== sublime-text ===<br />
<br />
* '''Maintainer:''' Sublime Text developer<br />
* '''Description:''' Sublime Text editor packages from developer's repository<br />
* '''Upstream page:''' https://www.sublimetext.com/docs/3/linux_repositories.html#pacman<br />
* '''Key-ID:''' 8A8F901A<br />
<br />
{{bc|<nowiki><br />
[sublime-text]<br />
Server = https://download.sublimetext.com/arch/stable/x86_64<br />
</nowiki>}}<br />
<br />
=== subtitlecomposer ===<br />
<br />
* '''Maintainer:''' Mladen Milinkovic (maxrd2)<br />
* '''Description:''' Subtitle Composer stable and nightly builds<br />
* '''Upstream page:''' https://github.com/maxrd2/subtitlecomposer<br />
* '''Key-ID:''' EF9D9B26<br />
<br />
{{bc|<nowiki><br />
[subtitlecomposer]<br />
Server = https://smoothware.net/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== trinity ===<br />
<br />
* '''Maintainer:''' Michael J. Manley <mmanley@ntge.net><br />
* '''Description:''' [[Trinity]] Desktop Environment<br />
* '''Key-ID:''' 5F710C1E<br />
<br />
{{bc|<nowiki><br />
[trinity]<br />
Server = https://repo.nasutek.com/arch/contrib/trinity/x86_64<br />
</nowiki>}}<br />
<br />
=== valveaur ===<br />
<br />
* '''Maintainer:''' John Schoenick <johns@valvesoftware.com> (https://valvesoftware.com)<br />
* '''Description:''' A repository by Valve Software Providing The Linux-fsync kernel and modules, including the futex-wait-multiple patchset for testing with Proton fsync & Mesa with the ACO compiler patchset. <br />
* '''Upstream page:''' https://steamcommunity.com/linux<br />
* '''Key-ID:''' 8DC2CE3A3D245E64<br />
<br />
{{bc|<nowiki><br />
[valveaur]<br />
Server = http://repo.steampowered.com/arch/valveaur<br />
</nowiki>}}<br />
<br />
=== xuanrui ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/xuanruiqi Xuanrui Qi (xuanruiqi)]<br />
* '''Description:''' xuanruiqi's own packages and frequently-used packages, mainly of interest to functional programmers.<br />
* '''Upstream Page:''' https://www.xuanruiqi.com/linux.html<br />
* '''Key-ID:''' 6E06FBC8<br />
<br />
{{bc|<nowiki><br />
[xuanrui]<br />
Server = https://arch.xuanruiqi.com/repo<br />
</nowiki>}}<br />
<br />
=== xyne-x86_64 ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
* '''Key-ID:''' Not required, as maintainer is a TU<br />
<br />
{{bc|<nowiki><br />
[xyne-x86_64]<br />
# Server = https://xyne.archlinux.ca/repos/xyne # It returns error 404 or 406 (varying). Use the line below:<br />
Server = http://xyne.archlinux.ca/bin/repo.php?file=<br />
</nowiki>}}<br />
<br />
=== home-thaodan ===<br />
<br />
* '''Maintainer''': [https://aur.archlinux.org/account/Thaodan Thaodan]<br />
* '''Upstream page''': https://gitlab.com/Thaodan/linux-pf<br />
* '''Description''': [[Kernel#Major_patchsets|pf-kernel]] and other packages by pf-kernel fork developer, Thaodan<br />
* '''Gitlab Project''': https://gitlab.com/Thaodan/repo-home-thaodan-repo<br />
* '''Key-ID:''': BBFE2FD421597395E4FC8C8DF6C85FEE79D661A4<br />
<br />
{{bc|<nowiki><br />
[home-thaodan]<br />
Server = https://thaodan.de/public/archlinux/home-thaodan/$arch<br />
</nowiki>}}<br />
<br />
== Unsigned ==<br />
<br />
{{Note|Users will need to add the following to these entries: {{ic|1=SigLevel = PackageOptional}}}}<br />
<br />
=== alucryd ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#alucryd Maxime Gauduin]<br />
* '''Description:''' Various packages Maxime Gauduin maintains (or not) in the AUR.<br />
<br />
{{bc|<nowiki><br />
[alucryd]<br />
Server = https://pkgbuild.com/~alucryd/$repo/x86_64<br />
</nowiki>}}<br />
<br />
=== alucryd-multilib ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#alucryd Maxime Gauduin]<br />
* '''Description:''' Various packages needed to run Steam without its runtime environment.<br />
<br />
{{bc|<nowiki><br />
[alucryd-multilib]<br />
Server = https://pkgbuild.com/~alucryd/$repo/x86_64<br />
</nowiki>}}<br />
<br />
=== andrwe ===<br />
<br />
* '''Maintainer:''' Andrwe Lord Weber<br />
* '''Description:''' contains programs I'm using on many systems<br />
* '''Upstream page:''' http://andrwe.org/linux/repository<br />
<br />
{{bc|<nowiki><br />
[andrwe]<br />
Server = http://repo.andrwe.org/$arch<br />
</nowiki>}}<br />
<br />
=== archgeotux ===<br />
<br />
* '''Maintainer:''' Samuel Mesa<br />
* '''Description:''' Geospatial and geographic information system applications<br />
* '''Upstream page:''' https://archgeotux.sourceforge.io/<br />
<br />
{{bc|<nowiki><br />
[archgeotux]<br />
Server = https://downloads.sourceforge.net/project/archgeotux/$arch<br />
</nowiki>}}<br />
<br />
=== archlinuxfr ===<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
* '''Upstream page:''' http://afur.archlinux.fr<br />
<br />
{{bc|<nowiki><br />
[archlinuxfr]<br />
Server = http://repo.archlinux.fr/$arch<br />
</nowiki>}}<br />
<br />
=== archlinuxgr ===<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' many interesting packages provided by the Hellenic (Greek) Arch Linux community<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr]<br />
Server = http://archlinuxgr.tiven.org/archlinux/$arch<br />
</nowiki>}}<br />
<br />
=== archlinuxgr-kde4 ===<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' KDE4 packages (plasmoids, themes etc) provided by the Hellenic (Greek) Arch Linux community<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr-kde4]<br />
Server = http://archlinuxgr.tiven.org/archlinux-kde4/$arch<br />
</nowiki>}}<br />
<br />
=== aur-av-bin ===<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/milk/ milkii] (ping me on Freenode)<br />
* '''Description:''' Precompiled Arch Linux binary packages of mostly audio and music related software from the AUR.<br />
* '''Upstream page:''' https://github.com/mxmilkb/aur-av-bin<br />
<br />
{{bc|<nowiki><br />
[aur-av-bin]<br />
SigLevel = PackageOptional<br />
Server = https://github.com/mxmilkb/aur-av-bin/releases/download/repository<br />
</nowiki>}}<br />
<br />
=== dx37essentials ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/DragonX256 DragonX256]<br />
* '''Description:''' Personal repository. Contains packages from AUR, which I using every day.<br />
* '''Git repo:''' https://gitlab.com/DX37/dx37essentials<br />
* '''Upstream page:''' https://dx37.gitlab.io/dx37essentials<br />
<br />
{{bc|<nowiki><br />
[dx37essentials]<br />
Server = https://dx37.gitlab.io/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== heftig ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/developers/#heftig Jan Steffens]<br />
* '''Description:''' Includes pulseaudio-git, pavucontrol-git, and firefox-developer-edition<br />
* '''Upstream page:''' https://bbs.archlinux.org/viewtopic.php?id=117157<br />
<br />
{{bc|<nowiki><br />
[heftig]<br />
Server = https://pkgbuild.com/~heftig/repo/$arch<br />
</nowiki>}}<br />
<br />
=== jkanetwork ===<br />
<br />
* '''Maintainer:''' kprkpr <kevin01010 at gmail dot com><br />
* '''Maintainer:''' Joselucross <jlgarrido97 at gmail dot com><br />
* '''Description:''' Packages of AUR like pimagizer,stepmania,yaourt,linux-mainline,wps-office,grub-customizer,some IDE.. Open for all that wants to contribute<br />
* '''Upstream page:''' http://repo.jkanetwork.com/<br />
<br />
{{bc|<nowiki><br />
[jkanetwork]<br />
Server = http://repo.jkanetwork.com/repo/$repo/<br />
</nowiki>}}<br />
<br />
=== juju ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/Juju Juju]<br />
* '''Description:''' Emulators and development tools for some retro computers such as the Commander X16 and the TI-84+, along with some of my packages I maintain on the AUR<br />
* '''Upstream page:''' http://repo.juju2143.ca/<br />
<br />
{{bc|<nowiki><br />
[juju]<br />
Server = https://repo.juju2143.ca/archlinux/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
=== kodi-devel-prebuilt ===<br />
<br />
* '''Maintainer:''' asm0dey <pavel.finkelshtein+AUR@gmail.com><br />
* '''Description:''' Prebuilt packages of kodi-devel from AUR<br />
* '''Upstream page:''' {{AUR|kodi-devel}}<br />
<br />
{{bc|<nowiki><br />
[kodi-devel-prebuilt]<br />
Server = https://asm0dey.github.io/$repo/$arch<br />
SigLevel = PackageOptional<br />
</nowiki>}}<br />
<br />
=== mesa-git ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#lcarlier Laurent Carlier]<br />
* '''Description:''' Mesa git builds for the ''testing'' and ''multilib-testing'' repositories<br />
<br />
{{bc|<nowiki><br />
[mesa-git]<br />
Server = https://pkgbuild.com/~lcarlier/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== oracle ===<br />
<br />
* '''Maintainer:''' [[User:Malvineous]]<br />
* '''Description:''' [[Oracle Database client]] and associated tools, built from AUR packages and hosted on AWS S3 using [https://github.com/Malvineous/archlinux-pacman-repo Makefile scripts].<br />
* '''Conditions:''' By using this repository you agree to the [http://www.oracle.com/technetwork/licenses/instant-client-lic-152016.html Oracle Technology Network Development and Distribution License Terms for Instant Client].<br />
{{bc|<nowiki><br />
[oracle]<br />
Server = http://linux.shikadi.net/arch/$repo/$arch/<br />
</nowiki>}}<br />
<br />
=== ownstuff ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/Martchus Martchus]<br />
* '''Description:''' A lot of packages from the AUR, e.g. a great number packages for mingw-w64 and Android cross compilation, fonts, Perl modules, tools like {{AUR|tageditor}}, {{AUR|syncthingtray}}, {{AUR|subtitlecomposer}} and {{AUR|qmplay2}}<br />
* '''Upstream page''': https://github.com/Martchus/PKGBUILDs (sources beside the AUR) and https://martchus.no-ip.biz/repoindex (package browser/search)<br />
<br />
{{bc|<nowiki><br />
[ownstuff-testing]<br />
Server = https://ftp.f3l.de/~martchus/$repo/os/$arch<br />
Server = https://martchus.no-ip.biz/repo/arch/$repo/os/$arch<br />
<br />
[ownstuff]<br />
Server = https://ftp.f3l.de/~martchus/$repo/os/$arch<br />
Server = https://martchus.no-ip.biz/repo/arch/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
{{Note|The testing repository is supposed to be used together with the official testing repositories.}}<br />
<br />
=== pantheon ===<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/people/trusted-users/#alucryd Maxime Gauduin]<br />
* '''Description:''' Repository containing Pantheon-related packages<br />
<br />
{{bc|<nowiki><br />
[pantheon]<br />
Server = https://pkgbuild.com/~alucryd/$repo/$arch<br />
</nowiki>}}<br />
<br />
=== pietma ===<br />
<br />
* '''Maintainer:''' MartiMcFly <martimcfly@autorisation.de><br />
* '''Description:''' Arch User Repository packages [https://aur.archlinux.org/packages/?K=martimcfly&SeB=m I create or maintain.].<br />
* '''Upstream page:''' http://pietma.com/tag/aur/<br />
<br />
{{bc|<nowiki><br />
[pietma]<br />
Server = http://repository.pietma.com/nexus/content/repositories/archlinux/$arch/$repo<br />
</nowiki>}}<br />
<br />
=== pnsft-pur ===<br />
<br />
* '''Maintainer:''' [https://aur.archlinux.org/account/ponsfoot ponsfoot]<br />
* '''Description:''' Japanese input method packages Mozc (vanilla) and libkkc<br />
<br />
{{bc|<nowiki><br />
[pnsft-pur]<br />
Server = https://osdn.net/projects/ponsfoot-aur/storage/pur/x86_64/<br />
</nowiki>}}<br />
<br />
=== stx4 ===<br />
<br />
* '''Maintainer:''' StarterX4 <starterx4[at]gmail.com><br />
* '''Description:''' Any – some fonts and fakepkgs; x86_64 – archived yet might useful packages (like PacmanXG4) and some AUR soft (like OpenBoard).<br />
* '''Upstream Page:''' https://keybase.pub/starterx4/repos/arch/<br />
<br />
{{bc|<nowiki><br />
[stx4-any]<br />
SigLevel = Never<br />
Server = https://starterx4.keybase.pub/repos/arch/any/stx4<br />
<br />
[stx4-x86_64]<br />
SigLevel = Never<br />
Server = https://starterx4.keybase.pub/repos/arch/x86_64/stx4<br />
</nowiki>}}<br />
<br />
=== titanium ===<br />
<br />
* '''Maintainer:''' Pyrerune <pyrerune@gmail.com><br />
* '''Description:''' Repository containing software I develop.<br />
{{bc|<nowiki><br />
[titanium]<br />
Server = https://pyrerune.github.io/titanium/$arch<br />
</nowiki>}}<br />
<br />
=== userrepository ===<br />
<br />
* '''Maintainer:''' [https://twitter.com/brunomiguel Bruno Miguel] <brunoalexandremiguel@gmail.com><br />
* '''Description:''' Repository containing software from AUR<br />
{{bc|<nowiki><br />
[userrepository]<br />
Server = https://userrepository.eu<br />
</nowiki>}}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=TrackPoint&diff=578892TrackPoint2019-08-03T06:02:49Z<p>Slowbro: add a fix from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1788928 regarding two-finger scroll and other trackpoint features ceasing to work after sleep</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Lenovo]]<br />
[[ja:トラックポイント]]<br />
[[zh-hans: TrackPoint]]<br />
The TrackPoint is Lenovo's trademark for the pointing-stick in the middle of the keyboard. It is supported by {{Pkg|xf86-input-evdev}} and {{Pkg|xf86-input-libinput}}. <br />
<br />
Default [[Xorg]] behavior supports click and point. For the {{ic|evdev}} driver middle-click and scrolling requires extra configuration.<br />
<br />
== GUI configuration ==<br />
<br />
[[Install]] the {{AUR|gpointing-device-settings}} package.<br />
<br />
{{Note|This software is not maintained anymore (last release in 2013).<br />
It may not allow deep configuration when {{Pkg|xf86-input-libinput}} is used. }}<br />
<br />
== Middle button scroll ==<br />
<br />
When using {{Pkg|xf86-input-libinput}}, middle-button scrolling is enabled by default. <br />
<br />
When using {{Pkg|xf86-input-evdev}}, middle-button scrolling is supported via ''xinput'' from the {{Pkg|xorg-xinput}} package. For example:<br />
<br />
{{hc|~/.xinitrc|<br />
xinput set-prop "''TPPS/2 IBM TrackPoint''" "Evdev Wheel Emulation" 1<br />
xinput set-prop "''TPPS/2 IBM TrackPoint''" "Evdev Wheel Emulation Button" 2<br />
xinput set-prop "''TPPS/2 IBM TrackPoint''" "Evdev Wheel Emulation Timeout" 200<br />
xinput set-prop "''TPPS/2 IBM TrackPoint''" "Evdev Wheel Emulation Axes" 6 7 4 5<br />
}}<br />
<br />
{{Note|<br />
* Devices names can be listed with {{ic|xinput --list}} or {{Pkg|hwinfo}}.<br />
* The {{ic|"Device Accel Constant Deceleration"}} line configures the sensitivity of the trackpoint.<br />
}}<br />
<br />
=== Xorg configuration ===<br />
<br />
Alternative to an {{ic|~/.xinitrc}} configuration, you can also create an [[Xorg#Configuration]] for the {{man|4|evdev}}driver. For example, as {{ic|/etc/X11/xorg.conf.d/20-thinkpad.conf}}, replacing {{ic|TPPS/2 IBM TrackPoint}} with the device name from ''xinput'':<br />
<br />
Section "InputClass"<br />
Identifier "Trackpoint Wheel Emulation"<br />
Driver "evdev"<br />
MatchProduct "''TPPS/2 IBM TrackPoint''"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "Emulate3Buttons" "false"<br />
Option "XAxisMapping" "6 7"<br />
Option "YAxisMapping" "4 5"<br />
EndSection<br />
<br />
=== Two-button trackpoints ===<br />
On two-button trackpoints, using {{Pkg|xf86-input-libinput}}, the scroll button can be set to right-click button without removing functionality. <br />
<br />
Replacing ''device'' with the device name from {{ic|xinput}}:<br />
<br />
$ xinput set-prop "''device''" "libinput Button Scrolling Button" 3<br />
<br />
== Sysfs attributes ==<br />
<br />
TrackPoints expose their attributes as files in {{ic|/sys/devices/platform/i8042/serio1/}}. For example, to manually enable the tap-to-click functionality:<br />
<br />
# echo -n 1 > /sys/devices/platform/i8042/serio1/press_to_select<br />
<br />
{{Note|The location of the attribute files may be different depending on the device you are using. Systems with both a TrackPoint and a touchpad device will use either {{ic|/sys/devices/platform/i8042/serio1/serio2/}} or {{ic|/sys/devices/platform/i8042/serio1/serio3/}} for the path, whereas systems with only a TrackPoint device will use the {{ic|/sys/devices/platform/i8042/serio1/}} path.}}<br />
<br />
=== Configuration at boot ===<br />
<br />
==== udev rule ====<br />
<br />
This rule increases the trackpoint '''speed''' and enables '''tap to select''' (see above) on boot.<br />
<br />
{{hc|1=/etc/udev/rules.d/10-trackpoint.rules|2=<br />
ACTION=="add", SUBSYSTEM=="input", ATTR{name}=="TPPS/2 IBM TrackPoint", ATTR{device/sensitivity}="240", ATTR{device/press_to_select}="1"<br />
}}<br />
<br />
==== systemd.path unit ====<br />
<br />
There have been [https://bbs.archlinux.org/viewtopic.php?id=199998 reports on the forums] that the attributes/files under {{ic|/sys/devices/platform/i8042/serio1/serio2/}} appear too late in the boot process for the above (or similar) udev rule(s) to have an effect on them. Instead, a ''systemd.path'' unit can be used to configure attributes of the TrackPoint.<br />
<br />
First create an executable script named e.g. {{ic|/usr/local/bin/trackpoint_configuration.sh}} that sets the TrackPoint attributes as shown in the [[#Sysfs attributes]] section. Then create the following systemd units. Make sure that all attributes modified by the script are listed with {{ic|PathExists}}.<br />
<br />
{{hc|/etc/systemd/system/trackpoint_parameters.path|2=<br />
[Unit]<br />
Description=Watch for, and modify, Trackpoint attributes<br />
<br />
[Path]<br />
PathExists=/sys/devices/platform/i8042/serio1/press_to_select<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
{{hc|/etc/systemd/system/trackpoint_parameters.service|2=<br />
[Unit]<br />
Description=Set TrackPoint attributes<br />
<br />
[Service]<br />
ExecStart=/usr/local/bin/trackpoint_configuration.sh<br />
}}<br />
<br />
Finally, [[enable]] and [[start]] the {{ic|trackpoint_parameters.path}} systemd unit.<br />
<br />
==== udev hwdb entry ====<br />
<br />
{{Out of date|1=Since around [https://who-t.blogspot.com/2018/06/libinput-and-its-device-quirks-files.html version 1.12] libinput stopped using udev hwdb for device-specific overrides and moved to ini-style files independent of hwdb (see [[#device-quirks]]).}}<br />
<br />
Libinput applies its own parameters to sysfs based on entries in the [https://github.com/systemd/systemd/blob/master/hwdb/70-pointingstick.hwdb udev hardware database]. This is the behavior on systems running a Wayland compositor, as libinput is the only supported input interface in that environment. Changes made prior to the start of a Wayland compositor or X session will be overwritten.<br />
<br />
To override libinput's default settings, add a local hwdb entry:<br />
<br />
{{hc|/etc/udev/hwdb.d/99-trackpoint.hwdb|2=<br />
evdev:name:TPPS/2 IBM TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPad??60?:*<br />
POINTINGSTICK_SENSITIVITY=250<br />
}}<br />
<br />
You can find various vendor/model keys in the [https://github.com/systemd/systemd/blob/master/hwdb/70-pointingstick.hwdb udev hardware database]. Note that since [https://cgit.freedesktop.org/wayland/libinput/commit/src/evdev.c?id=3669fa10dff95371658647272ef7ac7a3ef29a61 this commit] libinput ignores the POINTINGSTICK_CONST_ACCEL parameter and uses POINTINGSTICK_SENSITIVITY. The range is 0-255.<br />
<br />
Reload udev's hwdb to apply the changes:<br />
<br />
# udevadm hwdb --update<br />
<br />
To test the changes prior to restarting your compositor or X session, first find your device input node {{ic|/dev/input/eventX}} using:<br />
<br />
# libinput list-devices<br />
<br />
Run the following to generate some debug output:<br />
<br />
# udevadm trigger /sys/class/input/eventX<br />
# udevadm test /sys/class/input/eventX<br />
<br />
{{Note|This will not actually apply the parameters from hwdb, but you can verify the changes in the output of the {{ic|udevadm test}} command.}}<br />
<br />
Finally, restart your Wayland compositor or X session to apply the changes.<br />
<br />
==== device-quirks ====<br />
<br />
With the {{ic|libinput}} switch to the new device-quirks {{ic|.ini}}-style configuration files, you can adjust trackpoint parameters via local overrides in {{ic|/etc/libinput/}}.<br />
<br />
For example, to override the pointing speed, create {{ic|/etc/libinput/local-overrides.quirks}}:<br />
[Trackpoint Override]<br />
MatchUdevType=pointingstick<br />
AttrTrackpointMultiplier=0.75<br />
<br />
For more information, see [https://wayland.freedesktop.org/libinput/doc/latest/device-quirks.html#installing-temporary-local-device-quirks libinput: Installing temporary local device quirks]<br />
<br />
{{Note|Model quirks are internal API and may change at any time. No backwards-compatibility is guaranteed. Local overrides should only be used until the distribution updates the libinput packages.}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Trackpoint is not detected or is detected after X minutes ===<br />
<br />
This appears to be a kernel bug. See: https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
A workaround is passing {{ic|1=proto=bare}} to the {{ic|psmouse}} module. However, this disables scrolling with the clickpad and the two-finger middle click:<br />
# modprobe psmouse proto=bare<br />
<br />
=== Trackpoint buttons do not always work ===<br />
<br />
If you discover that disabling the touchpad in the BIOS disables the wrong buttons and/or that the trackpoint buttons work very unreliable a workaround is to pass {{ic|1=proto=imps}} to the {{ic|psmouse}} module.<br />
# rmmod psmouse; modprobe psmouse proto=imps<br />
<br />
=== Two-finger scroll ceases to work after suspending ===<br />
<br />
On some laptops, psmouse seems to fail on start up, or after suspend:<br />
<br />
psmouse serio1: synaptics: Unable to initialize device<br />
<br />
One workaround is to use add `psmouse.synaptics_intertouch=0` to your kernel commandline.<br />
<br />
== See also ==<br />
<br />
* [http://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint How to configure the TrackPoint - ThinkWiki]<br />
* [https://gist.githubusercontent.com/noromanba/11261595/raw/478cf4c4d9b63f1e59364a6f427ffccd63db5e1e/thinkpad-trackpoint-speed.mkd Trackpoint speed]<br />
* [https://askubuntu.com/questions/37824/what-is-the-best-way-to-configure-a-thinkpads-trackpoint/553926 What is the best way to configure a Thinkpad's TrackPoint?]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Input_Leap&diff=491984Input Leap2017-09-30T22:01:29Z<p>Slowbro: Troubleshooting: Additional Mouse Buttons</p>
<hr />
<div>[[Category:Input devices]]<br />
[[fr:Synergy]]<br />
[[it:Synergy]]<br />
[[ja:Synergy]]<br />
[http://synergy-project.org/ Synergy] lets you easily share a single mouse and keyboard between multiple computers (even with different operating systems) without the need for special hardware. It is intended for users with multiple computers on their desk since each system uses its own monitor(s).<br />
<br />
Redirecting the mouse and keyboard is as simple as moving the mouse off the edge of your screen. Synergy also merges the clipboards of all the systems into one, allowing cut-and-paste between systems. Furthermore, it synchronizes screen savers so they all start and stop together and, if screen locking is enabled, only one screen requires a password to unlock them all. <br />
<br />
==Installation==<br />
<br />
===Arch Linux===<br />
You can [[install]] the {{pkg|synergy}} package.<br />
<br />
===Windows and macOS===<br />
[https://symless.com/synergy/ Download] and run the newest installer from the official website. The official version is paid, although you may compile and run your own builds for free using [https://github.com/symless/synergy-core sources on GitHub].<br />
<br />
==Pre-configuration==<br />
First determine the IP addresses and [[Network_configuration#Set_the_hostname|host names]] for each machine and make sure each has a correct hosts file.<br />
<br />
* Arch Linux - {{ic|/etc/hosts}}<br />
* Windows - {{ic|C:\WINDOWS\system32\drivers\etc\hosts}}<br />
* macOS - [http://support.apple.com/kb/TA27291 How to Add Hosts to Local Hosts File].<br />
<br />
{{hc|/etc/hosts|<br />
10.10.66.1 archserver.localdomain archserver<br />
10.10.66.100 archleft.localdomain archleft<br />
10.10.66.105 archright.localdomain archright}}<br />
<br />
{{Note|Check that the clients can reach the server.}}<br />
<br />
==Server configuration==<br />
In synergy, the computer with keyboard and mouse you want to share is called server.<br />
See [https://github.com/symless/synergy-core/wiki/Text-Config Synergy Configuration File Format] for a detailed description of all available sections and options.<br />
<br />
===Arch Linux===<br />
The configuration file for Arch Linux is {{ic|/etc/synergy.conf}}. If it does not exist, create it using {{ic|/etc/synergy.conf.example}}, whose comments should give you enough information for a basic configuration; if you need further reference, read the guide mentioned above.<br />
{{Tip|1=You may also use {{AUR|quicksynergy}} from the [[AUR]] which provide a GUI to simplify the configuration process.}}<br />
{{Tip|1=Make sure the server port is not blocked. By default, synergy uses port 24800.}}<br />
<br />
If you experience problems and you wish to run the server in the foreground, you can run the following command instead:<br />
# synergys -f<br />
<br />
The synergy server process needs to attach to your user's X session, which means it needs to run as your user. [[Enable]] {{ic|synergys.service}} with {{ic|--user}} option.<br />
{{Tip|1=You can enable {{ic|synergys.socket}} to start the server when a client tries to connect instead. This is useful when the service can't connect to an X server on boot.}}<br />
<br />
====Use encryption==== <br />
<br />
To generate a certificate and fingerprint for the server to use.<br />
$ mkdir -p ~/.synergy/SSL/Fingerprints<br />
$ openssl req -x509 -nodes -days 365 -subj /CN=Synergy -newkey rsa:1024 -keyout ~/.synergy/SSL/Synergy.pem -out ~/.synergy/SSL/Synergy.pem<br />
$ openssl x509 -fingerprint -sha1 -noout -in ~/.synergy/SSL/Synergy.pem > ~/.synergy/SSL/Fingerprints/Local.txt<br />
$ sed -e "s/.*=//" -i ~/.synergy/SSL/Fingerprints/Local.txt<br />
<br />
To activate the SSL plugin, add the {{ic|--enable-crypto}} option.<br />
<br />
* Starting from the command line:<br />
$ synergys --enable-crypto<br />
<br />
* Starting with systemd:<br />
$ systemctl --user start synergys<br />
<br />
===Windows===<br />
<br />
# Open the Synergy program<br />
# Select the option ''Server (share this computer's mouse and keyboard)''<br />
# Select ''Configure interactively''<br />
# Click the ''Configure Server...'' button<br />
# This opens a window in which you can add screens depending on how many computers/screens you have: just drag the screen icon in the top-right corner to the screens area, and double-click it to edit its settings<br />
# Click ''OK'' to close the screens window when you are ready, then click on ''Start'' to start the server<br />
<br />
On Windows, configuration is saved by default in a {{ic|synergy.sgc}} file, but its name and location can of course be changed at pleasure.<br />
<br />
If you want to start the Synergy server everytime Windows starts, you have to launch the program '''as administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Server'' section; note that at the following reboot Synergy will indeed automatically start, but the tray icon will not display automatically (at least for version 1.4.2 beta on Windows 7). To uninstall the service, do the same thing but obviously select ''Uninstall''.<br />
<br />
If you want to start the server from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}:<br />
<br />
C:\Program Files\Synergy+\bin\synergys.exe -f --debug ERROR --name left --log c:\windows\synergy.log -c C:/windows/synergy.sgc --address 10.66.66.2:24800<br />
<br />
===macOS===<br />
<br />
macOS has a similar configuration as Unix: check [https://github.com/symless/synergy-core/wiki/Developer the official documentation] for more information.<br />
<br />
===Configuration examples===<br />
<br />
This is an example for a basic 3-computers setup:<br />
<br />
{{hc|/etc/synergy.conf|<nowiki><br />
section: screens<br />
server-fire:<br />
archright-fire:<br />
archleft-fire:<br />
end<br />
<br />
section: links<br />
archleft-fire:<br />
right = server-fire<br />
server-fire:<br />
right = archright-fire<br />
left = archleft-fire<br />
archright-fire:<br />
left = server-fire<br />
end<br />
</nowiki>}}<br />
<br />
This should be the example bundled with the Arch Linux package:<br />
<br />
{{hc|/etc/synergy.conf|2=<br />
section: screens<br />
# three hosts named: moe, larry, and curly<br />
moe:<br />
larry:<br />
curly:<br />
end<br />
<br />
section: links<br />
# larry is to the right of moe and curly is above moe<br />
moe:<br />
right = larry<br />
up = curly<br />
<br />
# moe is to the left of larry and curly is above larry.<br />
# note that curly is above both moe and larry and moe<br />
# and larry have a symmetric connection (they're in<br />
# opposite directions of each other).<br />
larry:<br />
left = moe<br />
up = curly<br />
<br />
# larry is below curly. if you move up from moe and then<br />
# down, you'll end up on larry.<br />
curly:<br />
down = larry<br />
end<br />
<br />
section: aliases<br />
# curly is also known as shemp<br />
curly:<br />
shemp<br />
end<br />
<br />
}}<br />
<br />
The following is a more customized example:<br />
<br />
{{hc|synergy.sgc|2=<br />
section: screens<br />
leftpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
rightpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
leftpc:<br />
10.66.66.2<br />
rightpc:<br />
10.66.66.1<br />
end<br />
<br />
section: links<br />
leftpc:<br />
right = rightpc<br />
rightpc:<br />
left = leftpc<br />
end<br />
<br />
section: options<br />
heartbeat = 1000<br />
relativeMouseMoves = false<br />
screenSaverSync = false<br />
win32KeepForeground = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 4<br />
end<br />
}}<br />
<br />
==Clients configuration==<br />
<br />
{{Note|This assumes a server has been set up and configured '''properly'''. Make sure the server is already configured to accept the client(s) before continuing.}}<br />
{{Tip|You don't need to setup a client on the host server as the server includes one.}}<br />
<br />
===Arch Linux===<br />
In a console window, type:<br />
$ synergyc server-host-name<br />
<br />
Or, to run synergy in the foreground:<br />
$ synergyc -f server-host-name<br />
<br />
Here, {{ic|server-host-name}} is the host name of the server.<br />
<br />
====Use encryption==== <br />
<br />
<br />
If you use the synergy command line client, copy the file containing the fingerprint [[synergy|{{ic|~/.synergy/SSL/Fingerprints/Local.txt}}]] from the server into the clients home directory [[synergy|{{ic|~/.synergy/SSL/Fingerprints/TrustedServers.txt}}]]. To start the synergy command line client with encryption, type:<br />
$ synergyc --enable-crypto<br />
<br />
{{Note| There is an open issue with the GUI client of synergy (see https://github.com/symless/synergy-core/issues/4737). The dialog to prompt for confirmation of the server's fingerprint, only pops up if the logging level is set to INFO, DEBUG or DEBUG2.}}<br />
<br />
====Autostart====<br />
<br />
There exist several ways to automatically start the Synergy client, and they are actually the same that can be used for every other application.<br />
<br />
{{Note|In all of the following examples, you always have to substitute {{ic|server-host-name}} with the real server host name.}}<br />
<br />
* You can add the next line to your [[xinitrc|{{ic|~/.xinitrc}}]]:<br />
<br />
{{hc|~/.xinitrc|<br />
...<br />
<br />
#replace server-host-name with the real name<br />
synergyc server-host-name<br />
}}<br />
<br />
The following is an alternative:<br />
<br />
{{hc|~/.xinitrc|<br />
<nowiki>XINIT_CMD='/usr/bin/synergyc -d FATAL -n galileo-fire 10.66.66.2:24800'<br />
/usr/bin/pgrep -lxf "$XINIT_CMD" || ( ( $XINIT_CMD ) & )</nowiki><br />
}}<br />
<br />
* Otherwise, if you are using a [[display manager]] (kdm, gdm, [[SLiM]], ...), or a stand-alone [[window manager]] (Openbox, ...), you could exploit its start-up script and add the following:<br />
synergyc server-host-name<br />
<br />
For example, using ''kdm'' you should edit {{ic|/usr/share/config/kdm/Xsetup}}.<br />
<br />
* To start the Synergy client with systemd, create a service file:<br />
<br />
{{hc|~/.config/systemd/user/synergyc.service|2=<br />
[Unit]<br />
Description=Synergy Client Daemon<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/synergyc --no-daemon ''server-name''<br />
Restart=always<br />
RestartSec=3<br />
<br />
[Install]<br />
WantedBy=default.target}}<br />
<br />
To start the service for your user:<br />
<br />
# systemctl --user start synergyc<br />
<br />
To start the service at login for your user:<br />
<br />
# systemctl --user enable synergyc<br />
<br />
Automatically starting Synergy is also documented in its [https://github.com/symless/synergy-core/wiki/Startup official reference page].<br />
<br />
===Windows===<br />
<br />
After installation, open the Synergy program, select the option ''Client (use another computer's keyboard and mouse)'' and type the host name of the server computer in the text box, then click ''Start'' to start the client.<br />
{{Note|You can use the tray icon to stop the client.}}<br />
<br />
If you want to start the Synergy client every time Windows starts, you have to launch the program '''as an administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Client'' section.<br />
<br />
If you want to start the client from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}. This points to a configuration file in {{ic|C:\synergy.sgc}} and runs in the background like a service.<br />
<br />
{{bc|<nowiki>START /MIN /D"C:\Program Files\Synergy+\bin" synergys.exe -d ERROR -n m6300 -c C:\synergy.sgc -a 10.66.66.2:24800</nowiki>}}<br />
<br />
===macOS===<br />
<br />
Locate the synergyc program in the synergyc folder and drag it onto the terminal window: the full path will appear in the terminal.<br />
Now append the host name of the server, so that the complete command will look like this:<br />
<br />
{{bc|/path/to/synergyc/synergyc server-host-name}}<br />
<br />
Then press {{ic|Enter}}.<br />
<br />
==Known issues==<br />
If Arch is being used as a client in a Synergy installation, the server may not be able to wake the client monitor. There are some workarounds, such as executing the following via [[SSH]], if ACPI is enabled (see: [[Display Power Management Signaling#Modifying DPMS and screensaver settings using xset|Modifying DPMS and ScreenSaver settings with xset]]):<br />
{{bc|# xset dpms force on}}<br />
<br />
==Troubleshooting==<br />
The official documentation has a [https://github.com/symless/synergy-core/wiki/User-FAQ FAQ] and also a [https://github.com/symless/synergy-core/wiki/User-Guide#Troubleshooting troubleshooting page].<br />
<br />
===Keyboard AltGr===<br />
If you encounter problems with AltGr add <br />
<br />
altgr = alt #1.8.2<br />
altgr = shift #v1.8.3 and higher<br />
<br />
on the screen/client section in /etc/synergys.conf.<br />
<br />
===Keyboard repeat===<br />
If you experience problems with your keyboard repeat on the client machine (Linux host), simply type:<br />
{{bc|# /usr/bin/xset r on}}<br />
in any console.<br />
<br />
===Keyboard mapping===<br />
If you experience problems with the keyboard mapping when using the server's keyboard in a client window (e.g a terminal) then re-setting the X key map after starting synergyc may help. The following command sets the keymap to its current value:<br />
<br />
# setxkbmap $(setxkbmap -query | grep "^layout:" | awk -F ": *" '{print $2}')<br />
<br />
===No cursor in Gnome===<br />
When [[GNOME]] doesn't detect a mouse, it will default to touchscreen mode and hide the cursor. To enable run:<br />
<br />
# dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
This can be added to an init script or systemd unit:<br />
<br />
ExecStartPost=dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
===Client is returning "failed to verify server certificate fingerprint"===<br />
You need to copy the content of server's "~/.synergy/SSL/Fingerprints/Local.txt" into client's "~/.synergy/SSL/Fingerprints/TrustedServers.txt".<br />
<br />
===Scroll Lock LED does not light===<br />
When using Scroll Lock to lock to a client (or to enter relative mouse move mode), you may run into an issue with your keyboard's Scroll Lock LED not lighting. This can be solved by binding the {{ic|Scroll_Lock}} key to an empty modifier key.<br />
<br />
First, find an empty modifier. In this case, mod3 is available:<br />
$ xmodmap<br />
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):<br />
<br />
shift Shift_L (0x32), Shift_R (0x3e)<br />
lock Caps_Lock (0x42)<br />
control Control_L (0x25), Control_R (0x69)<br />
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)<br />
mod2 Num_Lock (0x4d)<br />
mod3<br />
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)<br />
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)<br />
<br />
Then, add the new mapping.<br />
$ xmodmap -e 'add mod3 = Scroll_Lock'<br />
$ "echo "add mod3 = Scroll_Lock" >> ~/.Xmodmap<br />
<br />
See [[Xmodmap#Activating_the_custom_table]] to have {{ic|~/.Xmodmap}} loaded on login.<br />
<br />
After making this change, test the LED and screen locking. If you find that you need to press Scroll Lock twice to lock screens, enable {{ic|halfDuplexScrollLock}} on all screens in {{ic|section: screens}}.<br />
<br />
===Additional mouse buttons do not work in client===<br />
If you find that additional mouse buttons (i.e. Mouse4/Mouse5) do not translate to a client, try adding the following to {{ic|section: options}}:<br />
<br />
mousebutton(6) = mousebutton(4)<br />
mousebutton(7) = mousebutton(5)<br />
<br />
This will re-map the mouse keys to the proper number. If that does not fix the problem, remove the configuration, stop Synergy, and start it in the foreground with debug logging enabled:<br />
<br />
$ synergys -f -d DEBUG1<br />
<br />
Then, move your cursor to the screen of the client with the issue. Click the non-functioning keys, and watch for log entries like this:<br />
<br />
[2017-09-30T14:56:45] DEBUG1: onMouseDown id=6<br />
...<br />
[2017-09-30T14:56:46] DEBUG1: onMouseUp id=6<br />
<br />
The {{ic|<nowiki>id=...</nowiki>}} part will have the right number to use in {{ic|mousebutton(...)}}<br />
<br />
==External links==<br />
* Synergy website: https://symless.com/synergy/<br />
* Official documentation: https://github.com/symless/synergy-core/wiki/User-Guide</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Input_Leap&diff=491977Input Leap2017-09-30T21:45:36Z<p>Slowbro: Troubleshooting: Scroll Lock LED</p>
<hr />
<div>[[Category:Input devices]]<br />
[[fr:Synergy]]<br />
[[it:Synergy]]<br />
[[ja:Synergy]]<br />
[http://synergy-project.org/ Synergy] lets you easily share a single mouse and keyboard between multiple computers (even with different operating systems) without the need for special hardware. It is intended for users with multiple computers on their desk since each system uses its own monitor(s).<br />
<br />
Redirecting the mouse and keyboard is as simple as moving the mouse off the edge of your screen. Synergy also merges the clipboards of all the systems into one, allowing cut-and-paste between systems. Furthermore, it synchronizes screen savers so they all start and stop together and, if screen locking is enabled, only one screen requires a password to unlock them all. <br />
<br />
==Installation==<br />
<br />
===Arch Linux===<br />
You can [[install]] the {{pkg|synergy}} package.<br />
<br />
===Windows and macOS===<br />
[https://symless.com/synergy/ Download] and run the newest installer from the official website. The official version is paid, although you may compile and run your own builds for free using [https://github.com/symless/synergy-core sources on GitHub].<br />
<br />
==Pre-configuration==<br />
First determine the IP addresses and [[Network_configuration#Set_the_hostname|host names]] for each machine and make sure each has a correct hosts file.<br />
<br />
* Arch Linux - {{ic|/etc/hosts}}<br />
* Windows - {{ic|C:\WINDOWS\system32\drivers\etc\hosts}}<br />
* macOS - [http://support.apple.com/kb/TA27291 How to Add Hosts to Local Hosts File].<br />
<br />
{{hc|/etc/hosts|<br />
10.10.66.1 archserver.localdomain archserver<br />
10.10.66.100 archleft.localdomain archleft<br />
10.10.66.105 archright.localdomain archright}}<br />
<br />
{{Note|Check that the clients can reach the server.}}<br />
<br />
==Server configuration==<br />
In synergy, the computer with keyboard and mouse you want to share is called server.<br />
See [https://github.com/symless/synergy-core/wiki/Text-Config Synergy Configuration File Format] for a detailed description of all available sections and options.<br />
<br />
===Arch Linux===<br />
The configuration file for Arch Linux is {{ic|/etc/synergy.conf}}. If it does not exist, create it using {{ic|/etc/synergy.conf.example}}, whose comments should give you enough information for a basic configuration; if you need further reference, read the guide mentioned above.<br />
{{Tip|1=You may also use {{AUR|quicksynergy}} from the [[AUR]] which provide a GUI to simplify the configuration process.}}<br />
{{Tip|1=Make sure the server port is not blocked. By default, synergy uses port 24800.}}<br />
<br />
If you experience problems and you wish to run the server in the foreground, you can run the following command instead:<br />
# synergys -f<br />
<br />
The synergy server process needs to attach to your user's X session, which means it needs to run as your user. [[Enable]] {{ic|synergys.service}} with {{ic|--user}} option.<br />
{{Tip|1=You can enable {{ic|synergys.socket}} to start the server when a client tries to connect instead. This is useful when the service can't connect to an X server on boot.}}<br />
<br />
====Use encryption==== <br />
<br />
To generate a certificate and fingerprint for the server to use.<br />
$ mkdir -p ~/.synergy/SSL/Fingerprints<br />
$ openssl req -x509 -nodes -days 365 -subj /CN=Synergy -newkey rsa:1024 -keyout ~/.synergy/SSL/Synergy.pem -out ~/.synergy/SSL/Synergy.pem<br />
$ openssl x509 -fingerprint -sha1 -noout -in ~/.synergy/SSL/Synergy.pem > ~/.synergy/SSL/Fingerprints/Local.txt<br />
$ sed -e "s/.*=//" -i ~/.synergy/SSL/Fingerprints/Local.txt<br />
<br />
To activate the SSL plugin, add the {{ic|--enable-crypto}} option.<br />
<br />
* Starting from the command line:<br />
$ synergys --enable-crypto<br />
<br />
* Starting with systemd:<br />
$ systemctl --user start synergys<br />
<br />
===Windows===<br />
<br />
# Open the Synergy program<br />
# Select the option ''Server (share this computer's mouse and keyboard)''<br />
# Select ''Configure interactively''<br />
# Click the ''Configure Server...'' button<br />
# This opens a window in which you can add screens depending on how many computers/screens you have: just drag the screen icon in the top-right corner to the screens area, and double-click it to edit its settings<br />
# Click ''OK'' to close the screens window when you are ready, then click on ''Start'' to start the server<br />
<br />
On Windows, configuration is saved by default in a {{ic|synergy.sgc}} file, but its name and location can of course be changed at pleasure.<br />
<br />
If you want to start the Synergy server everytime Windows starts, you have to launch the program '''as administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Server'' section; note that at the following reboot Synergy will indeed automatically start, but the tray icon will not display automatically (at least for version 1.4.2 beta on Windows 7). To uninstall the service, do the same thing but obviously select ''Uninstall''.<br />
<br />
If you want to start the server from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}:<br />
<br />
C:\Program Files\Synergy+\bin\synergys.exe -f --debug ERROR --name left --log c:\windows\synergy.log -c C:/windows/synergy.sgc --address 10.66.66.2:24800<br />
<br />
===macOS===<br />
<br />
macOS has a similar configuration as Unix: check [https://github.com/symless/synergy-core/wiki/Developer the official documentation] for more information.<br />
<br />
===Configuration examples===<br />
<br />
This is an example for a basic 3-computers setup:<br />
<br />
{{hc|/etc/synergy.conf|<nowiki><br />
section: screens<br />
server-fire:<br />
archright-fire:<br />
archleft-fire:<br />
end<br />
<br />
section: links<br />
archleft-fire:<br />
right = server-fire<br />
server-fire:<br />
right = archright-fire<br />
left = archleft-fire<br />
archright-fire:<br />
left = server-fire<br />
end<br />
</nowiki>}}<br />
<br />
This should be the example bundled with the Arch Linux package:<br />
<br />
{{hc|/etc/synergy.conf|2=<br />
section: screens<br />
# three hosts named: moe, larry, and curly<br />
moe:<br />
larry:<br />
curly:<br />
end<br />
<br />
section: links<br />
# larry is to the right of moe and curly is above moe<br />
moe:<br />
right = larry<br />
up = curly<br />
<br />
# moe is to the left of larry and curly is above larry.<br />
# note that curly is above both moe and larry and moe<br />
# and larry have a symmetric connection (they're in<br />
# opposite directions of each other).<br />
larry:<br />
left = moe<br />
up = curly<br />
<br />
# larry is below curly. if you move up from moe and then<br />
# down, you'll end up on larry.<br />
curly:<br />
down = larry<br />
end<br />
<br />
section: aliases<br />
# curly is also known as shemp<br />
curly:<br />
shemp<br />
end<br />
<br />
}}<br />
<br />
The following is a more customized example:<br />
<br />
{{hc|synergy.sgc|2=<br />
section: screens<br />
leftpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
rightpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
leftpc:<br />
10.66.66.2<br />
rightpc:<br />
10.66.66.1<br />
end<br />
<br />
section: links<br />
leftpc:<br />
right = rightpc<br />
rightpc:<br />
left = leftpc<br />
end<br />
<br />
section: options<br />
heartbeat = 1000<br />
relativeMouseMoves = false<br />
screenSaverSync = false<br />
win32KeepForeground = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 4<br />
end<br />
}}<br />
<br />
==Clients configuration==<br />
<br />
{{Note|This assumes a server has been set up and configured '''properly'''. Make sure the server is already configured to accept the client(s) before continuing.}}<br />
{{Tip|You don't need to setup a client on the host server as the server includes one.}}<br />
<br />
===Arch Linux===<br />
In a console window, type:<br />
$ synergyc server-host-name<br />
<br />
Or, to run synergy in the foreground:<br />
$ synergyc -f server-host-name<br />
<br />
Here, {{ic|server-host-name}} is the host name of the server.<br />
<br />
====Use encryption==== <br />
<br />
<br />
If you use the synergy command line client, copy the file containing the fingerprint [[synergy|{{ic|~/.synergy/SSL/Fingerprints/Local.txt}}]] from the server into the clients home directory [[synergy|{{ic|~/.synergy/SSL/Fingerprints/TrustedServers.txt}}]]. To start the synergy command line client with encryption, type:<br />
$ synergyc --enable-crypto<br />
<br />
{{Note| There is an open issue with the GUI client of synergy (see https://github.com/symless/synergy-core/issues/4737). The dialog to prompt for confirmation of the server's fingerprint, only pops up if the logging level is set to INFO, DEBUG or DEBUG2.}}<br />
<br />
====Autostart====<br />
<br />
There exist several ways to automatically start the Synergy client, and they are actually the same that can be used for every other application.<br />
<br />
{{Note|In all of the following examples, you always have to substitute {{ic|server-host-name}} with the real server host name.}}<br />
<br />
* You can add the next line to your [[xinitrc|{{ic|~/.xinitrc}}]]:<br />
<br />
{{hc|~/.xinitrc|<br />
...<br />
<br />
#replace server-host-name with the real name<br />
synergyc server-host-name<br />
}}<br />
<br />
The following is an alternative:<br />
<br />
{{hc|~/.xinitrc|<br />
<nowiki>XINIT_CMD='/usr/bin/synergyc -d FATAL -n galileo-fire 10.66.66.2:24800'<br />
/usr/bin/pgrep -lxf "$XINIT_CMD" || ( ( $XINIT_CMD ) & )</nowiki><br />
}}<br />
<br />
* Otherwise, if you are using a [[display manager]] (kdm, gdm, [[SLiM]], ...), or a stand-alone [[window manager]] (Openbox, ...), you could exploit its start-up script and add the following:<br />
synergyc server-host-name<br />
<br />
For example, using ''kdm'' you should edit {{ic|/usr/share/config/kdm/Xsetup}}.<br />
<br />
* To start the Synergy client with systemd, create a service file:<br />
<br />
{{hc|~/.config/systemd/user/synergyc.service|2=<br />
[Unit]<br />
Description=Synergy Client Daemon<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/synergyc --no-daemon ''server-name''<br />
Restart=always<br />
RestartSec=3<br />
<br />
[Install]<br />
WantedBy=default.target}}<br />
<br />
To start the service for your user:<br />
<br />
# systemctl --user start synergyc<br />
<br />
To start the service at login for your user:<br />
<br />
# systemctl --user enable synergyc<br />
<br />
Automatically starting Synergy is also documented in its [https://github.com/symless/synergy-core/wiki/Startup official reference page].<br />
<br />
===Windows===<br />
<br />
After installation, open the Synergy program, select the option ''Client (use another computer's keyboard and mouse)'' and type the host name of the server computer in the text box, then click ''Start'' to start the client.<br />
{{Note|You can use the tray icon to stop the client.}}<br />
<br />
If you want to start the Synergy client every time Windows starts, you have to launch the program '''as an administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Client'' section.<br />
<br />
If you want to start the client from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}. This points to a configuration file in {{ic|C:\synergy.sgc}} and runs in the background like a service.<br />
<br />
{{bc|<nowiki>START /MIN /D"C:\Program Files\Synergy+\bin" synergys.exe -d ERROR -n m6300 -c C:\synergy.sgc -a 10.66.66.2:24800</nowiki>}}<br />
<br />
===macOS===<br />
<br />
Locate the synergyc program in the synergyc folder and drag it onto the terminal window: the full path will appear in the terminal.<br />
Now append the host name of the server, so that the complete command will look like this:<br />
<br />
{{bc|/path/to/synergyc/synergyc server-host-name}}<br />
<br />
Then press {{ic|Enter}}.<br />
<br />
==Known issues==<br />
If Arch is being used as a client in a Synergy installation, the server may not be able to wake the client monitor. There are some workarounds, such as executing the following via [[SSH]], if ACPI is enabled (see: [[Display Power Management Signaling#Modifying DPMS and screensaver settings using xset|Modifying DPMS and ScreenSaver settings with xset]]):<br />
{{bc|# xset dpms force on}}<br />
<br />
==Troubleshooting==<br />
The official documentation has a [https://github.com/symless/synergy-core/wiki/User-FAQ FAQ] and also a [https://github.com/symless/synergy-core/wiki/User-Guide#Troubleshooting troubleshooting page].<br />
<br />
===Keyboard AltGr===<br />
If you encounter problems with AltGr add <br />
<br />
altgr = alt #1.8.2<br />
altgr = shift #v1.8.3 and higher<br />
<br />
on the screen/client section in /etc/synergys.conf.<br />
<br />
===Keyboard repeat===<br />
If you experience problems with your keyboard repeat on the client machine (Linux host), simply type:<br />
{{bc|# /usr/bin/xset r on}}<br />
in any console.<br />
<br />
===Keyboard mapping===<br />
If you experience problems with the keyboard mapping when using the server's keyboard in a client window (e.g a terminal) then re-setting the X key map after starting synergyc may help. The following command sets the keymap to its current value:<br />
<br />
# setxkbmap $(setxkbmap -query | grep "^layout:" | awk -F ": *" '{print $2}')<br />
<br />
===No cursor in Gnome===<br />
When [[GNOME]] doesn't detect a mouse, it will default to touchscreen mode and hide the cursor. To enable run:<br />
<br />
# dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
This can be added to an init script or systemd unit:<br />
<br />
ExecStartPost=dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
===Client is returning "failed to verify server certificate fingerprint"===<br />
You need to copy the content of server's "~/.synergy/SSL/Fingerprints/Local.txt" into client's "~/.synergy/SSL/Fingerprints/TrustedServers.txt".<br />
<br />
===Scroll Lock LED does not light===<br />
When using Scroll Lock to lock to a client (or to enter relative mouse move mode), you may run into an issue with your keyboard's Scroll Lock LED not lighting. This can be solved by binding the {{ic|Scroll_Lock}} key to an empty modifier key.<br />
<br />
First, find an empty modifier. In this case, mod3 is available:<br />
$ xmodmap<br />
xmodmap: up to 4 keys per modifier, (keycodes in parentheses):<br />
<br />
shift Shift_L (0x32), Shift_R (0x3e)<br />
lock Caps_Lock (0x42)<br />
control Control_L (0x25), Control_R (0x69)<br />
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)<br />
mod2 Num_Lock (0x4d)<br />
mod3<br />
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)<br />
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)<br />
<br />
Then, add the new mapping.<br />
$ xmodmap -e 'add mod3 = Scroll_Lock'<br />
$ "echo "add mod3 = Scroll_Lock" >> ~/.Xmodmap<br />
<br />
See [[Xmodmap#Activating_the_custom_table]] to have {{ic|~/.Xmodmap}} loaded on login.<br />
<br />
After making this change, test the LED and screen locking. If you find that you need to press Scroll Lock twice to lock screens, enable {{ic|halfDuplexScrollLock}} on all screens in {{ic|section: screens}}.<br />
<br />
==External links==<br />
* Synergy website: https://symless.com/synergy/<br />
* Official documentation: https://github.com/symless/synergy-core/wiki/User-Guide</div>Slowbrohttps://wiki.archlinux.org/index.php?title=NVIDIA&diff=491432NVIDIA2017-09-26T15:43:26Z<p>Slowbro: easier to copy/paste this way. also, this section really should be tidied up but i'm not sure how..</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-hans:NVIDIA]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA/Tips and tricks}}<br />
{{Related|NVIDIA/Troubleshooting}}<br />
{{Related|Nouveau}}<br />
{{Related|Bumblebee}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This article covers the proprietary [http://www.nvidia.com NVIDIA] graphics card driver. For the open-source driver, see [[Nouveau]]. If you have a laptop with hybrid Intel/NVIDIA graphics, see [[NVIDIA Optimus]] instead.<br />
<br />
== Installation ==<br />
<br />
{{Warning|Avoid installing the NVIDIA driver through the package provided from the NVIDIA website. Installation through [[pacman]] allows upgrading the driver together with the rest of the system.}}<br />
<br />
These instructions are for those using the stock {{Pkg|linux}} or {{Pkg|linux-lts}} packages. For custom kernel setup, skip to the [[#Custom kernel|next]] subsection.<br />
<br />
1. If you do not know what graphics card you have, find out by issuing:<br />
:{{bc|<nowiki>$ lspci -k | grep -A 2 -E "(VGA|3D)"</nowiki>}}<br />
<br />
2. Determine the necessary driver version for your card by:<br />
:* finding the code name (e.g. NV50, NVC0, etc.) on [https://nouveau.freedesktop.org/wiki/CodeNames/ Nouveau wiki's code names page]<br />
:* looking up the name in NVIDIA's [http://www.nvidia.com/object/IO_32667.html legacy card list]: if your card is not there you can use the latest driver<br />
:* visiting NVIDIA's [http://www.nvidia.com/Download/index.aspx driver download site]<br />
<br />
3. Install the appropriate driver for your card:<br />
:* For GeForce 400 series cards and newer [NVCx and newer], [[install]] the {{Pkg|nvidia}}, {{Pkg|nvidia-dkms}} (for [[DKMS]] support) or {{Pkg|nvidia-lts}} package (both based on Nvidia's short lived branch). If these packages do not work, {{AUR|nvidia-beta}} may have a newer driver version that offers support. There is also {{AUR|nvidia-llb-dkms}}, which is built from Nvidia's [http://www.phoronix.com/scan.php?page=news_item&px=OTkxOA long lived branch].<br />
:* For GeForce 8000/9000, ION and 100-300 series cards [NV5x, NV8x, NV9x and NVAx] from around 2006-2010, [[install]] the {{Pkg|nvidia-340xx}} or {{Pkg|nvidia-340xx-lts}} package.<br />
:* For GeForce 6000/7000 series cards [NV4x and NV6x] from around 2004-2006, [[install]] the {{Pkg|nvidia-304xx}} or {{Pkg|nvidia-304xx-lts}} package.<br />
<br />
:* For even older cards, have a look at [[#Unsupported drivers]].<br />
<br />
4. For 32-bit application support on x86_64, you must also install the equivalent ''lib32'' package from the [[multilib]] repository (e.g. {{Pkg|lib32-nvidia-utils}}, {{Pkg|lib32-nvidia-340xx-utils}} or {{Pkg|lib32-nvidia-304xx-utils}}).<br />
<br />
5. Reboot. The {{Pkg|nvidia}} package contains a file which blacklists the ''nouveau'' module, so rebooting is necessary.<br />
<br />
Once the driver has been installed, continue to [[#Configuration]].<br />
<br />
=== Unsupported drivers ===<br />
<br />
If you have a GeForce 5 FX series card or older, Nvidia no longer supports drivers for your card. This means that these drivers [http://nvidia.custhelp.com/app/answers/detail/a_id/3142/ do not support the current Xorg version]. It thus might be easier if you use the [[Nouveau]] driver, which supports the old cards with the current Xorg.<br />
<br />
However, Nvidia's legacy drivers are still available and might provide better 3D performance/stability if you are willing to downgrade [[Xorg]]:<br />
<br />
* For GeForce 5 FX series cards [NV30-NV36], install the {{AUR|nvidia-173xx-dkms}} package. Last supported Xorg version is 1.15.<br />
* For GeForce 2/3/4 MX/Ti series cards [NV11, NV17-NV28], install the {{AUR|nvidia-96xx-dkms}} package. Last supported Xorg version is 1.12.<br />
<br />
{{Tip|The legacy nvidia-96xx-dkms and nvidia-173xx-dkms drivers can also be installed from the unofficial [http://pkgbuild.com/~bgyorgy/city.html <nowiki>[city] repository</nowiki>]. (It is strongly advised that you do not skip any dependencies restriction when installing from here)}}<br />
<br />
=== Custom kernel ===<br />
<br />
If you are using a custom kernel, compilation of the Nvidia kernel modules can be automated with [[DKMS]].<br />
<br />
Install the {{Pkg|nvidia-dkms}} package (or a specific branch such as {{Pkg|nvidia-340xx-dkms}}). The Nvidia module will be rebuilt after every Nvidia or kernel update thanks to the DKMS [[Pacman#Hooks|Pacman Hook]].<br />
<br />
=== Pure Video HD ===<br />
<br />
At least a video card with second generation [[wikipedia:Nvidia PureVideo#Table of GPUs containing a PureVideo SIP block|PureVideo HD]] is required for [[hardware video acceleration]] using VDPAU.<br />
<br />
=== DRM kernel mode setting ===<br />
<br />
{{Warning|Enabling KMS causes [[GDM]] and [[GNOME]] to default to [[Wayland]], which currently suffers from very poor performance: {{bug|53284}}. A workaround is to use the ''GNOME on Xorg'' session instead.}}<br />
<br />
{{Note|1=The NVIDIA driver does '''not''' provide an {{ic|fbdev}} driver for the high-resolution console for the kernel compiled-in {{ic|vesafb}} module. However, the kernel compiled-in {{ic|efifb}} module supports a high-resolution console on EFI systems. This method requires GRUB and is described in [[NVIDIA/Tips and tricks#Fixing terminal resolution]].[http://forums.fedoraforum.org/showthread.php?t=306271][https://www.reddit.com/r/archlinux/comments/4gwukx/nvidia_drivers_and_high_resolution_tty_possible/].}}<br />
<br />
{{Pkg|nvidia}} 364.16 adds support for DRM [[kernel mode setting]]. To enable this feature, add the {{ic|1=nvidia-drm.modeset=1}} [[kernel parameter]], and add {{ic|nvidia nvidia_modeset nvidia_uvm nvidia_drm}} to your [[initramfs#MODULES]].<br />
<br />
{{Warning|Do not forget to run [[mkinitcpio]] every time there is a {{Pkg|nvidia}} driver update. See [[#Pacman hook]] to automate these steps.}}<br />
<br />
=== Hardware accelerated video decoding with XvMC ===<br />
<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. See [[XvMC]] for details.<br />
<br />
==== Pacman hook ====<br />
<br />
To avoid the possibility of forgetting to update [[initramfs]] after an NVIDIA driver upgrade, you may want to use a [[Pacman#Hooks|pacman hook]]:<br />
<br />
{{hc|/etc/pacman.d/hooks/nvidia.hook|2=[Trigger]<br />
Operation=Install<br />
Operation=Upgrade<br />
Operation=Remove<br />
Type=Package<br />
Target=nvidia<br />
<br />
[Action]<br />
Depends=mkinitcpio<br />
When=PostTransaction<br />
Exec=/usr/bin/mkinitcpio -P}}<br />
<br />
Make sure the {{ic|Target}} package set in this hook is the one you've installed in steps above (e.g. {{ic|nvidia}}, {{ic|nvidia-dkms}}, {{ic|nvidia-lts}} or {{ic|nvidia-ck-something}}).<br />
<br />
== Configuration ==<br />
<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 configuration file (prefer {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} over {{ic|/etc/X11/xorg.conf}}) 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 />
<br />
{{Tip|For more configuration options see [[NVIDIA/Tips and tricks#Manual configuration]] and [[NVIDIA/Troubleshooting]] section.}}<br />
<br />
=== Minimal configuration ===<br />
<br />
A basic configuration block in {{ic|20-nvidia.conf}} (or deprecated in {{ic|xorg.conf}}) would look like this:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-nvidia.conf|<br />
Section "Device"<br />
Identifier "Nvidia Card"<br />
Driver "nvidia"<br />
VendorName "NVIDIA Corporation"<br />
BoardName "GeForce GTX 1050 Ti"<br />
EndSection<br />
}}<br />
<br />
=== Automatic configuration ===<br />
<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 />
=== NVIDIA Settings ===<br />
<br />
The {{Pkg|nvidia-settings}} tool lets you configure many options using either CLI or GUI. Running {{ic|nvidia-settings}} without any options launches the GUI, for CLI options see {{ic|nvidia-settings(1)}}.<br />
<br />
You can run the GUI as a normal user and save the settings to {{ic|~/.nvidia-settings-rc}}. Then you can load the settings using {{ic|$ nvidia-settings --load-config-only}} (for example in your [[xinitrc]]). Alternatively, you can move the settings file to {{ic|/etc/X11/xorg.conf.d/20-nvidia.conf}} where they will be loaded automatically.<br />
<br />
{{Tip|If your X server is crashing on startup, it may be because the GUI-generated settings are corrupt. Try deleting the generated file and starting from scratch.}}<br />
<br />
=== Multiple monitors ===<br />
<br />
See [[Multihead]] for more general information.<br />
<br />
==== Using NVIDIA Settings ====<br />
<br />
The [[#NVIDIA Settings|nvidia-settings]] tool can configure multiple monitors.<br />
<br />
For CLI configuration, first get the {{ic|CurrentMetaMode}} by running:<br />
<br />
{{hc|$ nvidia-settings -q CurrentMetaMode|2=<br />
Attribute 'CurrentMetaMode' (hostnmae:0.0): id=50, switchable=no, source=nv-control :: DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0}<br />
}}<br />
<br />
Save everything after the {{ic|::}} to the end of the attribute (in this case: {{ic|1=DPY-1: 2880x1620 @2880x1620 +0+0 {ViewPortIn=2880x1620, ViewPortOut=2880x1620+0+0&#125;}}) and use to reconfigure your displays with {{ic|1=nvidia-settings --assign "CurrentMetaMode=''your_meta_mode''"}}.<br />
<br />
{{Tip|You can create shell aliases for the different monitor and resolution configurations you use.}}<br />
<br />
==== ConnectedMonitor ====<br />
<br />
If the driver does not 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 />
==== TwinView ====<br />
<br />
You want only one big screen instead of two. Set the {{ic|TwinView}} argument to {{ic|1}}. This option should be used if you desire compositing. TwinView only works on a per card basis, when all participating monitors are connected to the same card.<br />
Option "TwinView" "1"<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 />
[ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/configtwinview.html Device option information].<br />
<br />
If you have multiple cards that are SLI capable, it is possible to run more than one monitor attached to separate cards (for example: two cards in SLI with one monitor attached to each). The "MetaModes" option in conjunction with SLI Mosaic mode enables this. Below is a configuration which works for the aforementioned example and runs [[GNOME]] flawlessly.<br />
{{hc|/etc/X11/xorg.conf.d/10-monitor.conf|<br />
Section "Device"<br />
Identifier "Card A"<br />
Driver "nvidia"<br />
BusID "PCI:1:00:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card B"<br />
Driver "nvidia"<br />
BusID "PCI:2:00:0"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Right Monitor"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Left Monitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Right Screen"<br />
Device "Card A"<br />
Monitor "Right Monitor"<br />
DefaultDepth 24<br />
Option "SLI" "Mosaic"<br />
Option "Stereo" "0"<br />
Option "BaseMosaic" "True"<br />
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Left Screen"<br />
Device "Card B"<br />
Monitor "Left Monitor"<br />
DefaultDepth 24<br />
Option "SLI" "Mosaic"<br />
Option "Stereo" "0"<br />
Option "BaseMosaic" "True"<br />
Option "MetaModes" "GPU-0.DFP-0: 1920x1200+4480+0, GPU-1.DFP-0:1920x1200+0+0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "Default"<br />
Screen 0 "Right Screen" 0 0<br />
Option "Xinerama" "0"<br />
EndSection}}<br />
<br />
===== Manual CLI configuration with xrandr =====<br />
{{Accuracy|Do these commands set up the monitors in ''TwinView'' mode?}}<br />
<br />
If the latest solutions do not work for you, you can use your window manager's ''autostart'' implementation with {{Pkg|xorg-xrandr}}.<br />
<br />
Some {{ic|xrandr}} examples could be:<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 the "monitor" to which the options are set.<br />
* {{ic|DVI-I-1}} is the name of the second monitor.<br />
* {{ic|--pos}} is the position of the second monitor relative to the first.<br />
* {{ic|--mode}} is the resolution of the second monitor.<br />
* {{ic|--rate}} is the refresh rate (in Hz).<br />
<br />
===== Vertical sync using TwinView =====<br />
<br />
If you are using TwinView and vertical sync (the "Sync to VBlank" option in '''nvidia-settings'''), you will notice that only one screen is being properly synced, unless you have two identical monitors. Although '''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, for example append in {{ic|/etc/profile}}:<br />
<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 />
<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). You can find the identifier for your display from '''nvidia-settings''' in the "X Server XVideoSettings" section.<br />
<br />
===== Gaming using TwinView =====<br />
<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 appropriate 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 />
==== Mosaic mode ====<br />
<br />
Mosaic mode is the only way to use more than 2 monitors across multiple graphics cards with compositing. Your window manager may or may not recognize the distinction between each monitor.<br />
<br />
===== Base Mosaic =====<br />
<br />
Base Mosaic mode works on any set of Geforce 8000 series or higher GPUs. It cannot be enabled from within the nvidia-setting GUI. You must either use the {{ic|nvidia-xconfig}} command line program or edit {{ic|xorg.conf}} by hand. Metamodes must be specified. The following is an example for four DFPs in a 2x2 configuration, each running at 1920x1024, with two DFPs connected to two cards:<br />
$ nvidia-xconfig --base-mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"<br />
<br />
{{Note|While the documentation lists a 2x2 configuration of monitors, [https://devtalk.nvidia.com/default/topic/579449/linux/basemosaic-v295-vs-v310-vs-v325-only-up-to-three-screens-/post/3954733/#3954733 GeForce cards are artificially limited to 3 monitors] in Base Mosaic mode. Quadro cards support more than 3 monitors. As of September 2014, the Windows driver has dropped this artificial restriction, but it remains in the Linux driver.}}<br />
<br />
===== SLI Mosaic =====<br />
<br />
If you have an SLI configuration and each GPU is a Quadro FX 5800, Quadro Fermi or newer then you can use SLI Mosaic mode. It can be enabled from within the nvidia-settings GUI or from the command line with:<br />
$ nvidia-xconfig --sli=Mosaic --metamodes="GPU-0.DFP-0: 1920x1024+0+0, GPU-0.DFP-1: 1920x1024+1920+0, GPU-1.DFP-0: 1920x1024+0+1024, GPU-1.DFP-1: 1920x1024+1920+1024"<br />
<br />
=== Driver persistence ===<br />
<br />
Nvidia has a daemon that is to be run at boot. See the [http://docs.nvidia.com/deploy/driver-persistence/index.html Driver Persistence] section of the Nvidia documentation for more details.<br />
<br />
To start the persistence daemon at boot, [[enable]] the {{ic|nvidia-persistenced.service}}. For manual usage see the [http://docs.nvidia.com/deploy/driver-persistence/index.html#usage upstream documentation].<br />
<br />
== See also ==<br />
<br />
* [https://forums.geforce.com/ NVIDIA User forums]<br />
* [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/README.txt Official README for NVIDIA drivers, all on one text page. Most Recent Driver Version as of September 7, 2015: 355.11.]<br />
* [ftp://download.nvidia.com/XFree86/Linux-x86/355.11/README/xconfigoptions.html README Appendix B. X Config Options, 355.11 (direct link)]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Input_Leap&diff=491113Input Leap2017-09-23T22:05:56Z<p>Slowbro: the symless/synergy repo was renamed to symless/synergy-core</p>
<hr />
<div>[[Category:Input devices]]<br />
[[fr:Synergy]]<br />
[[it:Synergy]]<br />
[[ja:Synergy]]<br />
[http://synergy-project.org/ Synergy] lets you easily share a single mouse and keyboard between multiple computers (even with different operating systems) without the need for special hardware. It is intended for users with multiple computers on their desk since each system uses its own monitor(s).<br />
<br />
Redirecting the mouse and keyboard is as simple as moving the mouse off the edge of your screen. Synergy also merges the clipboards of all the systems into one, allowing cut-and-paste between systems. Furthermore, it synchronizes screen savers so they all start and stop together and, if screen locking is enabled, only one screen requires a password to unlock them all. <br />
<br />
==Installation==<br />
<br />
===Arch Linux===<br />
You can [[install]] the {{pkg|synergy}} package.<br />
<br />
===Windows and macOS===<br />
[https://symless.com/synergy/ Download] and run the newest installer from the official website. The official version is paid, although you may compile and run your own builds for free using [https://github.com/symless/synergy-core sources on GitHub].<br />
<br />
==Pre-configuration==<br />
First determine the IP addresses and [[Network_configuration#Set_the_hostname|host names]] for each machine and make sure each has a correct hosts file.<br />
<br />
* Arch Linux - {{ic|/etc/hosts}}<br />
* Windows - {{ic|C:\WINDOWS\system32\drivers\etc\hosts}}<br />
* macOS - [http://support.apple.com/kb/TA27291 How to Add Hosts to Local Hosts File].<br />
<br />
{{hc|/etc/hosts|<br />
10.10.66.1 archserver.localdomain archserver<br />
10.10.66.100 archleft.localdomain archleft<br />
10.10.66.105 archright.localdomain archright}}<br />
<br />
{{Note|Check that the clients can reach the server.}}<br />
<br />
==Server configuration==<br />
In synergy, the computer with keyboard and mouse you want to share is called server.<br />
See [https://github.com/symless/synergy-core/wiki/Text-Config Synergy Configuration File Format] for a detailed description of all available sections and options.<br />
<br />
===Arch Linux===<br />
The configuration file for Arch Linux is {{ic|/etc/synergy.conf}}. If it does not exist, create it using {{ic|/etc/synergy.conf.example}}, whose comments should give you enough information for a basic configuration; if you need further reference, read the guide mentioned above.<br />
{{Tip|1=You may also use {{AUR|quicksynergy}} from the [[AUR]] which provide a GUI to simplify the configuration process.}}<br />
{{Tip|1=Make sure the server port is not blocked. By default, synergy uses port 24800.}}<br />
<br />
If you experience problems and you wish to run the server in the foreground, you can run the following command instead:<br />
# synergys -f<br />
<br />
The synergy server process needs to attach to your user's X session, which means it needs to run as your user. [[Enable]] {{ic|synergys.service}} with {{ic|--user}} option.<br />
{{Tip|1=You can enable {{ic|synergys.socket}} to start the server when a client tries to connect instead. This is useful when the service can't connect to an X server on boot.}}<br />
<br />
====Use encryption==== <br />
<br />
To generate a certificate and fingerprint for the server to use.<br />
$ mkdir -p ~/.synergy/SSL/Fingerprints<br />
$ openssl req -x509 -nodes -days 365 -subj /CN=Synergy -newkey rsa:1024 -keyout ~/.synergy/SSL/Synergy.pem -out ~/.synergy/SSL/Synergy.pem<br />
$ openssl x509 -fingerprint -sha1 -noout -in ~/.synergy/SSL/Synergy.pem > ~/.synergy/SSL/Fingerprints/Local.txt<br />
$ sed -e "s/.*=//" -i ~/.synergy/SSL/Fingerprints/Local.txt<br />
<br />
To activate the SSL plugin, add the {{ic|--enable-crypto}} option.<br />
<br />
* Starting from the command line:<br />
$ synergys --enable-crypto<br />
<br />
* Starting with systemd:<br />
$ systemctl --user start synergys<br />
<br />
===Windows===<br />
<br />
# Open the Synergy program<br />
# Select the option ''Server (share this computer's mouse and keyboard)''<br />
# Select ''Configure interactively''<br />
# Click the ''Configure Server...'' button<br />
# This opens a window in which you can add screens depending on how many computers/screens you have: just drag the screen icon in the top-right corner to the screens area, and double-click it to edit its settings<br />
# Click ''OK'' to close the screens window when you are ready, then click on ''Start'' to start the server<br />
<br />
On Windows, configuration is saved by default in a {{ic|synergy.sgc}} file, but its name and location can of course be changed at pleasure.<br />
<br />
If you want to start the Synergy server everytime Windows starts, you have to launch the program '''as administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Server'' section; note that at the following reboot Synergy will indeed automatically start, but the tray icon will not display automatically (at least for version 1.4.2 beta on Windows 7). To uninstall the service, do the same thing but obviously select ''Uninstall''.<br />
<br />
If you want to start the server from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}:<br />
<br />
C:\Program Files\Synergy+\bin\synergys.exe -f --debug ERROR --name left --log c:\windows\synergy.log -c C:/windows/synergy.sgc --address 10.66.66.2:24800<br />
<br />
===macOS===<br />
<br />
macOS has a similar configuration as Unix: check [https://github.com/symless/synergy-core/wiki/Developer the official documentation] for more information.<br />
<br />
===Configuration examples===<br />
<br />
This is an example for a basic 3-computers setup:<br />
<br />
{{hc|/etc/synergy.conf|<nowiki><br />
section: screens<br />
server-fire:<br />
archright-fire:<br />
archleft-fire:<br />
end<br />
<br />
section: links<br />
archleft-fire:<br />
right = server-fire<br />
server-fire:<br />
right = archright-fire<br />
left = archleft-fire<br />
archright-fire:<br />
left = server-fire<br />
end<br />
</nowiki>}}<br />
<br />
This should be the example bundled with the Arch Linux package:<br />
<br />
{{hc|/etc/synergy.conf|2=<br />
section: screens<br />
# three hosts named: moe, larry, and curly<br />
moe:<br />
larry:<br />
curly:<br />
end<br />
<br />
section: links<br />
# larry is to the right of moe and curly is above moe<br />
moe:<br />
right = larry<br />
up = curly<br />
<br />
# moe is to the left of larry and curly is above larry.<br />
# note that curly is above both moe and larry and moe<br />
# and larry have a symmetric connection (they're in<br />
# opposite directions of each other).<br />
larry:<br />
left = moe<br />
up = curly<br />
<br />
# larry is below curly. if you move up from moe and then<br />
# down, you'll end up on larry.<br />
curly:<br />
down = larry<br />
end<br />
<br />
section: aliases<br />
# curly is also known as shemp<br />
curly:<br />
shemp<br />
end<br />
<br />
}}<br />
<br />
The following is a more customized example:<br />
<br />
{{hc|synergy.sgc|2=<br />
section: screens<br />
leftpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
rightpc:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
leftpc:<br />
10.66.66.2<br />
rightpc:<br />
10.66.66.1<br />
end<br />
<br />
section: links<br />
leftpc:<br />
right = rightpc<br />
rightpc:<br />
left = leftpc<br />
end<br />
<br />
section: options<br />
heartbeat = 1000<br />
relativeMouseMoves = false<br />
screenSaverSync = false<br />
win32KeepForeground = false<br />
switchCorners = none +top-left +top-right +bottom-left +bottom-right <br />
switchCornerSize = 4<br />
end<br />
}}<br />
<br />
==Clients configuration==<br />
<br />
{{Note|This assumes a server has been set up and configured '''properly'''. Make sure the server is already configured to accept the client(s) before continuing.}}<br />
{{Tip|You don't need to setup a client on the host server as the server includes one.}}<br />
<br />
===Arch Linux===<br />
In a console window, type:<br />
$ synergyc server-host-name<br />
<br />
Or, to run synergy in the foreground:<br />
$ synergyc -f server-host-name<br />
<br />
Here, {{ic|server-host-name}} is the host name of the server.<br />
<br />
====Use encryption==== <br />
<br />
<br />
If you use the synergy command line client, copy the file containing the fingerprint [[synergy|{{ic|~/.synergy/SSL/Fingerprints/Local.txt}}]] from the server into the clients home directory [[synergy|{{ic|~/.synergy/SSL/Fingerprints/TrustedServers.txt}}]]. To start the synergy command line client with encryption, type:<br />
$ synergyc --enable-crypto<br />
<br />
{{Note| There is an open issue with the GUI client of synergy (see https://github.com/symless/synergy-core/issues/4737). The dialog to prompt for confirmation of the server's fingerprint, only pops up if the logging level is set to INFO, DEBUG or DEBUG2.}}<br />
<br />
====Autostart====<br />
<br />
There exist several ways to automatically start the Synergy client, and they are actually the same that can be used for every other application.<br />
<br />
{{Note|In all of the following examples, you always have to substitute {{ic|server-host-name}} with the real server host name.}}<br />
<br />
* You can add the next line to your [[xinitrc|{{ic|~/.xinitrc}}]]:<br />
<br />
{{hc|~/.xinitrc|<br />
...<br />
<br />
#replace server-host-name with the real name<br />
synergyc server-host-name<br />
}}<br />
<br />
The following is an alternative:<br />
<br />
{{hc|~/.xinitrc|<br />
<nowiki>XINIT_CMD='/usr/bin/synergyc -d FATAL -n galileo-fire 10.66.66.2:24800'<br />
/usr/bin/pgrep -lxf "$XINIT_CMD" || ( ( $XINIT_CMD ) & )</nowiki><br />
}}<br />
<br />
* Otherwise, if you are using a [[display manager]] (kdm, gdm, [[SLiM]], ...), or a stand-alone [[window manager]] (Openbox, ...), you could exploit its start-up script and add the following:<br />
synergyc server-host-name<br />
<br />
For example, using ''kdm'' you should edit {{ic|/usr/share/config/kdm/Xsetup}}.<br />
<br />
* To start the Synergy client with systemd, create a service file:<br />
<br />
{{hc|~/.config/systemd/user/synergyc.service|2=<br />
[Unit]<br />
Description=Synergy Client Daemon<br />
After=network.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/synergyc --no-daemon ''server-name''<br />
<br />
[Install]<br />
WantedBy=default.target}}<br />
<br />
To start the service for your user:<br />
<br />
# systemctl --user start synergyc<br />
<br />
To start the service at login for your user:<br />
<br />
# systemctl --user enable synergyc<br />
<br />
Automatically starting Synergy is also documented in its [https://github.com/symless/synergy-core/wiki/Startup official reference page].<br />
<br />
===Windows===<br />
<br />
After installation, open the Synergy program, select the option ''Client (use another computer's keyboard and mouse)'' and type the host name of the server computer in the text box, then click ''Start'' to start the client.<br />
{{Note|You can use the tray icon to stop the client.}}<br />
<br />
If you want to start the Synergy client every time Windows starts, you have to launch the program '''as an administrator''', then go to ''Edit -> Services'' and select ''Install'' in the ''Client'' section.<br />
<br />
If you want to start the client from the command-line, here is a Windows command you can place in a {{ic|.bat}} file or just run from {{ic|cmd.exe}}. This points to a configuration file in {{ic|C:\synergy.sgc}} and runs in the background like a service.<br />
<br />
{{bc|<nowiki>START /MIN /D"C:\Program Files\Synergy+\bin" synergys.exe -d ERROR -n m6300 -c C:\synergy.sgc -a 10.66.66.2:24800</nowiki>}}<br />
<br />
===macOS===<br />
<br />
Locate the synergyc program in the synergyc folder and drag it onto the terminal window: the full path will appear in the terminal.<br />
Now append the host name of the server, so that the complete command will look like this:<br />
<br />
{{bc|/path/to/synergyc/synergyc server-host-name}}<br />
<br />
Then press {{ic|Enter}}.<br />
<br />
==Known issues==<br />
If Arch is being used as a client in a Synergy installation, the server may not be able to wake the client monitor. There are some workarounds, such as executing the following via [[SSH]], if ACPI is enabled (see: [[Display Power Management Signaling#Modifying DPMS and screensaver settings using xset|Modifying DPMS and ScreenSaver settings with xset]]):<br />
{{bc|# xset dpms force on}}<br />
<br />
==Troubleshooting==<br />
The official documentation has a [https://github.com/symless/synergy-core/wiki/User-FAQ FAQ] and also a [https://github.com/symless/synergy-core/wiki/User-Guide#Troubleshooting troubleshooting page].<br />
<br />
===Keyboard AltGr===<br />
If you encounter problems with AltGr add <br />
<br />
altgr = alt #1.8.2<br />
altgr = shift #v1.8.3 and higher<br />
<br />
on the screen/client section in /etc/synergys.conf.<br />
<br />
===Keyboard repeat===<br />
If you experience problems with your keyboard repeat on the client machine (Linux host), simply type:<br />
{{bc|# /usr/bin/xset r on}}<br />
in any console.<br />
<br />
===Keyboard mapping===<br />
If you experience problems with the keyboard mapping when using the server's keyboard in a client window (e.g a terminal) then re-setting the X key map after starting synergyc may help. The following command sets the keymap to its current value:<br />
<br />
# setxkbmap $(setxkbmap -query | grep "^layout:" | awk -F ": *" '{print $2}')<br />
<br />
===No cursor in Gnome===<br />
When [[GNOME]] doesn't detect a mouse, it will default to touchscreen mode and hide the cursor. To enable run:<br />
<br />
# dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
This can be added to an init script or systemd unit:<br />
<br />
ExecStartPost=dconf write /org/gnome/settings-daemon/plugins/cursor/active false<br />
<br />
===Client is returning "failed to verify server certificate fingerprint"===<br />
You need to copy the content of server's "~/.synergy/SSL/Fingerprints/Local.txt" into client's "~/.synergy/SSL/Fingerprints/TrustedServers.txt".<br />
<br />
==External links==<br />
* Synergy website: https://symless.com/synergy/<br />
* Official documentation: https://github.com/symless/synergy-core/wiki/User-Guide</div>Slowbrohttps://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=489282PCI passthrough via OVMF2017-09-09T02:16:04Z<p>Slowbro: /* CPU pinning with isolcpus */ update cmdline example</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:OVMF による PCI パススルー]]<br />
The Open Virtual Machine Firmware ([http://www.tianocore.org/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 [http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf presentation (pdf)]. <br />
<br />
== Prerequisites ==<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 />
** [http://ark.intel.com/Search/FeatureFilter?productType=processors&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) don't have an IOMMU, so you '''need''' to have a motherboard with a [http://support.amd.com/TechDocs/43403.pdf#page=18 890FX] or [http://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 [http://wiki.xen.org/wiki/VTdHowTo fairly comprehensive list on the matter on the Xen wiki] as well as [[wikipedia:List_of_IOMMU-supporting_hardware|another one on Wikipedia]].<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 />
IOMMU is a system specific IO mapping mechanism and can be used with most devices. IOMMU is a generic name for Intel VT-d and AMD-Vi.<br />
<br />
Before you enable IOMMU, you might have to first enable (non-IOMMU) virtualisation (Intel VT-x/"Vanderpool" or AMD-V/"Pacifica") in your BIOS settings.<br />
<br />
===Enabling IOMMU===<br />
Ensure that AMD-Vi/Intel VT-d is enabled in your 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 />
You will also have to enable iommu support in the kernel itself through a [[Kernel_parameters|bootloader kernel option]]. Depending on your type of CPU, use either {{ic|intel_iommu<nowiki>=</nowiki>on}} for Intel CPUs (VT-d) or {{ic|amd_iommu<nowiki>=</nowiki>on}} for AMD CPUs (AMD-Vi).<br />
<br />
After rebooting, check dmesg to confirm that IOMMU has been correctly enabled:<br />
{{hc|dmesg<nowiki>|</nowiki>grep -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 />
===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 d in /sys/kernel/iommu_groups/*/devices/*; do <br />
n=${d#*/iommu_groups/*}; n=${n%%/*}<br />
printf 'IOMMU Group %s ' "$n"<br />
lspci -nns "${d##*/}"<br />
done;<br />
<br />
Example output:<br />
<br />
IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)<br />
IOMMU Group 1 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)<br />
IOMMU Group 2 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)<br />
IOMMU Group 3 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev <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 />
====Plugging your guest GPU in an unisolated CPU-based PCIe slot====<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 be appear to be grouped with the device that is connected to it.<br />
<br />
IOMMU Group 1 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)<br />
IOMMU Group 1 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)<br />
IOMMU Group 1 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 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 />
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 prefered 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.}}<br />
<br />
===Using vfio-pci===<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, but it can also control devices to an extent, such as by switching them into their D3 state when they are not in use. If your system supports it, which you can try by running the following command, you should use it. If it returns an error, use pci-stub instead.<br />
<br />
{{hc|$ modinfo vfio-pci|<br />
filename: /lib/modules/4.4.5-1-ARCH/kernel/drivers/vfio/pci/vfio-pci.ko.gz<br />
description: VFIO PCI - User Level meta-driver<br />
author: Alex Williamson <alex.williamson@redhat.com><br />
...}}<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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU Group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
<br />
You can then add those vendor-device ID pairs to the default parameters passed to vfio-pci whenever it is inserted into the kernel.<br />
{{hc|1=/etc/modprobe.d/vfio.conf|2=options vfio-pci ids=10de:13c2,10de:0fbb}}<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], 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 />
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}}, {{ic|vfio_iommu_type1}}, {{ic|vfio_pci}} and {{ic|vfio_virqfd}} to [[mkinitcpio]]:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=MODULES="... vfio vfio_iommu_type1 vfio_pci vfio_virqfd ..."}}<br />
<br />
{{note|If you also have another driver loaded this way for [[Kernel_mode_setting#Early_KMS_start|early modesetting]] (such as "nouveau", "radeon", "amdgpu", "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 mkinitcpio.conf:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=HOOKS="... modconf ..."}}<br />
<br />
Since new modules have been added to the initramfs configuration, it must be regenerated. 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 />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Reboot and verify that vfio-pci has loaded properly and that it is now bound to the right devices.<br />
{{hc|$ dmesg <nowiki>|</nowiki> 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 />
It isn't necessary for all devices (or even expected device) from vfio.conf to be in dmesg output. Sometimes device doesn't 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 />
{{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 />
===Using pci-stub (legacy method, pre-4.1 kernels)===<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead, which is a dummy driver used to claim a device and prevent other drivers from using it.<br />
<br />
Pci-stub 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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
Most linux distros (including Arch Linux) have pci-stub built statically within the kernel image. If for any reason it needs to be loaded as a module in your case, you will need to bind it yourself using whatever tool your distro provides for this, such as {{ic|mkinitpcio}} for Arch.<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
<br />
If you did need to add this module to your kernel image configuration manually, you must also regenerate it.<br />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Add the relevant PCI device IDs to the {{ic|pci-stubs.ids}} [[kernel parameter]], e.g. {{ic|1=pci-stub.ids=10de:13c2,10de:0fbb}}.<br />
<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], your pci root port is part of your IOMMU group, you '''must not''' pass its ID to {{ic|pci-stub}}, as it needs to remain attached to the host to function properly. Any other device within that group, however, should be left for {{ic|pci-stub}} to bind with.}}<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
[ 2.390128] pci-stub: add 10DE:13C2 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:06:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 10DE:0FBB sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:06:00.1: claimed by stub}}<br />
<br />
==Setting up an OVMF-based guest VM==<br />
OVMF is an open-source UEFI firmware for QEMU virtual machines. While it's 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 />
[[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|<br />
<nowiki>nvram = [</nowiki><br />
"/usr/share/ovmf/ovmf_code_x64.bin:/usr/share/ovmf/ovmf_vars_x64.bin"<br />
]<br />
}}<br />
<br />
You can now [[enable]] and start {{ic|libvirtd}} and its logging component.<br />
<br />
{{bc|<br />
# systemctl enable --now libvirtd<br />
# systemctl enable virtlogd.socket}}<br />
<br />
===Setting up the guest OS===<br />
The process of setting up a VM using {{ic|virt-manager}} is mostly self explainatory, as most of the process comes with fairly comprehensive on-screen instructions. However, you should pay special attention to the following steps :<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 you have correctly specified the location of your firmware in {{ic|/etc/libvirt/qemu.conf}} and restart {{ic|libvirtd.service}}.<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.<br />
<br />
===Attaching the PCI devices===<br />
With the installation done, it's 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 />
===Gotchas===<br />
====Using a non-EFI image on an OVMF-based VM====<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 />
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 />
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. Since switching between threads adds a bit of overhead (because context switching forces the core to change its cache between operations), this can noticeably harm performance on the guest. CPU pinning aims to resolve this as it overrides process scheduling and ensures that the VM threads will always run and only run on those specific cores. Here, for instance, the guest cores 0, 1, 2 and 3 are mapped to the host cores 4, 5, 6 and 7 respectively.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune></nowiki><br />
...}}<br />
<br />
====The case of Hyper-threading====<br />
If your CPU supports hardware multitasking, also known as Hyper-threading on Intel chips, there are two ways you can go with your CPU pinning. That is, Hyper-threading is simply a very efficient way of running two threads on one CPU at any given time, so while it may give you 8 logical cores on what would otherwise be a quad-core CPU, if the physical core is overloaded, the logical core won't be of any use. One could pin their VM threads on 2 physical cores and their 2 respective threads, but any task overloading those two cores won't be helped by the extra two logical cores, since in the end you're only passing through two cores out of four, not four out of eight. What you should do knowing this depends on what you intend to do with your host while your VM is running.<br />
<br />
This is the abridged content of {{ic|/proc/cpuinfo}} on a quad-core machine with hyper-threading.<br />
{{hc|<nowiki>$ cat /proc/cpuinfo | grep -e "processor" -e "core id" -e "^$"</nowiki>|<br />
processor : 0<br />
core id : 0<br />
<br />
processor : 1<br />
core id : 1<br />
<br />
processor : 2<br />
core id : 2<br />
<br />
processor : 3<br />
core id : 3<br />
<br />
processor : 4<br />
core id : 0<br />
<br />
processor : 5<br />
core id : 1<br />
<br />
processor : 6<br />
core id : 2<br />
<br />
processor : 7<br />
core id : 3}}<br />
<br />
If you don't 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, it would probably be better to pin your VM threads across all of your logical cores, so that the VM can fully take advantage of the spare CPU time on all your cores.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='4' threads='1'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
If you would instead prefer to have the host and guest running intensive tasks at the same time, it would then be preferable to pin a limited amount of physical cores and their respective threads on the guest and leave the rest to the host to avoid the two competing for CPU time.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='3'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='2' threads='2'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
===Static huge pages===<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 accross 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 4GB of memory divided into 4kB pages (which is the default size for normal 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. This is normally handeled with transparent huge pages, which dynamically manages hugepages to keep up with the demand.<br />
<br />
On a VM with a PCI passthrough, however, it is '''not possible''' to benefit from transparent huge pages, as IOMMU requires that the guest's memory be allocated and pinned as soon as the VM starts. It is therefore required to allocate huge pages statically in order to benefit from them. <br />
<br />
{{warning|Do note that static huge pages lock down the allocated amount of memory, making it unavailable for applications that are not configured to use them. Allocating 4GBs worth of huge pages on a machine with 8GBs of memory will only leave you with 4GBs 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 comand line with {{ic|<nowiki>hugepages=x</nowiki>}}. For instance, reserving 1024 pages with {{ic|<nowiki>hugepages=1024</nowiki>}} and the default size of 2048kB per huge page creates 2GBs worth of memory for the virtual machine to use.<br />
<br />
If supported by CPU page size could be set manually. 1 GB huge page support could be verified by {{ic|<nowiki>grep pdpe1gb /proc/cpuinfo</nowiki>}}. Setting 1 GB huge page size via kernel parameters :{{ic|<nowiki>default_hugepagesz=1G hugepagesz=1G hugepages=X transparent_hugepage=never</nowiki>}}<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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<memoryBacking><br />
<hugepages/><br />
</memoryBacking><br />
...}}<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're 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 />
=== High DPC Latency ===<br />
{{Accuracy|As far as I can tell all virtio modules listed here are for virtual devices used when Linux runs as a guest. Loading them on the host serves no purpose.}}<br />
If you are experiencing high DPC and/or interrupt latency in your Guest VM, ensure you have [[Kernel_modules#Manual_module_handling|loaded the needed virtio kernel modules]] on the host kernel. Loadable virtio kernel modules include: {{ic|virtio-pci, virtio-net, virtio-blk, virtio-balloon, virtio-ring}} and {{ic|virtio}}. <br />
<br />
After loading one or more of these modules, {{ic|lsmod <nowiki>|</nowiki> grep virtio}} executed on the host should not return empty.<br />
<br />
==== CPU pinning with isolcpus ====<br />
Alternatively, make sure that you have isolated CPUs properly. In this example, I will assume you are using CPUs 4-7.<br />
Use the kernel parameters {{ic|isolcpus nohz_full rcb_nocbs}} to completely isolate the CPUs from the kernel. <br />
<br />
{{hc|sudo vim /etc/defaults/grub|<nowiki>...<br />
GRUB_CMDLINE_LINUX="..your other params.. isolcpus=4-7 nohz_full=4-7 rcb_nocbs=4-7"<br />
...</nowiki>}}<br />
<br />
Then, run {{ic|qemu-system-x86_64}} with taskset and chrt:<br />
<br />
<code>sudo chrt -r 1 taskset -c 4-7 qemu-system-x86_64 ...</code><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.reddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ this reddit comment] for more info.<br />
<br />
===Improving performance on AMD CPU===<br />
<br />
{{note|Was tested on AMD Ryzen 5 1600 - helps a lot, depends on guest's applications. This slows down systems with AMD FX processors considerably, 1GB hugepages are fine however.}}<br />
<br />
Disabling Nested Page Tables(aka NPT) will improve GPU performance to a bare metal level.<br />
<br />
{{hc|1=/etc/modprobe.d/kvm_amd.conf|2=options kvm_amd npt=0}}<br />
<br />
Using [[#Static huge pages|huge pages]] for guest and bigger huge page size(e.g. 1 GB) could reduce periodical micro-freezes of whole VM introduced by disabled NPT.<br />
<br />
If periodical stuttering still occurs try removing smep feature from vCPU:<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<cpu mode='host-passthrough' check='none'><br />
...<br />
<feature policy='disable' name='smep'/><br />
...<br />
</cpu><br />
</nowiki><br />
...}}<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're 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're 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 />
{{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 />
Due to how both pci-stub and vfio-pci use 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 won't 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're using is instead assigned by pci bus address using the {{ic|driver_override}} mechanism.<br />
<br />
==== Script variants ====<br />
===== Passthrough all GPUs but the boot GPU =====<br />
Here, we will make a script to bind vfio-pci to all GPUs but the boot gpu. Create the script "/sbin/vfio-pci-override.sh":<br />
<br />
#!/bin/sh<br />
<br />
for i in /sys/devices/pci*/*/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 />
<br />
===== Passthrough selected GPU =====<br />
In this case we manually specify the GPU to bind.<br />
<br />
#!/bin/sh<br />
<br />
GROUP="0000:00:03.0"<br />
DEVS="0000:03:00.0 0000:03:00.1 ."<br />
<br />
if [ ! -z "$(ls -A /sys/class/iommu)" ]<br />
then<br />
for DEV in $DEVS; do<br />
echo "vfio-pci" > /sys/bus/pci/devices/$GROUP/$DEV/driver_override<br />
done<br />
fi<br />
<br />
modprobe -i vfio-pci<br />
<br />
==== Script installation ====<br />
Create /etc/modprobe.d/vfio.conf with the following:<br />
install vfio-pci /sbin/vfio-pci-override.sh<br />
<br />
Edit /etc/mkinitcpio.conf<br />
<br />
Remove any video drivers from MODULES, and add vfio-pci, and vfio_iommu_type1<br />
MODULES="ext4 vfat vfio-pci vfio_iommu_type1"<br />
<br />
Add "/etc/modprobe.d/vfio.conf" and "/sbin/vfio-pci-override.sh" to FILES:<br />
FILES="/etc/modprobe.d/vfio.conf /sbin/vfio-pci-override.sh"<br />
<br />
Regenerate your initramfs, and reboot:<br />
mkinitcpio -p linux<br />
<br />
=== Passing the boot GPU to the guest ===<br />
{{Expansion|Not possible at the time as far as I'm aware, but a common issue on various forums.|Talk:PCI passthrough via OVMF#Additionnal_sections}}<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's not possible, to swap the host and guest cards in the machine itself.<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 [http://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|pcie_acs_override<nowiki>=</nowiki>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|pcie_acs_override<nowiki>=</nowiki>}} 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|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/ovmf_vars_x64.bin}} to temporary location like {{ic|/tmp/my_vars.bin}} and finally specify the OVMF paths by appending the following parameters to the QEMU command:<br />
<br />
* {{ic|1=-drive if=pflash,format=raw,file=/tmp/my_vars.bin}} for the variables<br />
* {{ic|1=-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/ovmf_code_x64.bin}} for the actual OVMF firmware binary, note the readonly option<br />
<br />
{{Note|QEMU's default SeaBIOS can be used instead of OVMF, but it's not recommended as it can cause issues with passthrough setups.}}<br />
<br />
It's 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 />
===USB controller===<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 />
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 />
===Passing VM audio to host via PulseAudio===<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|<nowiki>#user = ""</nowiki>}} line. Then add your username in the quotations. This tells QEMU which user's pulseaudio stream to route through.<br />
{{hc|/etc/libvirt/qemu.conf|<br />
user <nowiki>=</nowiki> "example"}}<br />
<br />
Next, modify the libvirt configuration<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
</devices><br />
</domain><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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 libvirt and pulseaudio (run as your user)<br />
<br />
{{hc|systemctl restart libvirtd |<br />
pulseaudio --kill<br />
pulseaudio --start<br />
}}<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 />
===Gotchas===<br />
====Passing through a device that does not support resetting====<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 functionnal 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 won't 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 />
If you have trouble configuring a certain mechanism in your setup, you might want to look up [[PCI_passthrough_via_OVMF/Examples|complete passthrough setup examples]]. A few users have described their setups and you might want to look up certain tricks from their configuration files.<br />
<br />
== Troubleshooting ==<br />
<br />
==="Error 43: Driver failed to load" on Nvidia GPUs passed to Windows VMs===<br />
{{Note|This may also fix SYSTEM_THREAD_EXCEPTION_NOT_HANDLED boot crashes related to Nvidia drivers.}}<br />
{{Note|This may also fix problems under linux guests.}}<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=whatever</nowiki>}} to the cpu parameters in their QEMU command line, or by adding the following line to their libvirt domain configuration. It may help for the ID to be set to a 12-character alphanumeric (e.g. '123456789ab') as opposed to longer or shorter strings.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<features><br />
<hyperv><br />
...<br />
<vendor_id state='on' value='whatever'/><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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><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></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 />
...</nowiki>}}<br />
<br />
===="BAR 3: can't reserve [mem]" error in dmesg after starting VM====<br />
<br />
With respect to [http://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: can't 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]] video<nowiki>=</nowiki>efifb:off is required as well. [https://pve.proxmox.com/wiki/Pci_passthrough#BAR_3:_can.27t_reserve_.5Bmem.5D_error Source]}}<br />
<br />
<br />
=== UEFI (OVMF) Compatability 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'll 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 />
# cd /sys/bus/pci/devices/0000:01:00.0/<br />
# echo 1 > rom<br />
# cat rom > /tmp/image.rom<br />
# echo 0 > rom<br />
<br />
And test it for compatibility:<br />
<br />
$ ./rom-parser /tmp/image.rom<br />
<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 />
To be UEFI compatible, you need a "type 3 (EFI)" in the result. If it's 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 />
<pre><br />
-device vfio-pci,host=07:00.0,......,romfile=/path/to/your/gpu/bios.bin \<br />
</pre><br />
<br />
And in libvirt:<br />
<pre><br />
<hostdev><br />
...<br />
<rom file='/path/to/your/gpu/bios.bin'/><br />
...<br />
</hostdev><br />
</pre><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 />
<pre><br />
./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 />
</pre><br />
<br />
And to check a given VBIOS file:<br />
<br />
<pre><br />
./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 />
</pre><br />
<br />
If the external ROM did not work as it should in the guest, you'll have to flash the newer VBIOS image to the GPU.<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 />
# rmmod nvidia_modeset nvidia <br />
<br />
Flashing the VBIOS can be done with:<br />
<br />
# ./nvflash romfile.bin<br />
<br />
'''DO NOT''' interrupt the flashing process, even if it looks like it's stuck. Flashing should take about a minute on most GPUs, but may take longer.<br />
<br />
=== Unexpected crashes related to CPU exceptions ===<br />
KVM injects a GPF when the guest tries to access unsupported MSRs. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs instead of returning an error value.<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
Cases where adding this option might help:<br />
* GeForce Experience complaining about an unsupported CPU being present<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with KMODE_EXCEPTION_NOT_HANDLED. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
=== "System Thread Exception Not Handled" when booting on a Windows VM ===<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Slowed down audio pumped through HDMI on the video card ===<br />
For some users VM's audio slows down/starts stuttering/becomes demonic after a while when it's 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 />
# lspci -vs $device | grep 'MSI:'<br />
where `$device` is the card's address (e.g. `01:00.0`).<br />
<br />
The output should be similar to:<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 [http://forums.guru3d.com/showthread.php?t=378044 here].<br />
<br />
Other hints can be found on the [http://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 [http://vfio.blogspot.it/2014/09/vfio-interrupts-and-how-to-coax-windows.html VFIO tips and tricks].<br />
<br />
Some tools named {{ic|MSI_util}} or similar are available on the Internet, but they didn't work for me on Windows 10 64bit.<br />
<br />
In order to fix the issues enabling MSI on the 0 function of my 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; I also enabled it on the other function ({{ic|01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)}}) and that seems to have fixed 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|intel_iommu<nowiki>=</nowiki>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 doesnt start after enabling vfio_pci ===<br />
<br />
This is related to the host gpu being detected as a secondary gpu, which cases X to error, when it tries to load a driver for the guest gpu. To circumvent this, a xorg conf specifying the BusID for the host gpu is necessary. The correct BusID can be acquired from lspci or the Xorg log.<br />
{{hc|10-radeon.conf|<nowiki>Section "Device"<br />
Identifier "Radeon GPU"<br />
Driver "radeon"<br />
BusID "PCI:3:0:0"<br />
EndSection</nowiki>}}<br />
[https://www.redhat.com/archives/vfio-users/2016-August/msg00025.html Source]<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 />
== See also ==<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 />
* [http://pastebin.com/rcnUZCv7 Example script from https://www.youtube.com/watch?v=37D2bRsthfI]<br />
* [http://vfio.blogspot.com/ Complete tutorial for PCI passthrough]<br />
* [https://www.redhat.com/archives/vfio-users/ VFIO users mailing list]<br />
* [https://webchat.freenode.net/?channels=vfio-users #vfio-users on freenode]<br />
* [https://www.youtube.com/watch?v=aLeWg11ZBn0 YouTube: Level1Linux - GPU Passthrough for Virtualization with Ryzen]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=489281PCI passthrough via OVMF2017-09-09T02:15:15Z<p>Slowbro: /* High DPC Latency */ better formatted</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:OVMF による PCI パススルー]]<br />
The Open Virtual Machine Firmware ([http://www.tianocore.org/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 [http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf presentation (pdf)]. <br />
<br />
== Prerequisites ==<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 />
** [http://ark.intel.com/Search/FeatureFilter?productType=processors&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) don't have an IOMMU, so you '''need''' to have a motherboard with a [http://support.amd.com/TechDocs/43403.pdf#page=18 890FX] or [http://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 [http://wiki.xen.org/wiki/VTdHowTo fairly comprehensive list on the matter on the Xen wiki] as well as [[wikipedia:List_of_IOMMU-supporting_hardware|another one on Wikipedia]].<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 />
IOMMU is a system specific IO mapping mechanism and can be used with most devices. IOMMU is a generic name for Intel VT-d and AMD-Vi.<br />
<br />
Before you enable IOMMU, you might have to first enable (non-IOMMU) virtualisation (Intel VT-x/"Vanderpool" or AMD-V/"Pacifica") in your BIOS settings.<br />
<br />
===Enabling IOMMU===<br />
Ensure that AMD-Vi/Intel VT-d is enabled in your 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 />
You will also have to enable iommu support in the kernel itself through a [[Kernel_parameters|bootloader kernel option]]. Depending on your type of CPU, use either {{ic|intel_iommu<nowiki>=</nowiki>on}} for Intel CPUs (VT-d) or {{ic|amd_iommu<nowiki>=</nowiki>on}} for AMD CPUs (AMD-Vi).<br />
<br />
After rebooting, check dmesg to confirm that IOMMU has been correctly enabled:<br />
{{hc|dmesg<nowiki>|</nowiki>grep -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 />
===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 d in /sys/kernel/iommu_groups/*/devices/*; do <br />
n=${d#*/iommu_groups/*}; n=${n%%/*}<br />
printf 'IOMMU Group %s ' "$n"<br />
lspci -nns "${d##*/}"<br />
done;<br />
<br />
Example output:<br />
<br />
IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)<br />
IOMMU Group 1 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)<br />
IOMMU Group 2 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)<br />
IOMMU Group 3 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev <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 />
====Plugging your guest GPU in an unisolated CPU-based PCIe slot====<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 be appear to be grouped with the device that is connected to it.<br />
<br />
IOMMU Group 1 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)<br />
IOMMU Group 1 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)<br />
IOMMU Group 1 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 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 />
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 prefered 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.}}<br />
<br />
===Using vfio-pci===<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, but it can also control devices to an extent, such as by switching them into their D3 state when they are not in use. If your system supports it, which you can try by running the following command, you should use it. If it returns an error, use pci-stub instead.<br />
<br />
{{hc|$ modinfo vfio-pci|<br />
filename: /lib/modules/4.4.5-1-ARCH/kernel/drivers/vfio/pci/vfio-pci.ko.gz<br />
description: VFIO PCI - User Level meta-driver<br />
author: Alex Williamson <alex.williamson@redhat.com><br />
...}}<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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU Group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
<br />
You can then add those vendor-device ID pairs to the default parameters passed to vfio-pci whenever it is inserted into the kernel.<br />
{{hc|1=/etc/modprobe.d/vfio.conf|2=options vfio-pci ids=10de:13c2,10de:0fbb}}<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], 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 />
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}}, {{ic|vfio_iommu_type1}}, {{ic|vfio_pci}} and {{ic|vfio_virqfd}} to [[mkinitcpio]]:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=MODULES="... vfio vfio_iommu_type1 vfio_pci vfio_virqfd ..."}}<br />
<br />
{{note|If you also have another driver loaded this way for [[Kernel_mode_setting#Early_KMS_start|early modesetting]] (such as "nouveau", "radeon", "amdgpu", "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 mkinitcpio.conf:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=HOOKS="... modconf ..."}}<br />
<br />
Since new modules have been added to the initramfs configuration, it must be regenerated. 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 />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Reboot and verify that vfio-pci has loaded properly and that it is now bound to the right devices.<br />
{{hc|$ dmesg <nowiki>|</nowiki> 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 />
It isn't necessary for all devices (or even expected device) from vfio.conf to be in dmesg output. Sometimes device doesn't 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 />
{{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 />
===Using pci-stub (legacy method, pre-4.1 kernels)===<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead, which is a dummy driver used to claim a device and prevent other drivers from using it.<br />
<br />
Pci-stub 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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
Most linux distros (including Arch Linux) have pci-stub built statically within the kernel image. If for any reason it needs to be loaded as a module in your case, you will need to bind it yourself using whatever tool your distro provides for this, such as {{ic|mkinitpcio}} for Arch.<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
<br />
If you did need to add this module to your kernel image configuration manually, you must also regenerate it.<br />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Add the relevant PCI device IDs to the {{ic|pci-stubs.ids}} [[kernel parameter]], e.g. {{ic|1=pci-stub.ids=10de:13c2,10de:0fbb}}.<br />
<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], your pci root port is part of your IOMMU group, you '''must not''' pass its ID to {{ic|pci-stub}}, as it needs to remain attached to the host to function properly. Any other device within that group, however, should be left for {{ic|pci-stub}} to bind with.}}<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
[ 2.390128] pci-stub: add 10DE:13C2 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:06:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 10DE:0FBB sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:06:00.1: claimed by stub}}<br />
<br />
==Setting up an OVMF-based guest VM==<br />
OVMF is an open-source UEFI firmware for QEMU virtual machines. While it's 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 />
[[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|<br />
<nowiki>nvram = [</nowiki><br />
"/usr/share/ovmf/ovmf_code_x64.bin:/usr/share/ovmf/ovmf_vars_x64.bin"<br />
]<br />
}}<br />
<br />
You can now [[enable]] and start {{ic|libvirtd}} and its logging component.<br />
<br />
{{bc|<br />
# systemctl enable --now libvirtd<br />
# systemctl enable virtlogd.socket}}<br />
<br />
===Setting up the guest OS===<br />
The process of setting up a VM using {{ic|virt-manager}} is mostly self explainatory, as most of the process comes with fairly comprehensive on-screen instructions. However, you should pay special attention to the following steps :<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 you have correctly specified the location of your firmware in {{ic|/etc/libvirt/qemu.conf}} and restart {{ic|libvirtd.service}}.<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.<br />
<br />
===Attaching the PCI devices===<br />
With the installation done, it's 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 />
===Gotchas===<br />
====Using a non-EFI image on an OVMF-based VM====<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 />
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 />
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. Since switching between threads adds a bit of overhead (because context switching forces the core to change its cache between operations), this can noticeably harm performance on the guest. CPU pinning aims to resolve this as it overrides process scheduling and ensures that the VM threads will always run and only run on those specific cores. Here, for instance, the guest cores 0, 1, 2 and 3 are mapped to the host cores 4, 5, 6 and 7 respectively.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune></nowiki><br />
...}}<br />
<br />
====The case of Hyper-threading====<br />
If your CPU supports hardware multitasking, also known as Hyper-threading on Intel chips, there are two ways you can go with your CPU pinning. That is, Hyper-threading is simply a very efficient way of running two threads on one CPU at any given time, so while it may give you 8 logical cores on what would otherwise be a quad-core CPU, if the physical core is overloaded, the logical core won't be of any use. One could pin their VM threads on 2 physical cores and their 2 respective threads, but any task overloading those two cores won't be helped by the extra two logical cores, since in the end you're only passing through two cores out of four, not four out of eight. What you should do knowing this depends on what you intend to do with your host while your VM is running.<br />
<br />
This is the abridged content of {{ic|/proc/cpuinfo}} on a quad-core machine with hyper-threading.<br />
{{hc|<nowiki>$ cat /proc/cpuinfo | grep -e "processor" -e "core id" -e "^$"</nowiki>|<br />
processor : 0<br />
core id : 0<br />
<br />
processor : 1<br />
core id : 1<br />
<br />
processor : 2<br />
core id : 2<br />
<br />
processor : 3<br />
core id : 3<br />
<br />
processor : 4<br />
core id : 0<br />
<br />
processor : 5<br />
core id : 1<br />
<br />
processor : 6<br />
core id : 2<br />
<br />
processor : 7<br />
core id : 3}}<br />
<br />
If you don't 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, it would probably be better to pin your VM threads across all of your logical cores, so that the VM can fully take advantage of the spare CPU time on all your cores.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='4' threads='1'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
If you would instead prefer to have the host and guest running intensive tasks at the same time, it would then be preferable to pin a limited amount of physical cores and their respective threads on the guest and leave the rest to the host to avoid the two competing for CPU time.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='3'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='2' threads='2'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
===Static huge pages===<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 accross 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 4GB of memory divided into 4kB pages (which is the default size for normal 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. This is normally handeled with transparent huge pages, which dynamically manages hugepages to keep up with the demand.<br />
<br />
On a VM with a PCI passthrough, however, it is '''not possible''' to benefit from transparent huge pages, as IOMMU requires that the guest's memory be allocated and pinned as soon as the VM starts. It is therefore required to allocate huge pages statically in order to benefit from them. <br />
<br />
{{warning|Do note that static huge pages lock down the allocated amount of memory, making it unavailable for applications that are not configured to use them. Allocating 4GBs worth of huge pages on a machine with 8GBs of memory will only leave you with 4GBs 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 comand line with {{ic|<nowiki>hugepages=x</nowiki>}}. For instance, reserving 1024 pages with {{ic|<nowiki>hugepages=1024</nowiki>}} and the default size of 2048kB per huge page creates 2GBs worth of memory for the virtual machine to use.<br />
<br />
If supported by CPU page size could be set manually. 1 GB huge page support could be verified by {{ic|<nowiki>grep pdpe1gb /proc/cpuinfo</nowiki>}}. Setting 1 GB huge page size via kernel parameters :{{ic|<nowiki>default_hugepagesz=1G hugepagesz=1G hugepages=X transparent_hugepage=never</nowiki>}}<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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<memoryBacking><br />
<hugepages/><br />
</memoryBacking><br />
...}}<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're 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 />
=== High DPC Latency ===<br />
{{Accuracy|As far as I can tell all virtio modules listed here are for virtual devices used when Linux runs as a guest. Loading them on the host serves no purpose.}}<br />
If you are experiencing high DPC and/or interrupt latency in your Guest VM, ensure you have [[Kernel_modules#Manual_module_handling|loaded the needed virtio kernel modules]] on the host kernel. Loadable virtio kernel modules include: {{ic|virtio-pci, virtio-net, virtio-blk, virtio-balloon, virtio-ring}} and {{ic|virtio}}. <br />
<br />
After loading one or more of these modules, {{ic|lsmod <nowiki>|</nowiki> grep virtio}} executed on the host should not return empty.<br />
<br />
==== CPU pinning with isolcpus ====<br />
Alternatively, make sure that you have isolated CPUs properly. In this example, I will assume you are using CPUs 4-7.<br />
Use the kernel parameters {{ic|isolcpus nohz_full rcb_nocbs}} to completely isolate the CPUs from the kernel. <br />
<br />
{{hc|sudo vim /etc/defaults/grub|<nowiki>...<br />
GRUB_CMDLINE_LINUX="..your other params.. isolcpus=4-7 nohz_full=4-7 rcb_nocbs=4-7"<br />
...</nowiki>}}<br />
<br />
Then, run {{ic|qemu-system-x86_64}} with taskset and chrt:<br />
<br />
<code>sudo chrt -r 1 taskset -c <YOUR_CPU_NUMBERS> qemu-system-x86_64 ...</code><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.reddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ this reddit comment] for more info.<br />
<br />
===Improving performance on AMD CPU===<br />
<br />
{{note|Was tested on AMD Ryzen 5 1600 - helps a lot, depends on guest's applications. This slows down systems with AMD FX processors considerably, 1GB hugepages are fine however.}}<br />
<br />
Disabling Nested Page Tables(aka NPT) will improve GPU performance to a bare metal level.<br />
<br />
{{hc|1=/etc/modprobe.d/kvm_amd.conf|2=options kvm_amd npt=0}}<br />
<br />
Using [[#Static huge pages|huge pages]] for guest and bigger huge page size(e.g. 1 GB) could reduce periodical micro-freezes of whole VM introduced by disabled NPT.<br />
<br />
If periodical stuttering still occurs try removing smep feature from vCPU:<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<cpu mode='host-passthrough' check='none'><br />
...<br />
<feature policy='disable' name='smep'/><br />
...<br />
</cpu><br />
</nowiki><br />
...}}<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're 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're 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 />
{{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 />
Due to how both pci-stub and vfio-pci use 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 won't 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're using is instead assigned by pci bus address using the {{ic|driver_override}} mechanism.<br />
<br />
==== Script variants ====<br />
===== Passthrough all GPUs but the boot GPU =====<br />
Here, we will make a script to bind vfio-pci to all GPUs but the boot gpu. Create the script "/sbin/vfio-pci-override.sh":<br />
<br />
#!/bin/sh<br />
<br />
for i in /sys/devices/pci*/*/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 />
<br />
===== Passthrough selected GPU =====<br />
In this case we manually specify the GPU to bind.<br />
<br />
#!/bin/sh<br />
<br />
GROUP="0000:00:03.0"<br />
DEVS="0000:03:00.0 0000:03:00.1 ."<br />
<br />
if [ ! -z "$(ls -A /sys/class/iommu)" ]<br />
then<br />
for DEV in $DEVS; do<br />
echo "vfio-pci" > /sys/bus/pci/devices/$GROUP/$DEV/driver_override<br />
done<br />
fi<br />
<br />
modprobe -i vfio-pci<br />
<br />
==== Script installation ====<br />
Create /etc/modprobe.d/vfio.conf with the following:<br />
install vfio-pci /sbin/vfio-pci-override.sh<br />
<br />
Edit /etc/mkinitcpio.conf<br />
<br />
Remove any video drivers from MODULES, and add vfio-pci, and vfio_iommu_type1<br />
MODULES="ext4 vfat vfio-pci vfio_iommu_type1"<br />
<br />
Add "/etc/modprobe.d/vfio.conf" and "/sbin/vfio-pci-override.sh" to FILES:<br />
FILES="/etc/modprobe.d/vfio.conf /sbin/vfio-pci-override.sh"<br />
<br />
Regenerate your initramfs, and reboot:<br />
mkinitcpio -p linux<br />
<br />
=== Passing the boot GPU to the guest ===<br />
{{Expansion|Not possible at the time as far as I'm aware, but a common issue on various forums.|Talk:PCI passthrough via OVMF#Additionnal_sections}}<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's not possible, to swap the host and guest cards in the machine itself.<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 [http://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|pcie_acs_override<nowiki>=</nowiki>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|pcie_acs_override<nowiki>=</nowiki>}} 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|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/ovmf_vars_x64.bin}} to temporary location like {{ic|/tmp/my_vars.bin}} and finally specify the OVMF paths by appending the following parameters to the QEMU command:<br />
<br />
* {{ic|1=-drive if=pflash,format=raw,file=/tmp/my_vars.bin}} for the variables<br />
* {{ic|1=-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/ovmf_code_x64.bin}} for the actual OVMF firmware binary, note the readonly option<br />
<br />
{{Note|QEMU's default SeaBIOS can be used instead of OVMF, but it's not recommended as it can cause issues with passthrough setups.}}<br />
<br />
It's 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 />
===USB controller===<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 />
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 />
===Passing VM audio to host via PulseAudio===<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|<nowiki>#user = ""</nowiki>}} line. Then add your username in the quotations. This tells QEMU which user's pulseaudio stream to route through.<br />
{{hc|/etc/libvirt/qemu.conf|<br />
user <nowiki>=</nowiki> "example"}}<br />
<br />
Next, modify the libvirt configuration<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
</devices><br />
</domain><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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 libvirt and pulseaudio (run as your user)<br />
<br />
{{hc|systemctl restart libvirtd |<br />
pulseaudio --kill<br />
pulseaudio --start<br />
}}<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 />
===Gotchas===<br />
====Passing through a device that does not support resetting====<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 functionnal 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 won't 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 />
If you have trouble configuring a certain mechanism in your setup, you might want to look up [[PCI_passthrough_via_OVMF/Examples|complete passthrough setup examples]]. A few users have described their setups and you might want to look up certain tricks from their configuration files.<br />
<br />
== Troubleshooting ==<br />
<br />
==="Error 43: Driver failed to load" on Nvidia GPUs passed to Windows VMs===<br />
{{Note|This may also fix SYSTEM_THREAD_EXCEPTION_NOT_HANDLED boot crashes related to Nvidia drivers.}}<br />
{{Note|This may also fix problems under linux guests.}}<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=whatever</nowiki>}} to the cpu parameters in their QEMU command line, or by adding the following line to their libvirt domain configuration. It may help for the ID to be set to a 12-character alphanumeric (e.g. '123456789ab') as opposed to longer or shorter strings.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<features><br />
<hyperv><br />
...<br />
<vendor_id state='on' value='whatever'/><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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><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></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 />
...</nowiki>}}<br />
<br />
===="BAR 3: can't reserve [mem]" error in dmesg after starting VM====<br />
<br />
With respect to [http://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: can't 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]] video<nowiki>=</nowiki>efifb:off is required as well. [https://pve.proxmox.com/wiki/Pci_passthrough#BAR_3:_can.27t_reserve_.5Bmem.5D_error Source]}}<br />
<br />
<br />
=== UEFI (OVMF) Compatability 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'll 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 />
# cd /sys/bus/pci/devices/0000:01:00.0/<br />
# echo 1 > rom<br />
# cat rom > /tmp/image.rom<br />
# echo 0 > rom<br />
<br />
And test it for compatibility:<br />
<br />
$ ./rom-parser /tmp/image.rom<br />
<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 />
To be UEFI compatible, you need a "type 3 (EFI)" in the result. If it's 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 />
<pre><br />
-device vfio-pci,host=07:00.0,......,romfile=/path/to/your/gpu/bios.bin \<br />
</pre><br />
<br />
And in libvirt:<br />
<pre><br />
<hostdev><br />
...<br />
<rom file='/path/to/your/gpu/bios.bin'/><br />
...<br />
</hostdev><br />
</pre><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 />
<pre><br />
./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 />
</pre><br />
<br />
And to check a given VBIOS file:<br />
<br />
<pre><br />
./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 />
</pre><br />
<br />
If the external ROM did not work as it should in the guest, you'll have to flash the newer VBIOS image to the GPU.<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 />
# rmmod nvidia_modeset nvidia <br />
<br />
Flashing the VBIOS can be done with:<br />
<br />
# ./nvflash romfile.bin<br />
<br />
'''DO NOT''' interrupt the flashing process, even if it looks like it's stuck. Flashing should take about a minute on most GPUs, but may take longer.<br />
<br />
=== Unexpected crashes related to CPU exceptions ===<br />
KVM injects a GPF when the guest tries to access unsupported MSRs. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs instead of returning an error value.<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
Cases where adding this option might help:<br />
* GeForce Experience complaining about an unsupported CPU being present<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with KMODE_EXCEPTION_NOT_HANDLED. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
=== "System Thread Exception Not Handled" when booting on a Windows VM ===<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Slowed down audio pumped through HDMI on the video card ===<br />
For some users VM's audio slows down/starts stuttering/becomes demonic after a while when it's 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 />
# lspci -vs $device | grep 'MSI:'<br />
where `$device` is the card's address (e.g. `01:00.0`).<br />
<br />
The output should be similar to:<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 [http://forums.guru3d.com/showthread.php?t=378044 here].<br />
<br />
Other hints can be found on the [http://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 [http://vfio.blogspot.it/2014/09/vfio-interrupts-and-how-to-coax-windows.html VFIO tips and tricks].<br />
<br />
Some tools named {{ic|MSI_util}} or similar are available on the Internet, but they didn't work for me on Windows 10 64bit.<br />
<br />
In order to fix the issues enabling MSI on the 0 function of my 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; I also enabled it on the other function ({{ic|01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)}}) and that seems to have fixed 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|intel_iommu<nowiki>=</nowiki>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 doesnt start after enabling vfio_pci ===<br />
<br />
This is related to the host gpu being detected as a secondary gpu, which cases X to error, when it tries to load a driver for the guest gpu. To circumvent this, a xorg conf specifying the BusID for the host gpu is necessary. The correct BusID can be acquired from lspci or the Xorg log.<br />
{{hc|10-radeon.conf|<nowiki>Section "Device"<br />
Identifier "Radeon GPU"<br />
Driver "radeon"<br />
BusID "PCI:3:0:0"<br />
EndSection</nowiki>}}<br />
[https://www.redhat.com/archives/vfio-users/2016-August/msg00025.html Source]<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 />
== See also ==<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 />
* [http://pastebin.com/rcnUZCv7 Example script from https://www.youtube.com/watch?v=37D2bRsthfI]<br />
* [http://vfio.blogspot.com/ Complete tutorial for PCI passthrough]<br />
* [https://www.redhat.com/archives/vfio-users/ VFIO users mailing list]<br />
* [https://webchat.freenode.net/?channels=vfio-users #vfio-users on freenode]<br />
* [https://www.youtube.com/watch?v=aLeWg11ZBn0 YouTube: Level1Linux - GPU Passthrough for Virtualization with Ryzen]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=489280PCI passthrough via OVMF2017-09-09T02:08:23Z<p>Slowbro: /* High DPC Latency */ more information</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:OVMF による PCI パススルー]]<br />
The Open Virtual Machine Firmware ([http://www.tianocore.org/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 [http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf presentation (pdf)]. <br />
<br />
== Prerequisites ==<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 />
** [http://ark.intel.com/Search/FeatureFilter?productType=processors&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) don't have an IOMMU, so you '''need''' to have a motherboard with a [http://support.amd.com/TechDocs/43403.pdf#page=18 890FX] or [http://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 [http://wiki.xen.org/wiki/VTdHowTo fairly comprehensive list on the matter on the Xen wiki] as well as [[wikipedia:List_of_IOMMU-supporting_hardware|another one on Wikipedia]].<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 />
IOMMU is a system specific IO mapping mechanism and can be used with most devices. IOMMU is a generic name for Intel VT-d and AMD-Vi.<br />
<br />
Before you enable IOMMU, you might have to first enable (non-IOMMU) virtualisation (Intel VT-x/"Vanderpool" or AMD-V/"Pacifica") in your BIOS settings.<br />
<br />
===Enabling IOMMU===<br />
Ensure that AMD-Vi/Intel VT-d is enabled in your 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 />
You will also have to enable iommu support in the kernel itself through a [[Kernel_parameters|bootloader kernel option]]. Depending on your type of CPU, use either {{ic|intel_iommu<nowiki>=</nowiki>on}} for Intel CPUs (VT-d) or {{ic|amd_iommu<nowiki>=</nowiki>on}} for AMD CPUs (AMD-Vi).<br />
<br />
After rebooting, check dmesg to confirm that IOMMU has been correctly enabled:<br />
{{hc|dmesg<nowiki>|</nowiki>grep -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 />
===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 d in /sys/kernel/iommu_groups/*/devices/*; do <br />
n=${d#*/iommu_groups/*}; n=${n%%/*}<br />
printf 'IOMMU Group %s ' "$n"<br />
lspci -nns "${d##*/}"<br />
done;<br />
<br />
Example output:<br />
<br />
IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)<br />
IOMMU Group 1 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)<br />
IOMMU Group 2 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)<br />
IOMMU Group 3 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev <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 />
====Plugging your guest GPU in an unisolated CPU-based PCIe slot====<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 be appear to be grouped with the device that is connected to it.<br />
<br />
IOMMU Group 1 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)<br />
IOMMU Group 1 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)<br />
IOMMU Group 1 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 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 />
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 prefered 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.}}<br />
<br />
===Using vfio-pci===<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, but it can also control devices to an extent, such as by switching them into their D3 state when they are not in use. If your system supports it, which you can try by running the following command, you should use it. If it returns an error, use pci-stub instead.<br />
<br />
{{hc|$ modinfo vfio-pci|<br />
filename: /lib/modules/4.4.5-1-ARCH/kernel/drivers/vfio/pci/vfio-pci.ko.gz<br />
description: VFIO PCI - User Level meta-driver<br />
author: Alex Williamson <alex.williamson@redhat.com><br />
...}}<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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU Group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
<br />
You can then add those vendor-device ID pairs to the default parameters passed to vfio-pci whenever it is inserted into the kernel.<br />
{{hc|1=/etc/modprobe.d/vfio.conf|2=options vfio-pci ids=10de:13c2,10de:0fbb}}<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], 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 />
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}}, {{ic|vfio_iommu_type1}}, {{ic|vfio_pci}} and {{ic|vfio_virqfd}} to [[mkinitcpio]]:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=MODULES="... vfio vfio_iommu_type1 vfio_pci vfio_virqfd ..."}}<br />
<br />
{{note|If you also have another driver loaded this way for [[Kernel_mode_setting#Early_KMS_start|early modesetting]] (such as "nouveau", "radeon", "amdgpu", "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 mkinitcpio.conf:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=HOOKS="... modconf ..."}}<br />
<br />
Since new modules have been added to the initramfs configuration, it must be regenerated. 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 />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Reboot and verify that vfio-pci has loaded properly and that it is now bound to the right devices.<br />
{{hc|$ dmesg <nowiki>|</nowiki> 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 />
It isn't necessary for all devices (or even expected device) from vfio.conf to be in dmesg output. Sometimes device doesn't 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 />
{{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 />
===Using pci-stub (legacy method, pre-4.1 kernels)===<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead, which is a dummy driver used to claim a device and prevent other drivers from using it.<br />
<br />
Pci-stub 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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
Most linux distros (including Arch Linux) have pci-stub built statically within the kernel image. If for any reason it needs to be loaded as a module in your case, you will need to bind it yourself using whatever tool your distro provides for this, such as {{ic|mkinitpcio}} for Arch.<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
<br />
If you did need to add this module to your kernel image configuration manually, you must also regenerate it.<br />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Add the relevant PCI device IDs to the {{ic|pci-stubs.ids}} [[kernel parameter]], e.g. {{ic|1=pci-stub.ids=10de:13c2,10de:0fbb}}.<br />
<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], your pci root port is part of your IOMMU group, you '''must not''' pass its ID to {{ic|pci-stub}}, as it needs to remain attached to the host to function properly. Any other device within that group, however, should be left for {{ic|pci-stub}} to bind with.}}<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
[ 2.390128] pci-stub: add 10DE:13C2 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:06:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 10DE:0FBB sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:06:00.1: claimed by stub}}<br />
<br />
==Setting up an OVMF-based guest VM==<br />
OVMF is an open-source UEFI firmware for QEMU virtual machines. While it's 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 />
[[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|<br />
<nowiki>nvram = [</nowiki><br />
"/usr/share/ovmf/ovmf_code_x64.bin:/usr/share/ovmf/ovmf_vars_x64.bin"<br />
]<br />
}}<br />
<br />
You can now [[enable]] and start {{ic|libvirtd}} and its logging component.<br />
<br />
{{bc|<br />
# systemctl enable --now libvirtd<br />
# systemctl enable virtlogd.socket}}<br />
<br />
===Setting up the guest OS===<br />
The process of setting up a VM using {{ic|virt-manager}} is mostly self explainatory, as most of the process comes with fairly comprehensive on-screen instructions. However, you should pay special attention to the following steps :<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 you have correctly specified the location of your firmware in {{ic|/etc/libvirt/qemu.conf}} and restart {{ic|libvirtd.service}}.<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.<br />
<br />
===Attaching the PCI devices===<br />
With the installation done, it's 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 />
===Gotchas===<br />
====Using a non-EFI image on an OVMF-based VM====<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 />
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 />
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. Since switching between threads adds a bit of overhead (because context switching forces the core to change its cache between operations), this can noticeably harm performance on the guest. CPU pinning aims to resolve this as it overrides process scheduling and ensures that the VM threads will always run and only run on those specific cores. Here, for instance, the guest cores 0, 1, 2 and 3 are mapped to the host cores 4, 5, 6 and 7 respectively.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune></nowiki><br />
...}}<br />
<br />
====The case of Hyper-threading====<br />
If your CPU supports hardware multitasking, also known as Hyper-threading on Intel chips, there are two ways you can go with your CPU pinning. That is, Hyper-threading is simply a very efficient way of running two threads on one CPU at any given time, so while it may give you 8 logical cores on what would otherwise be a quad-core CPU, if the physical core is overloaded, the logical core won't be of any use. One could pin their VM threads on 2 physical cores and their 2 respective threads, but any task overloading those two cores won't be helped by the extra two logical cores, since in the end you're only passing through two cores out of four, not four out of eight. What you should do knowing this depends on what you intend to do with your host while your VM is running.<br />
<br />
This is the abridged content of {{ic|/proc/cpuinfo}} on a quad-core machine with hyper-threading.<br />
{{hc|<nowiki>$ cat /proc/cpuinfo | grep -e "processor" -e "core id" -e "^$"</nowiki>|<br />
processor : 0<br />
core id : 0<br />
<br />
processor : 1<br />
core id : 1<br />
<br />
processor : 2<br />
core id : 2<br />
<br />
processor : 3<br />
core id : 3<br />
<br />
processor : 4<br />
core id : 0<br />
<br />
processor : 5<br />
core id : 1<br />
<br />
processor : 6<br />
core id : 2<br />
<br />
processor : 7<br />
core id : 3}}<br />
<br />
If you don't 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, it would probably be better to pin your VM threads across all of your logical cores, so that the VM can fully take advantage of the spare CPU time on all your cores.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='4' threads='1'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
If you would instead prefer to have the host and guest running intensive tasks at the same time, it would then be preferable to pin a limited amount of physical cores and their respective threads on the guest and leave the rest to the host to avoid the two competing for CPU time.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='3'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='2' threads='2'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
===Static huge pages===<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 accross 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 4GB of memory divided into 4kB pages (which is the default size for normal 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. This is normally handeled with transparent huge pages, which dynamically manages hugepages to keep up with the demand.<br />
<br />
On a VM with a PCI passthrough, however, it is '''not possible''' to benefit from transparent huge pages, as IOMMU requires that the guest's memory be allocated and pinned as soon as the VM starts. It is therefore required to allocate huge pages statically in order to benefit from them. <br />
<br />
{{warning|Do note that static huge pages lock down the allocated amount of memory, making it unavailable for applications that are not configured to use them. Allocating 4GBs worth of huge pages on a machine with 8GBs of memory will only leave you with 4GBs 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 comand line with {{ic|<nowiki>hugepages=x</nowiki>}}. For instance, reserving 1024 pages with {{ic|<nowiki>hugepages=1024</nowiki>}} and the default size of 2048kB per huge page creates 2GBs worth of memory for the virtual machine to use.<br />
<br />
If supported by CPU page size could be set manually. 1 GB huge page support could be verified by {{ic|<nowiki>grep pdpe1gb /proc/cpuinfo</nowiki>}}. Setting 1 GB huge page size via kernel parameters :{{ic|<nowiki>default_hugepagesz=1G hugepagesz=1G hugepages=X transparent_hugepage=never</nowiki>}}<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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<memoryBacking><br />
<hugepages/><br />
</memoryBacking><br />
...}}<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're 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 />
=== High DPC Latency ===<br />
{{Accuracy|As far as I can tell all virtio modules listed here are for virtual devices used when Linux runs as a guest. Loading them on the host serves no purpose.}}<br />
If you are experiencing high DPC and/or interrupt latency in your Guest VM, ensure you have [[Kernel_modules#Manual_module_handling|loaded the needed virtio kernel modules]] on the host kernel. Loadable virtio kernel modules include: {{ic|virtio-pci, virtio-net, virtio-blk, virtio-balloon, virtio-ring}} and {{ic|virtio}}. <br />
<br />
After loading one or more of these modules, {{ic|lsmod <nowiki>|</nowiki> grep virtio}} executed on the host should not return empty.<br />
<br />
Alternatively, make sure that you have isolated CPUs properly. Use the kernel parameters {{ic|isolcpus nohz_full rcb_nocbs}} to completely isolate the CPUs from the kernel, then run {{ic|qemu-system-x86_64}} like so:<br />
<br />
<code>sudo chrt -r 1 taskset -c <YOUR_CPU_NUMBERS> qemu-system-x86_64 ...</code><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.reddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ this reddit comment] for more info.<br />
<br />
===Improving performance on AMD CPU===<br />
<br />
{{note|Was tested on AMD Ryzen 5 1600 - helps a lot, depends on guest's applications. This slows down systems with AMD FX processors considerably, 1GB hugepages are fine however.}}<br />
<br />
Disabling Nested Page Tables(aka NPT) will improve GPU performance to a bare metal level.<br />
<br />
{{hc|1=/etc/modprobe.d/kvm_amd.conf|2=options kvm_amd npt=0}}<br />
<br />
Using [[#Static huge pages|huge pages]] for guest and bigger huge page size(e.g. 1 GB) could reduce periodical micro-freezes of whole VM introduced by disabled NPT.<br />
<br />
If periodical stuttering still occurs try removing smep feature from vCPU:<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<cpu mode='host-passthrough' check='none'><br />
...<br />
<feature policy='disable' name='smep'/><br />
...<br />
</cpu><br />
</nowiki><br />
...}}<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're 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're 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 />
{{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 />
Due to how both pci-stub and vfio-pci use 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 won't 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're using is instead assigned by pci bus address using the {{ic|driver_override}} mechanism.<br />
<br />
==== Script variants ====<br />
===== Passthrough all GPUs but the boot GPU =====<br />
Here, we will make a script to bind vfio-pci to all GPUs but the boot gpu. Create the script "/sbin/vfio-pci-override.sh":<br />
<br />
#!/bin/sh<br />
<br />
for i in /sys/devices/pci*/*/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 />
<br />
===== Passthrough selected GPU =====<br />
In this case we manually specify the GPU to bind.<br />
<br />
#!/bin/sh<br />
<br />
GROUP="0000:00:03.0"<br />
DEVS="0000:03:00.0 0000:03:00.1 ."<br />
<br />
if [ ! -z "$(ls -A /sys/class/iommu)" ]<br />
then<br />
for DEV in $DEVS; do<br />
echo "vfio-pci" > /sys/bus/pci/devices/$GROUP/$DEV/driver_override<br />
done<br />
fi<br />
<br />
modprobe -i vfio-pci<br />
<br />
==== Script installation ====<br />
Create /etc/modprobe.d/vfio.conf with the following:<br />
install vfio-pci /sbin/vfio-pci-override.sh<br />
<br />
Edit /etc/mkinitcpio.conf<br />
<br />
Remove any video drivers from MODULES, and add vfio-pci, and vfio_iommu_type1<br />
MODULES="ext4 vfat vfio-pci vfio_iommu_type1"<br />
<br />
Add "/etc/modprobe.d/vfio.conf" and "/sbin/vfio-pci-override.sh" to FILES:<br />
FILES="/etc/modprobe.d/vfio.conf /sbin/vfio-pci-override.sh"<br />
<br />
Regenerate your initramfs, and reboot:<br />
mkinitcpio -p linux<br />
<br />
=== Passing the boot GPU to the guest ===<br />
{{Expansion|Not possible at the time as far as I'm aware, but a common issue on various forums.|Talk:PCI passthrough via OVMF#Additionnal_sections}}<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's not possible, to swap the host and guest cards in the machine itself.<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 [http://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|pcie_acs_override<nowiki>=</nowiki>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|pcie_acs_override<nowiki>=</nowiki>}} 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|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/ovmf_vars_x64.bin}} to temporary location like {{ic|/tmp/my_vars.bin}} and finally specify the OVMF paths by appending the following parameters to the QEMU command:<br />
<br />
* {{ic|1=-drive if=pflash,format=raw,file=/tmp/my_vars.bin}} for the variables<br />
* {{ic|1=-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/ovmf_code_x64.bin}} for the actual OVMF firmware binary, note the readonly option<br />
<br />
{{Note|QEMU's default SeaBIOS can be used instead of OVMF, but it's not recommended as it can cause issues with passthrough setups.}}<br />
<br />
It's 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 />
===USB controller===<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 />
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 />
===Passing VM audio to host via PulseAudio===<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|<nowiki>#user = ""</nowiki>}} line. Then add your username in the quotations. This tells QEMU which user's pulseaudio stream to route through.<br />
{{hc|/etc/libvirt/qemu.conf|<br />
user <nowiki>=</nowiki> "example"}}<br />
<br />
Next, modify the libvirt configuration<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
</devices><br />
</domain><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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 libvirt and pulseaudio (run as your user)<br />
<br />
{{hc|systemctl restart libvirtd |<br />
pulseaudio --kill<br />
pulseaudio --start<br />
}}<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 />
===Gotchas===<br />
====Passing through a device that does not support resetting====<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 functionnal 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 won't 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 />
If you have trouble configuring a certain mechanism in your setup, you might want to look up [[PCI_passthrough_via_OVMF/Examples|complete passthrough setup examples]]. A few users have described their setups and you might want to look up certain tricks from their configuration files.<br />
<br />
== Troubleshooting ==<br />
<br />
==="Error 43: Driver failed to load" on Nvidia GPUs passed to Windows VMs===<br />
{{Note|This may also fix SYSTEM_THREAD_EXCEPTION_NOT_HANDLED boot crashes related to Nvidia drivers.}}<br />
{{Note|This may also fix problems under linux guests.}}<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=whatever</nowiki>}} to the cpu parameters in their QEMU command line, or by adding the following line to their libvirt domain configuration. It may help for the ID to be set to a 12-character alphanumeric (e.g. '123456789ab') as opposed to longer or shorter strings.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<features><br />
<hyperv><br />
...<br />
<vendor_id state='on' value='whatever'/><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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><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></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 />
...</nowiki>}}<br />
<br />
===="BAR 3: can't reserve [mem]" error in dmesg after starting VM====<br />
<br />
With respect to [http://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: can't 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]] video<nowiki>=</nowiki>efifb:off is required as well. [https://pve.proxmox.com/wiki/Pci_passthrough#BAR_3:_can.27t_reserve_.5Bmem.5D_error Source]}}<br />
<br />
<br />
=== UEFI (OVMF) Compatability 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'll 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 />
# cd /sys/bus/pci/devices/0000:01:00.0/<br />
# echo 1 > rom<br />
# cat rom > /tmp/image.rom<br />
# echo 0 > rom<br />
<br />
And test it for compatibility:<br />
<br />
$ ./rom-parser /tmp/image.rom<br />
<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 />
To be UEFI compatible, you need a "type 3 (EFI)" in the result. If it's 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 />
<pre><br />
-device vfio-pci,host=07:00.0,......,romfile=/path/to/your/gpu/bios.bin \<br />
</pre><br />
<br />
And in libvirt:<br />
<pre><br />
<hostdev><br />
...<br />
<rom file='/path/to/your/gpu/bios.bin'/><br />
...<br />
</hostdev><br />
</pre><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 />
<pre><br />
./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 />
</pre><br />
<br />
And to check a given VBIOS file:<br />
<br />
<pre><br />
./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 />
</pre><br />
<br />
If the external ROM did not work as it should in the guest, you'll have to flash the newer VBIOS image to the GPU.<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 />
# rmmod nvidia_modeset nvidia <br />
<br />
Flashing the VBIOS can be done with:<br />
<br />
# ./nvflash romfile.bin<br />
<br />
'''DO NOT''' interrupt the flashing process, even if it looks like it's stuck. Flashing should take about a minute on most GPUs, but may take longer.<br />
<br />
=== Unexpected crashes related to CPU exceptions ===<br />
KVM injects a GPF when the guest tries to access unsupported MSRs. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs instead of returning an error value.<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
Cases where adding this option might help:<br />
* GeForce Experience complaining about an unsupported CPU being present<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with KMODE_EXCEPTION_NOT_HANDLED. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
=== "System Thread Exception Not Handled" when booting on a Windows VM ===<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Slowed down audio pumped through HDMI on the video card ===<br />
For some users VM's audio slows down/starts stuttering/becomes demonic after a while when it's 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 />
# lspci -vs $device | grep 'MSI:'<br />
where `$device` is the card's address (e.g. `01:00.0`).<br />
<br />
The output should be similar to:<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 [http://forums.guru3d.com/showthread.php?t=378044 here].<br />
<br />
Other hints can be found on the [http://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 [http://vfio.blogspot.it/2014/09/vfio-interrupts-and-how-to-coax-windows.html VFIO tips and tricks].<br />
<br />
Some tools named {{ic|MSI_util}} or similar are available on the Internet, but they didn't work for me on Windows 10 64bit.<br />
<br />
In order to fix the issues enabling MSI on the 0 function of my 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; I also enabled it on the other function ({{ic|01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)}}) and that seems to have fixed 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|intel_iommu<nowiki>=</nowiki>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 doesnt start after enabling vfio_pci ===<br />
<br />
This is related to the host gpu being detected as a secondary gpu, which cases X to error, when it tries to load a driver for the guest gpu. To circumvent this, a xorg conf specifying the BusID for the host gpu is necessary. The correct BusID can be acquired from lspci or the Xorg log.<br />
{{hc|10-radeon.conf|<nowiki>Section "Device"<br />
Identifier "Radeon GPU"<br />
Driver "radeon"<br />
BusID "PCI:3:0:0"<br />
EndSection</nowiki>}}<br />
[https://www.redhat.com/archives/vfio-users/2016-August/msg00025.html Source]<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 />
== See also ==<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 />
* [http://pastebin.com/rcnUZCv7 Example script from https://www.youtube.com/watch?v=37D2bRsthfI]<br />
* [http://vfio.blogspot.com/ Complete tutorial for PCI passthrough]<br />
* [https://www.redhat.com/archives/vfio-users/ VFIO users mailing list]<br />
* [https://webchat.freenode.net/?channels=vfio-users #vfio-users on freenode]<br />
* [https://www.youtube.com/watch?v=aLeWg11ZBn0 YouTube: Level1Linux - GPU Passthrough for Virtualization with Ryzen]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=489279PCI passthrough via OVMF2017-09-09T02:05:34Z<p>Slowbro: /* High DPC Latency */ solution via isolcpus</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[ja:OVMF による PCI パススルー]]<br />
The Open Virtual Machine Firmware ([http://www.tianocore.org/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 [http://www.linux-kvm.org/images/b/b3/01x09b-VFIOandYou-small.pdf presentation (pdf)]. <br />
<br />
== Prerequisites ==<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 />
** [http://ark.intel.com/Search/FeatureFilter?productType=processors&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) don't have an IOMMU, so you '''need''' to have a motherboard with a [http://support.amd.com/TechDocs/43403.pdf#page=18 890FX] or [http://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 [http://wiki.xen.org/wiki/VTdHowTo fairly comprehensive list on the matter on the Xen wiki] as well as [[wikipedia:List_of_IOMMU-supporting_hardware|another one on Wikipedia]].<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 />
IOMMU is a system specific IO mapping mechanism and can be used with most devices. IOMMU is a generic name for Intel VT-d and AMD-Vi.<br />
<br />
Before you enable IOMMU, you might have to first enable (non-IOMMU) virtualisation (Intel VT-x/"Vanderpool" or AMD-V/"Pacifica") in your BIOS settings.<br />
<br />
===Enabling IOMMU===<br />
Ensure that AMD-Vi/Intel VT-d is enabled in your 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 />
You will also have to enable iommu support in the kernel itself through a [[Kernel_parameters|bootloader kernel option]]. Depending on your type of CPU, use either {{ic|intel_iommu<nowiki>=</nowiki>on}} for Intel CPUs (VT-d) or {{ic|amd_iommu<nowiki>=</nowiki>on}} for AMD CPUs (AMD-Vi).<br />
<br />
After rebooting, check dmesg to confirm that IOMMU has been correctly enabled:<br />
{{hc|dmesg<nowiki>|</nowiki>grep -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 />
===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 d in /sys/kernel/iommu_groups/*/devices/*; do <br />
n=${d#*/iommu_groups/*}; n=${n%%/*}<br />
printf 'IOMMU Group %s ' "$n"<br />
lspci -nns "${d##*/}"<br />
done;<br />
<br />
Example output:<br />
<br />
IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)<br />
IOMMU Group 1 00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)<br />
IOMMU Group 2 00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)<br />
IOMMU Group 3 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev <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 />
====Plugging your guest GPU in an unisolated CPU-based PCIe slot====<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 be appear to be grouped with the device that is connected to it.<br />
<br />
IOMMU Group 1 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)<br />
IOMMU Group 1 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2)<br />
IOMMU Group 1 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 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 />
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 prefered 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.}}<br />
<br />
===Using vfio-pci===<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, but it can also control devices to an extent, such as by switching them into their D3 state when they are not in use. If your system supports it, which you can try by running the following command, you should use it. If it returns an error, use pci-stub instead.<br />
<br />
{{hc|$ modinfo vfio-pci|<br />
filename: /lib/modules/4.4.5-1-ARCH/kernel/drivers/vfio/pci/vfio-pci.ko.gz<br />
description: VFIO PCI - User Level meta-driver<br />
author: Alex Williamson <alex.williamson@redhat.com><br />
...}}<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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU Group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
<br />
You can then add those vendor-device ID pairs to the default parameters passed to vfio-pci whenever it is inserted into the kernel.<br />
{{hc|1=/etc/modprobe.d/vfio.conf|2=options vfio-pci ids=10de:13c2,10de:0fbb}}<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], 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 />
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}}, {{ic|vfio_iommu_type1}}, {{ic|vfio_pci}} and {{ic|vfio_virqfd}} to [[mkinitcpio]]:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=MODULES="... vfio vfio_iommu_type1 vfio_pci vfio_virqfd ..."}}<br />
<br />
{{note|If you also have another driver loaded this way for [[Kernel_mode_setting#Early_KMS_start|early modesetting]] (such as "nouveau", "radeon", "amdgpu", "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 mkinitcpio.conf:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=HOOKS="... modconf ..."}}<br />
<br />
Since new modules have been added to the initramfs configuration, it must be regenerated. 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 />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Reboot and verify that vfio-pci has loaded properly and that it is now bound to the right devices.<br />
{{hc|$ dmesg <nowiki>|</nowiki> 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 />
It isn't necessary for all devices (or even expected device) from vfio.conf to be in dmesg output. Sometimes device doesn't 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 />
{{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 />
===Using pci-stub (legacy method, pre-4.1 kernels)===<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead, which is a dummy driver used to claim a device and prevent other drivers from using it.<br />
<br />
Pci-stub 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 06:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] [10de:13c2] (rev a1)<br />
IOMMU group 13 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 the [[#Using_identical_guest_and_host_GPUs|Special procedures]] section instead.}}<br />
Most linux distros (including Arch Linux) have pci-stub built statically within the kernel image. If for any reason it needs to be loaded as a module in your case, you will need to bind it yourself using whatever tool your distro provides for this, such as {{ic|mkinitpcio}} for Arch.<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
<br />
If you did need to add this module to your kernel image configuration manually, you must also regenerate it.<br />
{{bc|# mkinitcpio -p linux}}<br />
{{Note|If you are using a non-standard kernel, such as {{ic|linux-vfio}}, replace {{ic|linux}} with whichever kernel you intend to use.}}<br />
<br />
Add the relevant PCI device IDs to the {{ic|pci-stubs.ids}} [[kernel parameter]], e.g. {{ic|1=pci-stub.ids=10de:13c2,10de:0fbb}}.<br />
<br />
{{note|If, as noted [[#Plugging_your_guest_GPU_in_an_unisolated_CPU-based_PCIe_slot|here]], your pci root port is part of your IOMMU group, you '''must not''' pass its ID to {{ic|pci-stub}}, as it needs to remain attached to the host to function properly. Any other device within that group, however, should be left for {{ic|pci-stub}} to bind with.}}<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
[ 2.390128] pci-stub: add 10DE:13C2 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:06:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 10DE:0FBB sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:06:00.1: claimed by stub}}<br />
<br />
==Setting up an OVMF-based guest VM==<br />
OVMF is an open-source UEFI firmware for QEMU virtual machines. While it's 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 />
[[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|<br />
<nowiki>nvram = [</nowiki><br />
"/usr/share/ovmf/ovmf_code_x64.bin:/usr/share/ovmf/ovmf_vars_x64.bin"<br />
]<br />
}}<br />
<br />
You can now [[enable]] and start {{ic|libvirtd}} and its logging component.<br />
<br />
{{bc|<br />
# systemctl enable --now libvirtd<br />
# systemctl enable virtlogd.socket}}<br />
<br />
===Setting up the guest OS===<br />
The process of setting up a VM using {{ic|virt-manager}} is mostly self explainatory, as most of the process comes with fairly comprehensive on-screen instructions. However, you should pay special attention to the following steps :<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 you have correctly specified the location of your firmware in {{ic|/etc/libvirt/qemu.conf}} and restart {{ic|libvirtd.service}}.<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.<br />
<br />
===Attaching the PCI devices===<br />
With the installation done, it's 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 />
===Gotchas===<br />
====Using a non-EFI image on an OVMF-based VM====<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 />
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 />
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. Since switching between threads adds a bit of overhead (because context switching forces the core to change its cache between operations), this can noticeably harm performance on the guest. CPU pinning aims to resolve this as it overrides process scheduling and ensures that the VM threads will always run and only run on those specific cores. Here, for instance, the guest cores 0, 1, 2 and 3 are mapped to the host cores 4, 5, 6 and 7 respectively.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune></nowiki><br />
...}}<br />
<br />
====The case of Hyper-threading====<br />
If your CPU supports hardware multitasking, also known as Hyper-threading on Intel chips, there are two ways you can go with your CPU pinning. That is, Hyper-threading is simply a very efficient way of running two threads on one CPU at any given time, so while it may give you 8 logical cores on what would otherwise be a quad-core CPU, if the physical core is overloaded, the logical core won't be of any use. One could pin their VM threads on 2 physical cores and their 2 respective threads, but any task overloading those two cores won't be helped by the extra two logical cores, since in the end you're only passing through two cores out of four, not four out of eight. What you should do knowing this depends on what you intend to do with your host while your VM is running.<br />
<br />
This is the abridged content of {{ic|/proc/cpuinfo}} on a quad-core machine with hyper-threading.<br />
{{hc|<nowiki>$ cat /proc/cpuinfo | grep -e "processor" -e "core id" -e "^$"</nowiki>|<br />
processor : 0<br />
core id : 0<br />
<br />
processor : 1<br />
core id : 1<br />
<br />
processor : 2<br />
core id : 2<br />
<br />
processor : 3<br />
core id : 3<br />
<br />
processor : 4<br />
core id : 0<br />
<br />
processor : 5<br />
core id : 1<br />
<br />
processor : 6<br />
core id : 2<br />
<br />
processor : 7<br />
core id : 3}}<br />
<br />
If you don't 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, it would probably be better to pin your VM threads across all of your logical cores, so that the VM can fully take advantage of the spare CPU time on all your cores.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='4'/><br />
<vcpupin vcpu='1' cpuset='5'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='4' threads='1'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
If you would instead prefer to have the host and guest running intensive tasks at the same time, it would then be preferable to pin a limited amount of physical cores and their respective threads on the guest and leave the rest to the host to avoid the two competing for CPU time.<br />
<br />
On the quad-core machine mentioned above, it would look like this :<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><vcpu placement='static'>4</vcpu><br />
<cputune><br />
<vcpupin vcpu='0' cpuset='2'/><br />
<vcpupin vcpu='1' cpuset='3'/><br />
<vcpupin vcpu='2' cpuset='6'/><br />
<vcpupin vcpu='3' cpuset='7'/><br />
</cputune><br />
...<br />
<cpu mode='custom' match='exact'><br />
...<br />
<topology sockets='1' cores='2' threads='2'/><br />
...<br />
</cpu></nowiki><br />
...}}<br />
<br />
===Static huge pages===<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 accross 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 4GB of memory divided into 4kB pages (which is the default size for normal 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. This is normally handeled with transparent huge pages, which dynamically manages hugepages to keep up with the demand.<br />
<br />
On a VM with a PCI passthrough, however, it is '''not possible''' to benefit from transparent huge pages, as IOMMU requires that the guest's memory be allocated and pinned as soon as the VM starts. It is therefore required to allocate huge pages statically in order to benefit from them. <br />
<br />
{{warning|Do note that static huge pages lock down the allocated amount of memory, making it unavailable for applications that are not configured to use them. Allocating 4GBs worth of huge pages on a machine with 8GBs of memory will only leave you with 4GBs 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 comand line with {{ic|<nowiki>hugepages=x</nowiki>}}. For instance, reserving 1024 pages with {{ic|<nowiki>hugepages=1024</nowiki>}} and the default size of 2048kB per huge page creates 2GBs worth of memory for the virtual machine to use.<br />
<br />
If supported by CPU page size could be set manually. 1 GB huge page support could be verified by {{ic|<nowiki>grep pdpe1gb /proc/cpuinfo</nowiki>}}. Setting 1 GB huge page size via kernel parameters :{{ic|<nowiki>default_hugepagesz=1G hugepagesz=1G hugepages=X transparent_hugepage=never</nowiki>}}<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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<memoryBacking><br />
<hugepages/><br />
</memoryBacking><br />
...}}<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're 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 />
=== High DPC Latency ===<br />
{{Accuracy|As far as I can tell all virtio modules listed here are for virtual devices used when Linux runs as a guest. Loading them on the host serves no purpose.}}<br />
If you are experiencing high DPC and/or interrupt latency in your Guest VM, ensure you have [[Kernel_modules#Manual_module_handling|loaded the needed virtio kernel modules]] on the host kernel. Loadable virtio kernel modules include: {{ic|virtio-pci, virtio-net, virtio-blk, virtio-balloon, virtio-ring}} and {{ic|virtio}}. <br />
<br />
After loading one or more of these modules, {{ic|lsmod <nowiki>|</nowiki> grep virtio}} executed on the host should not return empty.<br />
<br />
Alternatively, make sure that you have isolated CPUs properly. Use the kernel parameters {{ic|isolcpus nohz_full rcb_nocbs}} to completely isolate the CPUs from the kernel, then run {{ic|qemu-system-x86_64}} like so:<br />
<br />
<code>sudo chrt -r 1 taskset -c <YOUR_CPU_NUMBERS> qemu-system-x86_64 ...</code><br />
<br />
See [https://www.reddit.com/r/VFIO/comments/6vgtpx/high_dpc_latency_and_audio_stuttering_on_windows/dm0sfto/ this reddit comment] for more info.<br />
<br />
===Improving performance on AMD CPU===<br />
<br />
{{note|Was tested on AMD Ryzen 5 1600 - helps a lot, depends on guest's applications. This slows down systems with AMD FX processors considerably, 1GB hugepages are fine however.}}<br />
<br />
Disabling Nested Page Tables(aka NPT) will improve GPU performance to a bare metal level.<br />
<br />
{{hc|1=/etc/modprobe.d/kvm_amd.conf|2=options kvm_amd npt=0}}<br />
<br />
Using [[#Static huge pages|huge pages]] for guest and bigger huge page size(e.g. 1 GB) could reduce periodical micro-freezes of whole VM introduced by disabled NPT.<br />
<br />
If periodical stuttering still occurs try removing smep feature from vCPU:<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<cpu mode='host-passthrough' check='none'><br />
...<br />
<feature policy='disable' name='smep'/><br />
...<br />
</cpu><br />
</nowiki><br />
...}}<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're 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're 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 />
{{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 />
Due to how both pci-stub and vfio-pci use 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 won't 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're using is instead assigned by pci bus address using the {{ic|driver_override}} mechanism.<br />
<br />
==== Script variants ====<br />
===== Passthrough all GPUs but the boot GPU =====<br />
Here, we will make a script to bind vfio-pci to all GPUs but the boot gpu. Create the script "/sbin/vfio-pci-override.sh":<br />
<br />
#!/bin/sh<br />
<br />
for i in /sys/devices/pci*/*/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 />
<br />
===== Passthrough selected GPU =====<br />
In this case we manually specify the GPU to bind.<br />
<br />
#!/bin/sh<br />
<br />
GROUP="0000:00:03.0"<br />
DEVS="0000:03:00.0 0000:03:00.1 ."<br />
<br />
if [ ! -z "$(ls -A /sys/class/iommu)" ]<br />
then<br />
for DEV in $DEVS; do<br />
echo "vfio-pci" > /sys/bus/pci/devices/$GROUP/$DEV/driver_override<br />
done<br />
fi<br />
<br />
modprobe -i vfio-pci<br />
<br />
==== Script installation ====<br />
Create /etc/modprobe.d/vfio.conf with the following:<br />
install vfio-pci /sbin/vfio-pci-override.sh<br />
<br />
Edit /etc/mkinitcpio.conf<br />
<br />
Remove any video drivers from MODULES, and add vfio-pci, and vfio_iommu_type1<br />
MODULES="ext4 vfat vfio-pci vfio_iommu_type1"<br />
<br />
Add "/etc/modprobe.d/vfio.conf" and "/sbin/vfio-pci-override.sh" to FILES:<br />
FILES="/etc/modprobe.d/vfio.conf /sbin/vfio-pci-override.sh"<br />
<br />
Regenerate your initramfs, and reboot:<br />
mkinitcpio -p linux<br />
<br />
=== Passing the boot GPU to the guest ===<br />
{{Expansion|Not possible at the time as far as I'm aware, but a common issue on various forums.|Talk:PCI passthrough via OVMF#Additionnal_sections}}<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's not possible, to swap the host and guest cards in the machine itself.<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 [http://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|pcie_acs_override<nowiki>=</nowiki>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|pcie_acs_override<nowiki>=</nowiki>}} 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|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/ovmf_vars_x64.bin}} to temporary location like {{ic|/tmp/my_vars.bin}} and finally specify the OVMF paths by appending the following parameters to the QEMU command:<br />
<br />
* {{ic|1=-drive if=pflash,format=raw,file=/tmp/my_vars.bin}} for the variables<br />
* {{ic|1=-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/ovmf_code_x64.bin}} for the actual OVMF firmware binary, note the readonly option<br />
<br />
{{Note|QEMU's default SeaBIOS can be used instead of OVMF, but it's not recommended as it can cause issues with passthrough setups.}}<br />
<br />
It's 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 />
===USB controller===<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 />
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 />
===Passing VM audio to host via PulseAudio===<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|<nowiki>#user = ""</nowiki>}} line. Then add your username in the quotations. This tells QEMU which user's pulseaudio stream to route through.<br />
{{hc|/etc/libvirt/qemu.conf|<br />
user <nowiki>=</nowiki> "example"}}<br />
<br />
Next, modify the libvirt configuration<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
<domain type<nowiki>=</nowiki>'kvm'><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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|EDITOR<nowiki>=</nowiki>nano virsh edit [vmname]|<br />
</devices><br />
</domain><br />
}}<br />
<br />
to<br />
<br />
{{hc|EDITOR<nowiki>=</nowiki>nano 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 libvirt and pulseaudio (run as your user)<br />
<br />
{{hc|systemctl restart libvirtd |<br />
pulseaudio --kill<br />
pulseaudio --start<br />
}}<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 />
===Gotchas===<br />
====Passing through a device that does not support resetting====<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 functionnal 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 won't 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 />
If you have trouble configuring a certain mechanism in your setup, you might want to look up [[PCI_passthrough_via_OVMF/Examples|complete passthrough setup examples]]. A few users have described their setups and you might want to look up certain tricks from their configuration files.<br />
<br />
== Troubleshooting ==<br />
<br />
==="Error 43: Driver failed to load" on Nvidia GPUs passed to Windows VMs===<br />
{{Note|This may also fix SYSTEM_THREAD_EXCEPTION_NOT_HANDLED boot crashes related to Nvidia drivers.}}<br />
{{Note|This may also fix problems under linux guests.}}<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=whatever</nowiki>}} to the cpu parameters in their QEMU command line, or by adding the following line to their libvirt domain configuration. It may help for the ID to be set to a 12-character alphanumeric (e.g. '123456789ab') as opposed to longer or shorter strings.<br />
<br />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><br />
<features><br />
<hyperv><br />
...<br />
<vendor_id state='on' value='whatever'/><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 />
{{hc|<nowiki>EDITOR=nano virsh edit [vmname]</nowiki>|...<br />
<nowiki><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></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 />
...</nowiki>}}<br />
<br />
===="BAR 3: can't reserve [mem]" error in dmesg after starting VM====<br />
<br />
With respect to [http://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: can't 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]] video<nowiki>=</nowiki>efifb:off is required as well. [https://pve.proxmox.com/wiki/Pci_passthrough#BAR_3:_can.27t_reserve_.5Bmem.5D_error Source]}}<br />
<br />
<br />
=== UEFI (OVMF) Compatability 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'll 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 />
# cd /sys/bus/pci/devices/0000:01:00.0/<br />
# echo 1 > rom<br />
# cat rom > /tmp/image.rom<br />
# echo 0 > rom<br />
<br />
And test it for compatibility:<br />
<br />
$ ./rom-parser /tmp/image.rom<br />
<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 />
To be UEFI compatible, you need a "type 3 (EFI)" in the result. If it's 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 />
<pre><br />
-device vfio-pci,host=07:00.0,......,romfile=/path/to/your/gpu/bios.bin \<br />
</pre><br />
<br />
And in libvirt:<br />
<pre><br />
<hostdev><br />
...<br />
<rom file='/path/to/your/gpu/bios.bin'/><br />
...<br />
</hostdev><br />
</pre><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 />
<pre><br />
./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 />
</pre><br />
<br />
And to check a given VBIOS file:<br />
<br />
<pre><br />
./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 />
</pre><br />
<br />
If the external ROM did not work as it should in the guest, you'll have to flash the newer VBIOS image to the GPU.<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 />
# rmmod nvidia_modeset nvidia <br />
<br />
Flashing the VBIOS can be done with:<br />
<br />
# ./nvflash romfile.bin<br />
<br />
'''DO NOT''' interrupt the flashing process, even if it looks like it's stuck. Flashing should take about a minute on most GPUs, but may take longer.<br />
<br />
=== Unexpected crashes related to CPU exceptions ===<br />
KVM injects a GPF when the guest tries to access unsupported MSRs. A number of those issues can be solved by passing the {{ic|1=ignore_msrs=1}} option to the KVM module, which will ignore unimplemented MSRs instead of returning an error value.<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
Cases where adding this option might help:<br />
* GeForce Experience complaining about an unsupported CPU being present<br />
* StarCraft 2 and L.A. Noire reliably blue-screening Windows 10 with KMODE_EXCEPTION_NOT_HANDLED. The blue screen information does not identify a driver file in these cases.<br />
<br />
{{Warning|While this is normally safe and some applications might not work without this, silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<br />
<br />
=== "System Thread Exception Not Handled" when booting on a Windows VM ===<br />
Windows 8 or Windows 10 guests may raise a generic compatibility exception at boot, namely "System Thread Exception Not Handled", which tends to be caused by legacy drivers acting strangely on real machines. On KVM machines this issue can generally be solved by setting the CPU model to {{ic|core2duo}}.<br />
<br />
=== Slowed down audio pumped through HDMI on the video card ===<br />
For some users VM's audio slows down/starts stuttering/becomes demonic after a while when it's 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 />
# lspci -vs $device | grep 'MSI:'<br />
where `$device` is the card's address (e.g. `01:00.0`).<br />
<br />
The output should be similar to:<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 [http://forums.guru3d.com/showthread.php?t=378044 here].<br />
<br />
Other hints can be found on the [http://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 [http://vfio.blogspot.it/2014/09/vfio-interrupts-and-how-to-coax-windows.html VFIO tips and tricks].<br />
<br />
Some tools named {{ic|MSI_util}} or similar are available on the Internet, but they didn't work for me on Windows 10 64bit.<br />
<br />
In order to fix the issues enabling MSI on the 0 function of my 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; I also enabled it on the other function ({{ic|01:00.1 Audio device: NVIDIA Corporation Device 0fba (rev a1)}}) and that seems to have fixed 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|intel_iommu<nowiki>=</nowiki>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 doesnt start after enabling vfio_pci ===<br />
<br />
This is related to the host gpu being detected as a secondary gpu, which cases X to error, when it tries to load a driver for the guest gpu. To circumvent this, a xorg conf specifying the BusID for the host gpu is necessary. The correct BusID can be acquired from lspci or the Xorg log.<br />
{{hc|10-radeon.conf|<nowiki>Section "Device"<br />
Identifier "Radeon GPU"<br />
Driver "radeon"<br />
BusID "PCI:3:0:0"<br />
EndSection</nowiki>}}<br />
[https://www.redhat.com/archives/vfio-users/2016-August/msg00025.html Source]<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 />
== See also ==<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 />
* [http://pastebin.com/rcnUZCv7 Example script from https://www.youtube.com/watch?v=37D2bRsthfI]<br />
* [http://vfio.blogspot.com/ Complete tutorial for PCI passthrough]<br />
* [https://www.redhat.com/archives/vfio-users/ VFIO users mailing list]<br />
* [https://webchat.freenode.net/?channels=vfio-users #vfio-users on freenode]<br />
* [https://www.youtube.com/watch?v=aLeWg11ZBn0 YouTube: Level1Linux - GPU Passthrough for Virtualization with Ryzen]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=481138Blizzard App2017-07-02T17:13:12Z<p>Slowbro: formatting fix</p>
<hr />
<div>[[Category:Gaming]]<br />
[[ja:Battle.net]]<br />
The Battle.net client is a tool to download, update and launch games by Blizzard Entertainment. It is not officially available for Linux, but usable through [[Wine]].<br />
<br />
== Installation ==<br />
<br />
You need to install [[wine]], {{Pkg|winetricks}}, {{Pkg|lib32-gnutls}}, and {{Pkg|lib32-libldap}}<br />
<br />
From winetricks, install:<br />
<br />
$ winetricks corefonts<br />
<br />
== Known issues ==<br />
<br />
=== Crash after login/no 'Login' buttons ===<br />
If the launcher crashes after logging in, and/or you are missing the 'Log in to Blizzard' and 'Log in with Facebook' buttons, try running {{ic|winecfg}} and changing your Windows Version to Windows XP.<br />
<br />
=== Login region select ===<br />
When logging in, you must move the mouse over where the dropdown would be for 'Region Select' - otherwise it does not show up.<br />
<br />
=== White flashing ===<br />
The client often flashes when the window is moved, or other windows are moved over it. This should not affect the running of the app.<br />
<br />
=== Login screen stuck at loading spinner (input fields disabled/greyed out)===<br />
<br />
There are two possible causes for this:<br />
# Missing {{Pkg|lib32-gnutls}} (cannot connect due to no HTTPS)<br />
# Battle.net's "Browser Acceleration" has been enabled<br />
<br />
To fix #1, install lib32-gnutls package. If wine still complains about it not being found, you may need to remove <code>.wine</code> folder and restart the whole installtion process (if you do this, remember to rerun {{ic|winetricks corefonts}} to install the runtime files.<br />
<br />
To fix #2, disconnect from the internet and relaunch Battle.net Launcher. The email/password field should now be enabled and you can click the little gear icon beside the fields to configure options. Go to 'Advanced' and disable browser acceleration.<br />
<br />
== See also ==<br />
[https://appdb.winehq.org/objectManager.php?iId=28855&sClass=version Battle.net App (WineHQ AppDB)]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=481137Blizzard App2017-07-02T17:12:13Z<p>Slowbro: Remove unused section. Also, the Windows XP selection is still required for me, so I am re-adding it in 'Known Issues'</p>
<hr />
<div>[[Category:Gaming]]<br />
[[ja:Battle.net]]<br />
The Battle.net client is a tool to download, update and launch games by Blizzard Entertainment. It is not officially available for Linux, but usable through [[Wine]].<br />
<br />
== Installation ==<br />
<br />
You need to install [[wine]], {{Pkg|winetricks}}, {{Pkg|lib32-gnutls}}, and {{Pkg|lib32-libldap}}<br />
<br />
From winetricks, install:<br />
<br />
$ winetricks corefonts<br />
<br />
== Known issues ==<br />
<br />
=== Crash after login/no 'Login' buttons ===<br />
If the launcher crashes after logging in, and/or you are missing the 'Log in to Blizzard' and 'Log in with Facebook' buttons, try running {{winecfg}} and changing your Windows Version to Windows XP.<br />
<br />
=== Login region select ===<br />
When logging in, you must move the mouse over where the dropdown would be for 'Region Select' - otherwise it does not show up.<br />
<br />
=== White flashing ===<br />
The client often flashes when the window is moved, or other windows are moved over it. This should not affect the running of the app.<br />
<br />
=== Login screen stuck at loading spinner (input fields disabled/greyed out)===<br />
<br />
There are two possible causes for this:<br />
# Missing {{Pkg|lib32-gnutls}} (cannot connect due to no HTTPS)<br />
# Battle.net's "Browser Acceleration" has been enabled<br />
<br />
To fix #1, install lib32-gnutls package. If wine still complains about it not being found, you may need to remove <code>.wine</code> folder and restart the whole installtion process (if you do this, remember to rerun {{ic|winetricks corefonts}} to install the runtime files.<br />
<br />
To fix #2, disconnect from the internet and relaunch Battle.net Launcher. The email/password field should now be enabled and you can click the little gear icon beside the fields to configure options. Go to 'Advanced' and disable browser acceleration.<br />
<br />
== See also ==<br />
[https://appdb.winehq.org/objectManager.php?iId=28855&sClass=version Battle.net App (WineHQ AppDB)]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468597Lenovo ThinkPad X2202017-02-19T23:24:38Z<p>Slowbro: Better title</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-form-factor laptop with Intel Mobile i5/i7 CPU, and Intel graphics. It has no optical drive. You can see full specs at [http://www.thinkwiki.org/wiki/Category:X220 ThinkWiki].<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails (UEFI/GPT)===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
Additional considerations from ThinkWiki:<br />
* The X220 cannot/will not boot GPT disks using Legacy BIOS, you must setup UEFI.<br />
* The X220 will not boot /efi/*/*.efi unless "signed"(?) into BIOS, you have to copy it to /efi/boot/bootx64.efi.<br />
* Disabling the BIOS setting "USB UEFI BIOS Support" disables *all* USB booting, ie, both UEFI and legacy BIOS.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468596Lenovo ThinkPad X2202017-02-19T23:23:46Z<p>Slowbro: fixing up formatting</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-form-factor laptop with Intel Mobile i5/i7 CPU, and Intel graphics. It has no optical drive. You can see full specs at [http://www.thinkwiki.org/wiki/Category:X220 ThinkWiki].<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails (GPT)===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
Additional considerations from ThinkWiki:<br />
* The X220 cannot/will not boot GPT disks using Legacy BIOS, you must setup UEFI.<br />
* The X220 will not boot /efi/*/*.efi unless "signed"(?) into BIOS, you have to copy it to /efi/boot/bootx64.efi.<br />
* Disabling the BIOS setting "USB UEFI BIOS Support" disables *all* USB booting, ie, both UEFI and legacy BIOS.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468595Lenovo ThinkPad X2202017-02-19T23:23:08Z<p>Slowbro: Issues: Expand GPT issues section</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-form-factor laptop with Intel Mobile i5/i7 CPU, and Intel graphics. It has no optical drive. You can see full specs at [http://www.thinkwiki.org/wiki/Category:X220 ThinkWiki].<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails (GPT)===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
Additional considerations from ThinkWiki:<br />
<br />
On booting:<br />
* The X220 cannot/will not boot GPT disks using Legacy BIOS, you must setup UEFI.<br />
* The X220 will not boot /efi/*/*.efi unless "signed"(?) into BIOS, you have to copy it to /efi/boot/bootx64.efi.<br />
* Disabling the BIOS setting "USB UEFI BIOS Support" disables *all* USB booting, ie, both UEFI and legacy BIOS.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468594Lenovo ThinkPad X2202017-02-19T23:14:39Z<p>Slowbro: expanded top summary</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-form-factor laptop with Intel Mobile i5/i7 CPU, and Intel graphics. It has no optical drive. You can see full specs at [http://www.thinkwiki.org/wiki/Category:X220 ThinkWiki].<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails ===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468593Lenovo ThinkPad X2202017-02-19T23:11:12Z<p>Slowbro: typo</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-form-factor laptop.<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails ===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_X220&diff=468592Lenovo ThinkPad X2202017-02-19T23:10:49Z<p>Slowbro: add top summary</p>
<hr />
<div>[[Category:Lenovo]]<br />
[[ja:Lenovo ThinkPad X220]]<br />
The Lenovo ThinkPad X220 is a small-formfactor laptop.<br />
<br />
== Setup ==<br />
=== Battery ===<br />
Battery functions like charging thresholds can be controlled using the script {{AUR|tpacpi-bat}} together with the kernel module {{AUR|acpi_call-git}}{{Broken package link|{{aur-mirror|acpi_call-git}}}}. The [[TLP]] power saving tool supports using acpi_call as backend for setting the thresholds as well.<br />
<br />
=== Fingerprint reader ===<br />
The Upek fingerprint reader is supported by [[Fingerprint-gui]].<br />
<br />
=== Graphics ===<br />
The graphics driver is provided by the {{pkg|xf86-video-intel}} package from the [[Official repositories]].<br />
<br />
=== Trackpoint and Clickpad ===<br />
<br />
See [[TrackPoint]].<br />
<br />
== Issues ==<br />
=== Boot fails ===<br />
The laptop can not boot from a GPT disk in legacy BIOS mode, it is necessary to either switch to UEFI booting or create a MBR Partition Table.<br />
<br />
=== Reboot loop after resume from suspend ===<br />
This can be caused by the EFI storage getting too full. Run the following commands as root to free up some space.<br />
<br />
# First clear the pstore<br />
mkdir -p /dev/pstore<br />
mount -t pstore pstore /dev/pstore<br />
ls /dev/pstore # <- Nothing important should be here, but check first anyway<br />
rm /dev/pstore/*<br />
<br />
# Next some EFI variables. These are used/created by pstore, but I've had them even though <br />
#I deleted the pstore data using the above commands. YMMV.<br />
rm /sys/firmware/efi/efivars/dump-type0-*<br />
<br />
This information was taken from [http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/x220-does-not-resume-from-sleep/m-p/1083233/highlight/false#M48825 the Lenovo forums]<br />
<br />
=== Microphone ===<br />
<br />
The x220 internal microphone has been the source of many complaints across platforms. Specifically, it can generate a lot of static or hissing on top of any recorded audio. The workaround is to mute the right mic input channel (in audio control programs that allow independent channel setting) or to drag the balance slider in a GUI for the internal mic level fully to the left.<br />
<br />
Note also that the audio jack is a combination headset/mic jack and will work with modern smartphone headsets with inline microphones, as an alternative.<br />
<br />
=== Backlight ===<br />
<br />
Since {{ic|linux 3.16}}, some backlight-related kernel parameter defaults have been changed, causing the hardware brightness up/down keys to no longer function automatically. This can be worked around by setting {{ic|acpi_osi}}, e.g.<br />
acpi_osi="!Windows 2012"<br />
in the [[kernel parameters]]. More details can be found on [[Backlight#Kernel_command-line_options|the Backlight page]].<br />
<br />
==See also==<br />
* Arch user blogs about the X220 <br />
** [http://natalian.org/archives/2011/11/10/Thinkpad_X220/ Thinkpad X220 model 4287CTO] using a msata SSD for 64 bit Archlinux<br />
** [http://blog.jamiek.it/2011/10/arch-linux-on-thinkpad-x220.html X220 i5]<br />
* [http://www.thinkwiki.org/wiki/Category:X220 Thinkwiki X220 reference]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=129885 "Arch By Hand" UEFI GPT SSD LUKS Install Script], built on an x220 tablet with an SSD.<br />
* [http://forum.notebookreview.com/lenovo-ibm/575569-linux-x220-29.html#post8075286 Power saving options for the X220 - Notebook Review Forum]<br />
* {{aur|thinkpad-scripts}} for ThinkPad X220 Tablet rotation, docking, etc scripts</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=458370Laptop/Lenovo2016-12-04T04:11:14Z<p>Slowbro: Add Yoga Series, Move P series to be in alphabetical order, fix extra table cells.</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || <br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || <br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || <br />
|-<br />
| Lenovo ThinkPad Edge E540 || 2015.08.01 || Yes || Yes || Yes || Yes || Yes || Yes* || NA || SD card (yes), Finger Print (yes), touch pad and trackpoint (yes), Webcam (yes) || <br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== P series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad P50]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
| [[Lenovo ThinkPad P70]] || 2016.04 || Yes || Yes || Yes || Yes || Yes || Suspend working, hibernate not tested || NA || SD card (Yes), Webcam (Yes), Fingerprint Reader (No), || Wifi requires Kernel 4.3.3+ <br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad T410 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card reader tested, no Fingerprint scanner||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[Lenovo ThinkPad T430]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| [[Lenovo ThinkPad T440s]] || Yes || Yes || Yes || Yes || Yes* || ? || Yes || ? || || See wiki page for more details about wireless<br />
|-<br />
| [[Lenovo ThinkPad T450s]] || 2015.10.01 || Yes || Yes || Yes || Yes || Yes || ? || NA || SD Card reader; fingerprint scanner|| <br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
|}<br />
<br />
==== W series ====<br />
{{HCL/Laptops table header}}<br />
|-<br />
| Lenovo ThinkPad W550s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Not tested), Webcam (Yes), Fingeprint Reader (Yes) ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD slot ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad X220]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon]] || NA || Yes || Yes || Yes || Yes || Proprietary/nonfree || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 2)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 3)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X1 Carbon (Gen 4)]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
==== Yoga Series ====<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo Thinkpad Yoga 260]] || USB || Yes || Yes || Yes || Yes || Yes || Unknown || N/A || SD card (Yes), Webcam (Yes), Fingerprint Reader (Unknown), Touchscreen (Yes), Tablet (Partial), Accelerometer (No) || Wifi requires Kernel 4.3.3+<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad U430p || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| Lenovo IdeaPad Y700 || 2015.12.01 || Yes || Yes || Yes || Yes || Yes || Not tested || NA || || [https://bugzilla.kernel.org/show_bug.cgi?id=151681 Trackpad requires pata_legacy to be blacklisted]<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
| Lenovo B50-70 || Yes || Yes* ||Yes || Yes || Yes || Yes || Not tested || NA || See below* ||<br />
|-<br />
| Lenovo B450 || Yes || Yes ||Yes || Yes || Yes || NA || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== K series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo K450e || NA || Yes || Yes || Yes || Yes || Not tested || Yes || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
=== U Series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo U31-70 || 2015.10.01 || Yes || Yes || Yes || Yes* || Yes || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (Yes), Touchpad (Yes), Webcam (Yes) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
{{Accuracy|Lots of vague or unproven bugs/workarounds, poor writing}}<br />
<br />
=== Lenovo U31-70 ===<br />
Wireless needs {{Pkg|linux}} >= 4.3 and latest {{Pkg|linux-firmware}}, both packages are currently in testing. Copy one of the firmware blobs {{ic|eeprom_ar6320_2p1_NFA345i.bin}} or {{ic|eeprom_ar6320_2p1_NFA345i_highTX.bin}} from the windows driver to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-pci-168c:0041:17aa:3545.bin}}.<br />
<br />
Wireless with firmware blobs from windows driver may no longer work on {{Pkg|linux}} >= 4.4. Download firmware blob https://github.com/kvalo/ath10k-firmware/blob/f428f53b36b144971c9c4c3d2ebd5fa8cae86c89/QCA6174/hw2.1/board-2.bin and copy it to {{ic|/usr/lib/firmware/ath10k/QCA6174/hw2.1/board-2.bin}}. Tested with {{Pkg|linux}} 4.4.5-1 and {{Pkg|linux-firmware}} 20160113.40e9ae8-1nu<br />
<br />
With packages {{Pkg|linux}} 4.6.1-2 and {{Pkg|linux-firmware}} 20160516.80d463b-1 being in stable, wireless works without any additional steps needed.<br />
<br />
=== Lenovo B50-70 ===<br />
* UEFI:<br />
** to be able to disable Secure Boot (necessary for dual boot, not needed for Linux only), you have to switch from "UEFI first" to "UEFI only" (or something like this) in UEFI setup menu; the Secure Boot option appears then on the Security tab<br />
** after UEFI update having Linux and Windows installed, the Linux bootloader ceased to be the default one, UEFI started to load Windows by default and it was impossible to select the Linux one in the UEFI boot menu and in the UEFI setup - reinstalling the bootloader helped; having no access to a boot media that supports UEFI, a solution might be also replacing the Windows EFI bootloader file with a Linux one temporalily, in order to be able to boot Linux from HDD<br />
** for the UEFI update, a Windows OS is needed<br />
* Touchpad:<br />
** Synaptics - works after installing Synaptics drivers from repo, possible to change behaviour (like reaction for double tap) according to your wish<br />
* Video:<br />
** in laptops with dual video card (Intel and ATI) - detects both, Intel is active as a default, not checked if it's possible at all to switch between them<br />
<br />
==== Operation with a HDD caddy ====<br />
When you install an SSD in the place of the plate HDD drive and you want to have your HDD still inside the laptop, it is possible to install it in the place of the optical drive in a special "HDD caddy". The optical drive is of 9 mm height, but a 9,5 mm caddy (ultra slim) fits in the slot. A caddy with a SATA interface is needed. It is difficult to separate the front bezel from the original optical drive (and opening its case does not help, but brings a danger of making a mess in the opening mechanism; the only option is just to pull the bezel using a bit of force, but you risk breaking the latches).<br />
<br />
While the HDD installed instead of the optical drive operates flawlessly in Windows, it wasn't going to work out of the box in Linux, at least in one case. The kernel tries to establish a connection with the disk, but fails to do it (''SATA link down'' entry in /var/log/messages). The solution is to force a 1.5 Gbps transfer speed (instead of 6 Gbps) by adding a ''libata.force='' kernel parameter. See [https://www.kernel.org/doc/Documentation/kernel-parameters.txt] for details.<br />
<br />
=== Lenovo K450e ===<br />
<br />
After installing Arch Linux and booting, a single beep may be heard. To disable this beep, press F1 during startup, then change Boot Priority to 'UEFI First', as well as enabling 'CSM'.<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T430 ===<br />
<br />
* Bluetooth (0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0 [ThinkPad]) appears to be functional, even during standby or hibernation.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using older versions of synclient makes the trackpoint essentially unusable. This has been resolved in newer versions of {{Pkg|xf86-input-synaptics}}.<br />
** See [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] and [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version].<br />
** Install {{AUR|xf86-input-synlx40}}{{Broken package link|{{aur-mirror|xf86-input-synlx40}}}} and {{AUR|xf86-input-mtrack}} for alternative drivers.<br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** As the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Muting the speaker output improves bass output on the headset port.<br />
** If the system fails to wake from sleep, it can lose sync with the internal audio card and speakers/headphones may fail to work. In this case, put the system to sleep, and wake it again and audio functionality should be restored. <br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control does not seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[Hardware video acceleration]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl-dkms}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/f4550c211ca7809ecf926f8074c7b7250a74bd92 kernel recipe patch]). The current 4.3 kernel includes these patches. You will also need to install the xf86_64-input-synaptics package([https://www.archlinux.org/packages/?name=xf86-input-synaptics]) <br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== ThinkPad Edge E420s Delay with Space Bar====<br />
Solution: Update BIOS (at least 1.08).<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=429955Blizzard App2016-04-06T23:40:38Z<p>Slowbro: </p>
<hr />
<div>[[Category:Gaming]]<br />
{{Expansion|This page is a work in progress...}}<br />
<br />
== Installation ==<br />
<br />
=== Packages ===<br />
You need to install [[wine]], {{Pkg|winetricks}}, and {{Pkg|lib32-libldap}}<br />
<br />
From winetricks, install:<br />
<br />
$ winetricks corefonts vcrun2005 vcrun2008<br />
<br />
== Wine Config ==<br />
<br />
The Battle.net client must be ran as Windows Version 'Windows XP'. Other versions will result in the client being a blank white window.<br />
<br />
== Known Issues ==<br />
<br />
=== Login Region Select ===<br />
When logging in, you must move the mouse over where the dropdown would be for 'Region Select' - otherwise it does not show up.<br />
<br />
=== White Flashing ===<br />
The client often flashes when the window is moved, or other windows are moved over it. This should not affect the running of the app.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=429954Blizzard App2016-04-06T23:40:25Z<p>Slowbro: </p>
<hr />
<div>[[Category:Gaming]]<br />
{{Expansion|This page is a work in progress...}}<br />
<br />
== Installation ==<br />
<br />
=== Packages ===<br />
You need to install [[wine]], {{Pkg|winetricks}}, and {{Pkg|lib32-libldap}}<br />
<br />
From winetricks, install:<br />
<br />
$ winetricks corefonts vcrun2005 vcrun2008<br />
<br />
== Wine Config ===<br />
<br />
The Battle.net client must be ran as Windows Version 'Windows XP'. Other versions will result in the client being a blank white window.<br />
<br />
== Known Issues ==<br />
<br />
=== Login Region Select ===<br />
When logging in, you must move the mouse over where the dropdown would be for 'Region Select' - otherwise it does not show up.<br />
<br />
=== White Flashing ===<br />
The client often flashes when the window is moved, or other windows are moved over it. This should not affect the running of the app.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=427853Blizzard App2016-03-26T01:11:06Z<p>Slowbro: </p>
<hr />
<div>Note: this page is a work in progress.<br />
<br />
== Installation ==<br />
<br />
=== Packages ===<br />
You need to install [[wine]], {{Pkg|winetricks}}, {{Pkg|lib32-libldap}}, <br />
<br />
From winetricks:<br />
<br />
$ winetricks corefonts vcrun2005 vcrun2008</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=427852Blizzard App2016-03-26T01:06:24Z<p>Slowbro: </p>
<hr />
<div>== Installation ==<br />
<br />
=== Packages ===<br />
You need to install [[wine]], {{Pkg|winetricks}}, {{Pkg|lib32-libldap}}, <br />
<br />
From winetricks:<br />
<br />
$ winetricks corefonts vcrun2005 vcrun2008</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Blizzard_App&diff=427851Blizzard App2016-03-26T01:04:06Z<p>Slowbro: work in progress</p>
<hr />
<div>## Installation ##<br />
<br />
You need to install [[wine]], {{Pkg|winetricks}}, {{Pkg|lib32-libldap}}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=User:Slowbro/Dell_Latitude_E5540&diff=426389User:Slowbro/Dell Latitude E55402016-03-18T21:53:58Z<p>Slowbro: </p>
<hr />
<div>[[Category:Dell]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Dell}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
== lspci ==<br />
<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)<br />
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)<br />
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)<br />
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)<br />
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)<br />
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)<br />
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)<br />
00:1c.5 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)<br />
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)<br />
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)<br />
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)<br />
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)<br />
03:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev a1)<br />
</pre><br />
<br />
==Configuration==<br />
<br />
WIP<br />
<br />
== Issues ==<br />
<br />
No issues to report yet.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=User:Slowbro/Dell_Latitude_E5540&diff=426388User:Slowbro/Dell Latitude E55402016-03-18T21:53:25Z<p>Slowbro: </p>
<hr />
<div>[[Category:Dell]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Dell}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
== lspci ==<br />
<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)<br />
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)<br />
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)<br />
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)<br />
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)<br />
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)<br />
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)<br />
00:1c.5 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)<br />
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)<br />
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)<br />
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)<br />
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)<br />
03:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev a1)<br />
</pre></div>Slowbrohttps://wiki.archlinux.org/index.php?title=User:Slowbro/Dell_Latitude_E5540&diff=426387User:Slowbro/Dell Latitude E55402016-03-18T21:52:52Z<p>Slowbro: /* lspci */</p>
<hr />
<div>==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
== lspci ==<br />
<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)<br />
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)<br />
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)<br />
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)<br />
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)<br />
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)<br />
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)<br />
00:1c.5 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)<br />
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)<br />
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)<br />
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)<br />
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)<br />
03:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev a1)<br />
</pre></div>Slowbrohttps://wiki.archlinux.org/index.php?title=User:Slowbro/Dell_Latitude_E5540&diff=426386User:Slowbro/Dell Latitude E55402016-03-18T21:50:32Z<p>Slowbro: Created page with "== lspci == <pre> 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b) 00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Grap..."</p>
<hr />
<div>== lspci ==<br />
<br />
<pre><br />
00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 0b)<br />
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 0b)<br />
00:03.0 Audio device: Intel Corporation Haswell-ULT HD Audio Controller (rev 0b)<br />
00:14.0 USB controller: Intel Corporation 8 Series USB xHCI HC (rev 04)<br />
00:16.0 Communication controller: Intel Corporation 8 Series HECI #0 (rev 04)<br />
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I218-LM (rev 04)<br />
00:1b.0 Audio device: Intel Corporation 8 Series HD Audio Controller (rev 04)<br />
00:1c.0 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 1 (rev e4)<br />
00:1c.3 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 4 (rev e4)<br />
00:1c.4 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 5 (rev e4)<br />
00:1c.5 PCI bridge: Intel Corporation 8 Series PCI Express Root Port 6 (rev e4)<br />
00:1d.0 USB controller: Intel Corporation 8 Series USB EHCI #1 (rev 04)<br />
00:1f.0 ISA bridge: Intel Corporation 8 Series LPC Controller (rev 04)<br />
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)<br />
00:1f.3 SMBus: Intel Corporation 8 Series SMBus Controller (rev 04)<br />
01:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader Controller (rev 01)<br />
02:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01)<br />
03:00.0 3D controller: NVIDIA Corporation GF117M [GeForce 610M/710M/810M/820M / GT 620M/625M/630M/720M] (rev a1)<br />
</pre></div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=426385Laptop/Dell2016-03-18T21:49:15Z<p>Slowbro: /* Latitude */</p>
<hr />
<div>[[Category:Dell]]<br />
{{Laptops navigation}}<br />
<br><br />
== Inspiron ==<br />
{{HCL/Laptops table header}}<br />
| Inspiron 1300 || Don't Panic (Core Dump version) || 3D with {{Pkg|xf86-video-intel}} || Intel || ''b44'' module works out-of-the-box || BCM4318-based card, works with [[ndiswrapper]] || N/A || Untested || Untested || -- || Everything works out-of-the-box except wireless and sometimes screen resolution<br />
|- <br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{AUR|broadcom-wl}} needed from the AUR || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || Both hibernate and suspend-to-RAM and works with [[pm-utils]] || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ([[AUR]] {{AUR|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS; media keys configured with KeyTouch. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| [[Dell Inspiron 1564|Inspiron 1564]] || Core Dump || 3D with either [[Catalyst]] or [[ATI|xf86-video-ati]]; both work flawlessly. || Intel HD Audio with ALSA || Realtek RTL8101E Ethernet Controller || Intel WiFi Link 5100 with ''iwlagn'' driver || Untested || Both suspend and hibernate work flawlessly with [[pm-utils]] || Untested || Realtek card reader works out-of-the-box. LCD brightness works out-of-the-box; volume keys need configuring through key bindings. || Overall, this laptop is Linux friendly.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcmsmac.2Fbrcmfmac|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read this [[hybrid_graphics#ATI_Dynamic_Switchable_Graphics|ATI Dynamic Switchable Graphics]]. This has not be testing yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2014.10.01 || Intel® HD Graphics 4400 || Untested || Yes RJ45 Ethernet || Came with Intel® 7260BGN + BT4.0 but never tested it. I switched the card to an Intel® 7260AG + BT4.0 Dual Band (IEEE 802.11AC) Works perfectly with iwlwifi driver || Yes, check wifi section for details. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad needs a lot of modifying to scroll properly. || All of the hardware works flawlessly. Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. Kernel 4.2.x causes ACPI battery to not be detected, {{Pkg|linux-lts}} works fine.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]] untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Inspiron E1405 || Any || 3D with {{Pkg|xf86-video-intel}} 2.0, native resolution with {{Pkg|xorg-server}} 1.3 (1440x900) || Intel HD Audio with [[ALSA]] || Yes || Yes, ipw3945 || Yes || Suspend-to-RAM is shaky; hibernate is flawless || Untested || SD card reader works out-of-the-box || Everything else works without a hitch<br />
|}<br />
<br />
== Latitude ==<br />
{{HCL/Laptops table header}}<br />
| Latitude D420 || Duke || {{Pkg|xf86-video-intel}}, native resolution with {{Pkg|xorg-server}} 1.2 (1280x800) || Intel HD Audio with ALSA || Yes (with tg3) || Yes (with ipw3945) || N/A || || Untested || Have not tested SD card reader || External D-Bay DVD/CD-RW works, docking station mostly works (can un-dock, but locks up on re-docking)<br />
|-<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes, with [[pm-utils]] || Untested || ||<br />
|-<br />
| [[Latitude E5540]] || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M using {{Pkg|nvidia}} || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works find (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM good, hibernate not working || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. Touchpad (alps a10) pointer aspens by default, install {{AUR|psmouse-elantech}}{{Broken package link|{{aur-mirror|psmouse-elantech}}}} from the [[AUR]] to fix it ({{AUR|psmouse-alps}}{{Broken package link|{{aur-mirror|psmouse-alps}}}} does not work anymore) || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|}<br />
<br />
== Precision ==<br />
{{HCL/Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|}<br />
<br />
== Studio ==<br />
{{HCL/Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{AUR|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
<br />
== XPS ==<br />
{{HCL/Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| XPS M1210 || Duke || 3D with NVIDIA open source drivers || SigmaTel audio with ALSA || ''b44'' module, out-of-the-box || IPW 3945, command-line {{Pkg|wireless_tools}} || Untested || Untested || Untested || rico card reader worked out-of-the-box, hot keys using keytouch, web cam works but is unstable. In [[MPlayer]], use {{ic|1=driver=v4l2:device=/dev/video0}} || Everything else works without a hitch<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || Don't Panic (2007.08-2) || For dedicated graphics (NVIDIA 8400m) works with NVIDIA package || Works with Intel HD Audio and ALSA, but need to configure microphone || Yes || Works with iwl4965 || Can set Bluetooth but have not tested with any devices || Suspend works fine with [[pm-utils]] (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || Untested || 2.0 MP web cam works with ''uvcvideo'', media keys work with keytouch or esekeyd, IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone<br />
|}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=423732Dm-crypt/Encrypting an entire system2016-03-03T01:17:59Z<p>Slowbro: Update LVM on LUKS to make it a bit more clear how the setup goes, especially w/ bootloader</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Encryption]]<br />
[[Category:File systems]]<br />
[[Category:Getting and installing Arch]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
Back to [[dm-crypt]].<br />
<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://www.archlinux.org/download/ installation image].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted. <br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below: <br />
<br />
{| class="wikitable"<br />
! Scenarios <br />
! Advantages <br />
! Disadvantages <br />
|----------------------------------------------------------<br />
| [[#Simple partition layout with LUKS]]<br />
shows a basic and straight-forward set-up for a fully LUKS encrypted root. <br />
|<br />
* Simple partitioning and setup<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated <br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexiblity by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not transparent when locked<br />
* Easiest method to allow [[Dm-crypt/Swap_encryption#With_suspend-to-disk_support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook <br />
* Less useful, if a singular volume should receive a separate key <br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup. <br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks <br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys <br />
* LVM layout is transparent when locked <br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios. <br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Deniable encryption|deniable encryption]]<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it <br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an ESP partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the ESP partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of blockdevice and stacked filesystem encryption and reap the advantages of both. See [[Disk encryption]] to plan ahead. <br />
<br />
See [[Dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[Dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[Dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
== Simple partition layout with LUKS ==<br />
<br />
This example covers a full system encryption with ''dmcrypt'' + LUKS in a simple partition layout:<br />
<br />
+--------------------+--------------------------+--------------------------+<br />
|Boot partition |LUKS encrypted system |Optional free space |<br />
| |partition |for additional partitions |<br />
|/dev/sdaY |/dev/sdaX |or swap to be setup later |<br />
+--------------------+--------------------------+--------------------------+<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sdaX}}) and {{ic|/boot}} ({{ic|/dev/sdaY}}), see [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[Dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured). <br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|encryption options]] before executing the first command:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdaX<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mkfs -t ext4 /dev/mapper/cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
Check the mapping works as intended:<br />
# umount /mnt<br />
# cryptsetup close cryptroot<br />
# cryptsetup open /dev/sdaX cryptroot<br />
# mount -t ext4 /dev/mapper/cryptroot /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[Dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each blockdevice requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[Dm-crypt/Device encryption#Using LUKS to Format Partitions with a Keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for a crypted root. For a standard [[EFI|MBR/non-EFI]] {{ic|/boot}} partition, for example, execute:<br />
# mkfs -t ext4 /dev/sdaY<br />
# mkdir /mnt/boot<br />
# mount -t ext4 /dev/sdaY /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
At [[Installation guide#Mount the partitions]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
Afterwards continue with the installation procedure up to the mkinitcpio step.<br />
<br />
=== Configuring mkinitcpio ===<br />
Add the {{ic|encrypt}} hook to [[mkinitcpio.conf]]:<br />
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' ... filesystems ..."}}<br />
<br />
Depending on which other hooks are used, the order may be relevant. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader: <br />
<br />
cryptdevice=UUID=''<device-UUID>'':cryptroot root=/dev/mapper/cryptroot<br />
<br />
See [[Dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
The {{ic|''<device-UUID>''}} refers to the UUID of {{ic|/dev/sdaX}}, see [[Persistent block device naming]] for details.<br />
<br />
== LVM on LUKS ==<br />
<br />
The straight-forward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot. <br />
<br />
The disk layout in this example is: <br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume1 | Logical volume2 | Logical volume3 | | |<br />
|/dev/mapper/MyVol-swap |/dev/mapper/MyVol-root |/dev/mapper/MyVol-home | | Boot partition |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS encrypted partition | | |<br />
| /dev/sdaX | | /dev/sdbY |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
<br />
This method does not allow you to span the logical volumes over multiple disks, even in the future. The [[#LUKS on LVM]] method does not have this limitation.<br />
<br />
{{Tip|Two variants of this setup: <br />
* Instructions at [[Dm-crypt/Specialties#Encrypted system using a remote LUKS header]] use this setup with a remote LUKS header on a USB device to achieve a two factor authentication with it. <br />
* Instructions at [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ Pavel Kogan's blog] show how to encrypt the {{ic|/boot}} partition while keeping it on the main LUKS partition when using GRUB, but be aware of {{Bug|43663}}.}} <br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]].<br />
<br />
When using the [[GRUB]] bootloader together with [[GPT]], create a BIOS Boot Partition as explained in [[GRUB#BIOS systems]].<br />
<br />
Create a partition to be mounted at {{ic|/boot}} of type {{ic|8300}} with a size of 100 MB or more.<br />
<br />
Create a partition of type {{ic|8E00}}, which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/''sdaX''<br />
<br />
For more information about the available cryptsetup options see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open --type luks /dev/''sdaX'' lvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/lvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/lvm<br />
<br />
Create the volume group named {{ic|MyVol}} (or whatever you want), adding the previously created physical volume to it:<br />
<br />
# vgcreate MyVol /dev/mapper/lvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
# lvcreate -L 8G MyVol -n swap<br />
# lvcreate -L 15G MyVol -n root<br />
# lvcreate -l 100%FREE MyVOl -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/mapper/MyVol-root<br />
# mkfs.ext4 /dev/mapper/MyVol-home<br />
# mkswap /dev/mapper/MyVol-swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/mapper/MyVol-root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/mapper/MyVol-home /mnt/home<br />
# swapon /dev/mapper/MyVol-swapv<br />
<br />
=== Preparing the boot partition ===<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. This directory must be located on a separate unencrypted filesystem. <br />
<br />
Create an Ext2 filesystem on the partition intended for {{ic|/boot}}. Any filesystem that can be read by the bootloader is eligible.<br />
<br />
# mkfs.ext2 /dev/''sdbY''<br />
<br />
Create the directory {{ic|/mnt/boot}}:<br />
<br />
# mkdir /mnt/boot<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount /dev/''sdbY'' /mnt/boot<br />
<br />
Afterwards continue with the installation procedure up to the {{ic|mkinitcpio}} step.<br />
<br />
=== Configuring mkinitcpio ===<br />
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
{{hc|/etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}<br />
<br />
{{Note|The order of both hooks no longer matters with the current implementation of {{ic|lvm2}}.}}<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':lvm root=/dev/mapper/MyVol-root<br />
<br />
You can get the device-UUID from {{ic|blkid}} - see [[Persistent block device naming]] for more details.{{ic|:lvm}} refers to the mapper name that was set up for the LVM PV (in this case, /dev/mapper/lvm).<br />
<br />
See [[Dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well. Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. <br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan. If you want to span a logical volume over multiple disks during setup already, a procedure to do so is described in [[Dm-crypt/Specialties#Expanding LVM on multiple disks]].<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#Simple partition layout with LUKS]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
* {{ic|/dev/sda1}} -> {{ic|/boot}}<br />
* {{ic|/dev/sda2}} -> LVM<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[Dm-crypt/Drive preparation#dm-crypt wipe before installation]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# lvm pvcreate /dev/sda2<br />
# lvm vgcreate lvm /dev/sda2<br />
# lvm lvcreate -L 10G -n lvroot lvm<br />
# lvm lvcreate -L 500M -n swap lvm<br />
# lvm lvcreate -L 500M -n tmp lvm<br />
# lvm lvcreate -l 100%FREE -n home lvm<br />
<br />
# cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/lvm/lvroot<br />
# cryptsetup open --type luks /dev/lvm/lvroot root<br />
# mkfs -t ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[Dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]]. Further, note that if you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show_up|LVM shows up]].<br />
<br />
=== Preparing the boot partition ===<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M<br />
# mkfs -t ext4 /dev/sda1<br />
# mkdir /mnt/boot<br />
# mount /dev/sda1 /mnt/boot<br />
<br />
Now after setup of the encrypted LVM partitioning, it would be time to install: [[Installation guide#Mount_the_partitions|Arch Install Scripts]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''block'' ''''encrypt''' '''lvm2''' ... filesystems ..."}}<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:<br />
<br />
cryptdevice=/dev/lvm/lvroot:cryptoroot root=/dev/mapper/cryptoroot<br />
<br />
See [[Dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0}}<br />
The following [[Dm-crypt/System_configuration#crypttab|crypttab]] options will re-encrypt the temporary filesystems each reboot:<br />
{{hc|/etc/crypttab|<br />
swap /dev/lvm/swap /dev/urandom swap,cipher<nowiki>=aes-xts-plain64,size=</nowiki>256<br />
tmp /dev/lvm/tmp /dev/urandom tmp,cipher<nowiki>=aes-xts-plain64,size=</nowiki>256}}<br />
<br />
=== Encrypting logical volume /home ===<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should be persistent, of course. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths. <br />
To safe on entering a second passphrase at boot for it, a [[Dm-crypt/Device_encryption#Keyfiles|keyfile]] is created: <br />
mkdir -m 700 /etc/luks-keys<br />
dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256<br />
<br />
The logical volume is encrypted with it: <br />
cryptsetup luksFormat -v -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup -d /etc/luks-keys/home open --type luks /dev/lvm/home home<br />
mkfs -t ext4 /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
The encrypted mount is configured in [[Dm-crypt/System_configuration#crypttab|crypttab]]: <br />
{{hc|/etc/crypttab|<br />
home /dev/lvm/home /etc/luks-keys/home}}<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2}}<br />
and setup is done.<br />
<br />
If you want to expand the logical volume for {{ic|/home}} (or any other volume) at a later point, it is important to note that the LUKS encrypted part has to be resized as well. For a procedure see [[Dm-crypt/Specialties#Expanding LVM on multiple disks]].<br />
<br />
== LUKS on software RAID ==<br />
<br />
{{Expansion|Some references: [[RAID]], [[Software RAID and LVM]], http://wiki.drewhess.com/wiki/Creating_an_encrypted_filesystem_on_a_partition , http://jasonwryan.com/blog/2012/02/11/lvm/ . Note that full-disk encryption is [https://forums.gentoo.org/viewtopic-p-7029704.html not deniable] with this configuration (consider RAID on LUKS instead?).}}<br />
<br />
== Plain dm-crypt ==<br />
<br />
This scenario sets up a system on a dm-crypt a full disk with ''plain'' mode encryption. Note that for most use cases, the methods using LUKS described above are the better options for both system encryption and encrypted partitions. LUKS features like key management with multiple pass-phrases/key-files are unavailable with ''plain'' mode.<br />
<br />
dm-crypt ''plain'' mode does not require a header on the encrypted disk: this means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data, which is the desired attribute for this scenario, see also [[Wikipedia:Deniable encryption]]. <br />
<br />
''Plain'' dm-crypt encrypted disks can be more resilient to damage than LUKS encrypted disks, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Disk encryption#Cryptographic metadata]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are: <br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function, or <br />
* dm-crypt LUKS mode by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook [[Dm-crypt/Specialties#Encrypted system using a remote LUKS header|may be modified]].}}<br />
<br />
The scenario uses a USB stick for the boot device and another one to store the encryption key. The disk layout is: <br />
<br />
+--------------------+------------------+--------------------+ +---------------+ +---------------+<br />
|Volume 1: |Volume 2: |Volume 3: | |Boot device | |Encryption key |<br />
| | | | | | |file storage |<br />
|root |swap |home | |/boot | |(unpartitioned |<br />
| | | | | | |in example) |<br />
|/dev/store/root |/dev/store/swap |/dev/store/home | |/dev/sdY1 | |/dev/sdZ |<br />
|--------------------+------------------+--------------------| |---------------| |---------------|<br />
|disk drive /dev/sdaX encrypted using plain mode and LVM | |USB stick 1 | |USB stick 2 |<br />
+------------------------------------------------------------+ +---------------+ +---------------+<br />
<br />
{{ic|/boot}} and the boot loader cannot be kept on the encrypted drive, or it will defeat the purpose of using ''plain'' mode for deniable encryption. This also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone.<br />
<br />
This scenario also uses a key file, assuming it stored as raw bits on a second USB stick, so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[Dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
{{Tip|<br />
* It is also possible to use a single usb key by copying the keyfile to the initram directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initram image by setting {{ic|1=FILES="/etc/keyfile"}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initram image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|cryptkey&#61;rootfs:/etc/keyfile}}. <br />
* Another option is using a passphrase with good [[Disk_encryption#Choosing_a_strong_passphrase|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with data. In particular this applies to the scenario usecase we apply here. <br />
<br />
See [[Dm-crypt/Drive preparation]] and [[Dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[Dm-crypt/Device encryption#Encryption options for plain mode]] for details. <br />
<br />
Using the device {{ic|/dev/sd''X''}}, with the twofish-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario: <br />
{{bc|<nowiki># cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=</nowiki>/dev/sd''Z'' <nowiki>--key-size=512 open --type=plain /dev/sdX enc</nowiki>}}<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. <br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/enc}}:<br />
# fdisk -l<br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device, see [[LVM#Installing Arch Linux on LVM]] for further details: <br />
# pvcreate /dev/mapper/enc<br />
# vgcreate store /dev/mapper/enc<br />
# lvcreate -L 20G store -n root<br />
# lvcreate -L 10G store -n swap<br />
# lvcreate -l 100%FREE store -n home<br />
We format and mount them and activate swap, see [[File systems#Format a device]] for further details: <br />
# mkfs.ext4 /dev/store/root<br />
# mkfs.ext4 /dev/store/home<br />
# mount /dev/store/root /mnt<br />
# mkdir /mnt/home<br />
# mount /dev/store/home /mnt/home<br />
# mkswap /dev/store/swap<br />
# swapon /dev/store/swap<br />
<br />
=== Preparing the boot partition ===<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required. Create the partition using a [[Partitioning#Partitioning_tools|partitioning tool]] of your choice.<br />
<br />
We choose a non-journalling file system to preserve the flash memory of the {{ic|/boot}} partition, if not already formatted as vfat:<br />
# mkfs.ext2 /dev/sd''Y''1<br />
# mkdir /mnt/boot<br />
# mount /dev/sd''Y''1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
{{hc|etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following kernel parameters need to be set by the boot loader:<br />
<br />
cryptdevice=/dev/sd''X'':enc cryptkey=/dev/sd''Z'':0:512 crypto=sha512:twofish-xts-plain64:512:0:<br />
<br />
See [[Dm-crypt/System configuration#Boot loader]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
# grub-install --recheck /dev/sd''Y''<br />
}}<br />
<br />
===Post-installation===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sd''Yn''<br />
/dev/sd''Yn'' /boot ext2 '''noauto''',rw,noatime 0 2}}<br />
<br />
However, when an update to the kernel or bootloader is required, the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration for the system's root partition as the previous [[#LVM on LUKS]] section, with two distinct differences: <br />
<br />
# The setup is performed for an [[UEFI]] system and <br />
# A special feature of the [[GRUB]] bootloader is used to additionally encrypt the boot partition {{ic|/boot}}. See also [[GRUB#Boot partition]].<br />
<br />
The disk layout in this example is: <br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Boot partition: |Volume 1: |Volume 2: |Volume 3: |<br />
| | | | | |<br />
|/boot/efi |/boot |root |swap |home |<br />
| | | | | |<br />
| | |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |/dev/sdaY +----------------+----------------+----------------+<br />
|'''un'''encrypted |LUKS encrypted |/dev/sdaZ encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
{{Tip|All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].}} <br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]].<br />
<br />
Create an [[Unified_Extensible_Firmware_Interface#EFI_System_Partition|EFI System Partition (ESP)]] with an appropriate size, it will later be mounted at {{ic|/boot/efi}}. <br />
<br />
Create a partition to be mounted at {{ic|/boot}} of type {{ic|8300}} with a size of 100 MB or more.<br />
<br />
{{Tip|When using the [[GRUB]] bootloader together with a BIOS/[[GPT]], create a BIOS Boot Partition as explained in [[GRUB#BIOS systems]] instead of the ESP.}}<br />
<br />
Create a partition of type {{ic|8E00}}, which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. <br />
<br />
# cryptsetup luksFormat /dev/''sdaZ''<br />
<br />
For more information about the available cryptsetup options see the [[Dm-crypt/Device encryption#Encryption_options_for_LUKS_mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
{{hc| gdisk /dev/sda |<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 1050623 512.0 MiB EF00 EFI System<br />
2 1050624 1460223 200.0 MiB 8300 Linux filesystem<br />
3 1460224 41943006 19.3 GiB 8E00 Linux LVM<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open --type luks /dev/''sdaZ'' lvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/lvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the previous scenario. Therefore, please follow [[#Preparing the logical volumes|Preparing the logical volumes]] above or adjust as required.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. <br />
<br />
First, create the LUKS container where the files will be located and installed into: <br />
<br />
# cryptsetup luksFormat /dev/sda''Y'' <br />
<br />
Next, open it: <br />
# cryptsetup open /dev/sda''Y'' cryptboot <br />
<br />
Create a filesystem on the partition intended for {{ic|/boot}}. Any filesystem that can be read by the bootloader is eligible:<br />
<br />
# mkfs.ext2 /dev/mapper/''cryptboot''<br />
<br />
Create the directory {{ic|/mnt/boot}}:<br />
<br />
# mkdir /mnt/boot<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount /dev/mapper/''cryptboot'' /mnt/boot<br />
<br />
Create a mountpoint for the [[Unified_Extensible_Firmware_Interface#EFI_System_Partition|ESP]] at {{ic|/boot/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mkdir /mnt/boot/efi<br />
# mount /dev/''sdaX'' /mnt/boot/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
{{hc|lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk <br />
├─sda1 8:1 0 512M 0 part /boot/efi<br />
├─sda2 8:2 0 200M 0 part <br />
│ └─boot 254:0 0 198M 0 crypt /boot<br />
└─sda3 8:3 0 100G 0 part <br />
└─lvm 254:1 0 100G 0 crypt <br />
├─MyStorage-swapvol 254:2 0 8G 0 lvm [SWAP]<br />
├─MyStorage-rootvol 254:3 0 15G 0 lvm /<br />
└─MyStorage-homevol 254:4 0 77G 0 lvm /home<br />
}}<br />
<br />
Afterwards continue with the installation procedure up to the mkinitcpio step.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
{{hc|/etc/mkinitcpio.conf|2=HOOKS="... '''encrypt''' '''lvm2''' ... filesystems ..."}}<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
In order to unlock the encrypted root partition at boot, the following kernel parameters need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''<device-UUID>'':MyStorage root=/dev/mapper/MyStorage-rootvol<br />
<br />
See [[Dm-crypt/System configuration#Boot loader]] for details.<br />
<br />
The {{ic|''<device-UUID>''}} refers to the UUID of {{ic|/dev/sdaX}}, see [[Persistent block device naming]] for details.<br />
<br />
Now we prepare the GRUB bootloader installation to recognize the LUKS encrypted {{ic|/boot}} partition according to [[GRUB#Boot partition]]. <br />
<br />
Open {{ic|/etc/default/grub}} and add the parameter to the end:<br />
<br />
{{ic|1=GRUB_ENABLE_CRYPTODISK=y}}<br />
<br />
Create the GRUB menu configuration file: <br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
[[GRUB#Installation_2|Install GRUB]] to the mounted ESP: <br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck<br />
<br />
If this finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/boot}} partition after the next reboot.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
This section deals with extra configuration to let the system '''mount''' the encrypted {{ic|/boot}}. <br />
<br />
While GRUB asks for a passphrase to unlock the encrypted {{ic|/boot}} after above instructions, the partition unlock is not passed on to the initramfs. Hence, {{ic|/boot}} will not be available after the system has re-/booted, because the {{ic|encrypt}} hook only unlocks the system's root. <br />
<br />
If you used the ''genfstab'' script during installation, it will have generated {{ic|/etc/fstab}} entries for the {{ic|/boot}} and {{ic|/boot/efi}} mount points already, but the system will fail to find the generated device mapper for the boot partition. To make it available, add it to [[Dm-crypt/System configuration#crypttab|crypttab]]. For example: <br />
<br />
{{hc|/etc/crypttab|<br />
cryptboot /dev/sdaY none luks}}<br />
<br />
will make the system ask for the passphrase again (i.e. you have to enter it twice at boot: once for GRUB and once for systemd init). To avoid the double entry for unlocking {{ic|/boot}}, follow the instructions at [[Dm-crypt/Device encryption#Keyfiles]] to: <br />
<br />
# Create a [[Dm-crypt/Device_encryption#Storing the keyfile on a filesystem|randomtext keyfile]], <br />
# Add the keyfile to the ({{ic|/dev/sdaY}}) [[Dm-crypt/Device encryption#Configuring LUKS to make use of the keyfile|boot partition's LUKS header]] and<br />
# Check the {{ic|/etc/fstab}} entry and add the {{ic|/etc/crypttab}} line to [[Dm-crypt/Device_encryption#Unlocking_a_secondary_partition_at_boot|unlock it automatically at boot]].<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|Optional post-installation steps: <br />
* It may be worth considering to add the GRUB bootloader to the ignore list of {{ic|/etc/pacman.conf}} in order to take particular control of when the bootloader (which includes its own encryption modules) is updated. <br />
* If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=423731Laptop/Dell2016-03-03T01:00:57Z<p>Slowbro: /* Latitude */</p>
<hr />
<div>[[Category:Dell]]<br />
{{Laptops navigation}}<br />
<br><br />
== Inspiron ==<br />
{{HCL/Laptops table header}}<br />
| Inspiron 1300 || Don't Panic (Core Dump version) || 3D with {{Pkg|xf86-video-intel}} || Intel || ''b44'' module works out-of-the-box || BCM4318-based card, works with [[ndiswrapper]] || N/A || Untested || Untested || -- || Everything works out-of-the-box except wireless and sometimes screen resolution<br />
|- <br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{AUR|broadcom-wl}} needed from the AUR || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || Both hibernate and suspend-to-RAM and works with [[pm-utils]] || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ([[AUR]] {{AUR|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS; media keys configured with KeyTouch. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| [[Dell Inspiron 1564|Inspiron 1564]] || Core Dump || 3D with either [[Catalyst]] or [[ATI|xf86-video-ati]]; both work flawlessly. || Intel HD Audio with ALSA || Realtek RTL8101E Ethernet Controller || Intel WiFi Link 5100 with ''iwlagn'' driver || Untested || Both suspend and hibernate work flawlessly with [[pm-utils]] || Untested || Realtek card reader works out-of-the-box. LCD brightness works out-of-the-box; volume keys need configuring through key bindings. || Overall, this laptop is Linux friendly.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcmsmac.2Fbrcmfmac|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read this [[hybrid_graphics#ATI_Dynamic_Switchable_Graphics|ATI Dynamic Switchable Graphics]]. This has not be testing yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2014.10.01 || Intel® HD Graphics 4400 || Untested || Yes RJ45 Ethernet || Came with Intel® 7260BGN + BT4.0 but never tested it. I switched the card to an Intel® 7260AG + BT4.0 Dual Band (IEEE 802.11AC) Works perfectly with iwlwifi driver || Yes, check wifi section for details. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad needs a lot of modifying to scroll properly. || All of the hardware works flawlessly. Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. Kernel 4.2.x causes ACPI battery to not be detected, {{Pkg|linux-lts}} works fine.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]] untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Inspiron E1405 || Any || 3D with {{Pkg|xf86-video-intel}} 2.0, native resolution with {{Pkg|xorg-server}} 1.3 (1440x900) || Intel HD Audio with [[ALSA]] || Yes || Yes, ipw3945 || Yes || Suspend-to-RAM is shaky; hibernate is flawless || Untested || SD card reader works out-of-the-box || Everything else works without a hitch<br />
|}<br />
<br />
== Latitude ==<br />
{{HCL/Laptops table header}}<br />
| Latitude D420 || Duke || {{Pkg|xf86-video-intel}}, native resolution with {{Pkg|xorg-server}} 1.2 (1280x800) || Intel HD Audio with ALSA || Yes (with tg3) || Yes (with ipw3945) || N/A || || Untested || Have not tested SD card reader || External D-Bay DVD/CD-RW works, docking station mostly works (can un-dock, but locks up on re-docking)<br />
|-<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes, with [[pm-utils]] || Untested || ||<br />
|-<br />
| Latitude E5540 || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M using {{Pkg|nvidia}} || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works find (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM good, hibernate not working || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. Touchpad (alps a10) pointer aspens by default, install {{AUR|psmouse-elantech}}{{Broken package link|{{aur-mirror|psmouse-elantech}}}} from the [[AUR]] to fix it ({{AUR|psmouse-alps}}{{Broken package link|{{aur-mirror|psmouse-alps}}}} does not work anymore) || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|}<br />
<br />
== Precision ==<br />
{{HCL/Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|}<br />
<br />
== Studio ==<br />
{{HCL/Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{AUR|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
<br />
== XPS ==<br />
{{HCL/Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| XPS M1210 || Duke || 3D with NVIDIA open source drivers || SigmaTel audio with ALSA || ''b44'' module, out-of-the-box || IPW 3945, command-line {{Pkg|wireless_tools}} || Untested || Untested || Untested || rico card reader worked out-of-the-box, hot keys using keytouch, web cam works but is unstable. In [[MPlayer]], use {{ic|1=driver=v4l2:device=/dev/video0}} || Everything else works without a hitch<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || Don't Panic (2007.08-2) || For dedicated graphics (NVIDIA 8400m) works with NVIDIA package || Works with Intel HD Audio and ALSA, but need to configure microphone || Yes || Works with iwl4965 || Can set Bluetooth but have not tested with any devices || Suspend works fine with [[pm-utils]] (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || Untested || 2.0 MP web cam works with ''uvcvideo'', media keys work with keytouch or esekeyd, IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone<br />
|}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=423730Laptop/Dell2016-03-03T00:59:44Z<p>Slowbro: Cleaned up, put things in categories, tried to order by model number, added Latitude E5540</p>
<hr />
<div>[[Category:Dell]]<br />
{{Laptops navigation}}<br />
<br><br />
== Inspiron ==<br />
{{HCL/Laptops table header}}<br />
| Inspiron 1300 || Don't Panic (Core Dump version) || 3D with {{Pkg|xf86-video-intel}} || Intel || ''b44'' module works out-of-the-box || BCM4318-based card, works with [[ndiswrapper]] || N/A || Untested || Untested || -- || Everything works out-of-the-box except wireless and sometimes screen resolution<br />
|- <br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{AUR|broadcom-wl}} needed from the AUR || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || Both hibernate and suspend-to-RAM and works with [[pm-utils]] || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ([[AUR]] {{AUR|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS; media keys configured with KeyTouch. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| [[Dell Inspiron 1564|Inspiron 1564]] || Core Dump || 3D with either [[Catalyst]] or [[ATI|xf86-video-ati]]; both work flawlessly. || Intel HD Audio with ALSA || Realtek RTL8101E Ethernet Controller || Intel WiFi Link 5100 with ''iwlagn'' driver || Untested || Both suspend and hibernate work flawlessly with [[pm-utils]] || Untested || Realtek card reader works out-of-the-box. LCD brightness works out-of-the-box; volume keys need configuring through key bindings. || Overall, this laptop is Linux friendly.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcmsmac.2Fbrcmfmac|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read this [[hybrid_graphics#ATI_Dynamic_Switchable_Graphics|ATI Dynamic Switchable Graphics]]. This has not be testing yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2014.10.01 || Intel® HD Graphics 4400 || Untested || Yes RJ45 Ethernet || Came with Intel® 7260BGN + BT4.0 but never tested it. I switched the card to an Intel® 7260AG + BT4.0 Dual Band (IEEE 802.11AC) Works perfectly with iwlwifi driver || Yes, check wifi section for details. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad needs a lot of modifying to scroll properly. || All of the hardware works flawlessly. Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. Kernel 4.2.x causes ACPI battery to not be detected, {{Pkg|linux-lts}} works fine.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]] untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Inspiron E1405 || Any || 3D with {{Pkg|xf86-video-intel}} 2.0, native resolution with {{Pkg|xorg-server}} 1.3 (1440x900) || Intel HD Audio with [[ALSA]] || Yes || Yes, ipw3945 || Yes || Suspend-to-RAM is shaky; hibernate is flawless || Untested || SD card reader works out-of-the-box || Everything else works without a hitch<br />
|}<br />
<br />
== Latitude ==<br />
{{HCL/Laptops table header}}<br />
| Latitude D420 || Duke || {{Pkg|xf86-video-intel}}, native resolution with {{Pkg|xorg-server}} 1.2 (1280x800) || Intel HD Audio with ALSA || Yes (with tg3) || Yes (with ipw3945) || N/A || || Untested || Have not tested SD card reader || External D-Bay DVD/CD-RW works, docking station mostly works (can un-dock, but locks up on re-docking)<br />
|-<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes, with [[pm-utils]] || Untested || ||<br />
|-<br />
| Latitude E5540 || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works find (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM good, hibernate not working || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. Touchpad (alps a10) pointer aspens by default, install {{AUR|psmouse-elantech}}{{Broken package link|{{aur-mirror|psmouse-elantech}}}} from the [[AUR]] to fix it ({{AUR|psmouse-alps}}{{Broken package link|{{aur-mirror|psmouse-alps}}}} does not work anymore) || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|}<br />
<br />
== Precision ==<br />
{{HCL/Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|}<br />
<br />
== Studio ==<br />
{{HCL/Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{AUR|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
<br />
== XPS ==<br />
{{HCL/Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| XPS M1210 || Duke || 3D with NVIDIA open source drivers || SigmaTel audio with ALSA || ''b44'' module, out-of-the-box || IPW 3945, command-line {{Pkg|wireless_tools}} || Untested || Untested || Untested || rico card reader worked out-of-the-box, hot keys using keytouch, web cam works but is unstable. In [[MPlayer]], use {{ic|1=driver=v4l2:device=/dev/video0}} || Everything else works without a hitch<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || Don't Panic (2007.08-2) || For dedicated graphics (NVIDIA 8400m) works with NVIDIA package || Works with Intel HD Audio and ALSA, but need to configure microphone || Yes || Works with iwl4965 || Can set Bluetooth but have not tested with any devices || Suspend works fine with [[pm-utils]] (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || Untested || 2.0 MP web cam works with ''uvcvideo'', media keys work with keytouch or esekeyd, IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone<br />
|}</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=391817Laptop/Lenovo2015-08-19T19:10:33Z<p>Slowbro: Fix columns in X Series</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || SD slot ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || NA || SD card (Yes), Webcam (Yes) ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| Lenovo ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/1bec378c98a6c9a4ff496960e7a2268de6e5fd0a kernel recipe patch])<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=391816Laptop/Lenovo2015-08-19T19:09:41Z<p>Slowbro: Fix columns in T Series</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ThinkFinger ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || Card Reader ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || NA || Card Reader || See below<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD slot || ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| Lenovo ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/1bec378c98a6c9a4ff496960e7a2268de6e5fd0a kernel recipe patch])<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=391815Laptop/Lenovo2015-08-19T19:08:40Z<p>Slowbro: fix columns in Edge Series</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || ThinkFinger || ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card Reader || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || Card Reader || See below ||<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD slot || ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| Lenovo ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/1bec378c98a6c9a4ff496960e7a2268de6e5fd0a kernel recipe patch])<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=391729Lenovo ThinkPad T5502015-08-18T22:36:05Z<p>Slowbro: typo</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Lenovo}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
==Configuration==<br />
<br />
===Backlight===<br />
The following kernel options are needed for [[Backlight#Kernel_command-line_options|ACPI/Backlight]]:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1<br />
<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the {{ic|Fn}} key should turn on. Now you can use the {{ic|Fn}} key like normal (''i.e.'', with FnLock on {{ic|Fn+F1}} would equate to a {{ic|XF86AudioMute}} to be handled by X/WM/whathaveyou).<br />
<br />
===Suspend===<br />
Add the following kernel parameter in order to combat freeze/panic after suspend-to-ram:<br />
<br />
i915.enable_rc6=0<br />
<br />
===Video Drivers===<br />
Follow [[Intel graphics]] for installing the GPU driver. The T550 suffers from [[Intel graphics#Loss of horizontal sync when switching TTYs]], but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] fixes it.<br />
<br />
==Issues==<br />
<br />
===DisplayPort Extenders===<br />
The T550 is only able to drive three displays at once. If you are using a one-to-three DisplayPort adapter, you will need to disable the laptop display ({{ic|xrandr --output eDP1 --off}}) in order to use three external displays. Expect a heavy delay (1-2 seconds) while adjusting displays via DisplayPort with {{ic|xrandr}}.<br />
<br />
===USB===<br />
Enabling "Always-On USB" in the BIOS seems to make the forward-most USB port on the right side of the laptop (the 'Charging Port') unusable in Linux - disabling this feature in BIOS re-enables the port.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=389476Laptop/Lenovo2015-07-31T20:37:39Z<p>Slowbro: /* T series */</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || ThinkFinger || ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card Reader || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || Card Reader || See below ||<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || DisplayPort ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD slot || ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| Lenovo ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/1bec378c98a6c9a4ff496960e7a2268de6e5fd0a kernel recipe patch])<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=389475Laptop/Lenovo2015-07-31T20:35:05Z<p>Slowbro: clean up tables; trying to make things easier to find</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
==== 300 series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== Edge series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
==== L series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
|}<br />
<br />
==== R series ====<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad R50 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| IBM ThinkPad R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
|}<br />
<br />
==== T series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || ThinkFinger || ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card Reader || ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || Card Reader || See below ||<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
==== X series ====<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD slot || ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| Lenovo ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
|}<br />
<br />
== Lenovo ==<br />
<br />
=== IdeaPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
=== N series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo N200 (3000) || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
|}<br />
<br />
=== S series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo S21e-20 || 2015.07.01 || Yes || Yes || NA || Yes* || ? || Yes || NA || SD Card (Yes), USB 3.0 (Yes), HDMI Out (?), Touchpad (Yes*) ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
<br />
=== Lenovo S21e-20 ===<br />
* Tested with {{aur|broadcom-wl}} 802.11 wireless driver<br />
* Synaptics touchpad required 3 patches to {{Pkg|linux}}:drivers/hid/hid-rmi.c on 2015-07-26 ([https://bugs.freedesktop.org/show_bug.cgi?id=91102 bug report], [https://github.com/harisokanovic/archlinux-packages/commit/1bec378c98a6c9a4ff496960e7a2268de6e5fd0a kernel recipe patch])<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=389471Lenovo ThinkPad T5502015-07-31T19:19:40Z<p>Slowbro: USB issues</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Lenovo}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
==Configuration==<br />
<br />
===Backlight===<br />
The following kernel options are needed for [[Backlight#Kernel_command-line_options|ACPI/Backlight]]:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1<br />
<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the {{ic|Fn}} key should turn on. Now you can use the {{ic|Fn}} key like normal (''i.e.'', with FnLock on {{ic|Fn+F1}} would equate to a {{ic|XF86AudioMute}} to be handled by X/WM/whathaveyou).<br />
<br />
===Suspend===<br />
Add the following kernel parameter in order to combat freeze/panic after suspend-to-ram:<br />
<br />
i915.enable_rc6=0<br />
<br />
===Video Drivers===<br />
Follow [[Intel graphics]] for installing the GPU driver. The T550 suffers from [[Intel graphics#Loss of horizontal sync when switching TTYs]], but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] fixes it.<br />
<br />
==Issues==<br />
<br />
===DisplayPort Extenders===<br />
The T550 is only able to drive three displays at once. If you are using a one-to-three DisplayPort adapter, you will need to disable the laptop display ({{ic|xrandr --output eDP1 --off}}) in order to use three external displays. Expect a heavy delay (1-2 seconds) while adjusting displays via DisplayPort with {{ic||xrandr}}.<br />
<br />
===USB===<br />
Enabling "Always-On USB" in the BIOS seems to make the forward-most USB port on the right side of the laptop (the 'Charging Port') unusable in Linux - disabling this feature in BIOS re-enables the port.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=387120Lenovo ThinkPad T5502015-07-22T22:23:20Z<p>Slowbro: </p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Lenovo}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
==Configuration==<br />
<br />
===Backlight===<br />
The following kernel options are needed for [[Backlight#Kernel_command-line_options|ACPI/Backlight]]:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1<br />
<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the {{ic|Fn}} key should turn on. Now you can use the {{ic|Fn}} key like normal (''i.e.'', with FnLock on {{ic|Fn+F1}} would equate to a {{ic|XF86AudioMute}} to be handled by X/WM/whathaveyou).<br />
<br />
===Suspend===<br />
Add the following kernel parameter in order to combat freeze/panic after suspend-to-ram:<br />
<br />
i915.enable_rc6=0<br />
<br />
===Video Drivers===<br />
[[Install]] {{ic|xf86-video-intel}} for graphics drivers. The T550 suffers from [[Intel graphics#Loss of horizontal sync when switching TTYs]], but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] fixes it.<br />
<br />
==Issues==<br />
<br />
===DisplayPort Extenders===<br />
The T550 is only able to drive three displays at once. If you are using a one-to-three DisplayPort adapter, you will need to disable the laptop display ({{ic|xrandr --output eDP1 --off}}) in order to use three external displays. Expect a heavy delay (1-2 seconds) while adjusting displays via DisplayPort with {{ic||xrandr}}.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=387119Lenovo ThinkPad T5502015-07-22T22:19:15Z<p>Slowbro: /* Suspend */</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Lenovo}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
==Configuration==<br />
<br />
===Backlight===<br />
The following kernel options are needed for [[Backlight#Kernel_command-line_options|ACPI/Backlight]]:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1<br />
<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the {{ic|Fn}} key should turn on. Now you can use the {{ic|Fn}} key like normal (''i.e.'', with FnLock on {{ic|Fn+F1}} would equate to a {{ic|XF86AudioMute}} to be handled by X/WM/whathaveyou).<br />
<br />
===Suspend===<br />
Add the following kernel parameter in order to combat freeze/panic after suspend-to-ram:<br />
<br />
i915.enable_rc6=0<br />
<br />
===Video Drivers===<br />
[[Install]] {{ic|xf86-video-intel}} for graphics drivers. The T550 suffers from [[Intel graphics#Loss of horizontal sync when switching TTYs]], but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] fixes it.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=387118Lenovo ThinkPad T5502015-07-22T21:47:28Z<p>Slowbro: suspend</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Related articles start}}<br />
{{Related|Laptop}}<br />
{{Related|Laptop/Lenovo}}<br />
{{Related articles end}}<br />
<br />
==Installation==<br />
Use the [[Installation]] guide.<br />
<br />
==Configuration==<br />
<br />
===Backlight===<br />
The following kernel options are needed for [[Backlight#Kernel_command-line_options|ACPI/Backlight]]:<br />
<br />
acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1<br />
<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the {{ic|Fn}} key should turn on. Now you can use the {{ic|Fn}} key like normal (''i.e.'', with FnLock on {{ic|Fn+F1}} would equate to a {{ic|XF86AudioMute}} to be handled by X/WM/whathaveyou).<br />
<br />
===Suspend===<br />
Add the following kernel parameter in order to combat freeze/panic after suspend-to-ram:<br />
<br />
i915.i915_enable_rc6=0<br />
<br />
===Video Drivers===<br />
[[Install]] {{ic|xf86-video-intel}} for graphics drivers. The T550 suffers from [[Intel graphics#Loss of horizontal sync when switching TTYs]], but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] fixes it.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=380678Lenovo ThinkPad T5502015-07-02T06:53:29Z<p>Slowbro: /* Kernel Options */</p>
<hr />
<div>[[Category:Lenovo]]<br />
<br />
==Base System==<br />
The basic setup in [[Beginners' Guide]] works fine.<br />
<br />
===Kernel Options===<br />
The following kernel options are needed for ACPI/Backlight:<br />
<br />
<code>acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1</code><br />
<br />
==Video==<br />
===Drivers===<br />
Use {{ic|xf86-video-intel}} for graphics drivers. The T550 seems to suffer from [[Intel_graphics#Loss_of_horizontal_sync_when_switching_TTYs]] - but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] seems to fix it.<br />
<br />
===Backlight===<br />
The backlight uses the Intel driver, with the sysfs class located at {{ic|/sys/class/backlight/intel_backlight}} Changing via {{ic|xbacklight}} seems to work fine.<br />
<br />
==Hardware==<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the Fn key should turn on. Now you can use the Fn ley like normal - i.e. with FnLock on {{ic|Fn+F1}} would equate to an XF86AudioMute}} to be handled by X/WM/whathaveyou.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=380677Lenovo ThinkPad T5502015-07-02T06:52:21Z<p>Slowbro: /* Base System */</p>
<hr />
<div>[[Category:Lenovo]]<br />
<br />
==Base System==<br />
The basic setup in [[Beginners' Guide]] works fine.<br />
<br />
===Kernel Options===<br />
The following kernel options are needed for ACPI/Backlight: {{ic|acpi_osi=Linux acpi_backlight=vendor video.use_native_backlight=1}}<br />
<br />
==Video==<br />
===Drivers===<br />
Use {{ic|xf86-video-intel}} for graphics drivers. The T550 seems to suffer from [[Intel_graphics#Loss_of_horizontal_sync_when_switching_TTYs]] - but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] seems to fix it.<br />
<br />
===Backlight===<br />
The backlight uses the Intel driver, with the sysfs class located at {{ic|/sys/class/backlight/intel_backlight}} Changing via {{ic|xbacklight}} seems to work fine.<br />
<br />
==Hardware==<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the Fn key should turn on. Now you can use the Fn ley like normal - i.e. with FnLock on {{ic|Fn+F1}} would equate to an XF86AudioMute}} to be handled by X/WM/whathaveyou.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=380676Lenovo ThinkPad T5502015-07-02T06:45:26Z<p>Slowbro: Fn key</p>
<hr />
<div>[[Category:Lenovo]]<br />
<br />
==Base System==<br />
The basic setup in [[Beginners' Guide]] works fine.<br />
<br />
==Video==<br />
===Drivers===<br />
Use {{ic|xf86-video-intel}} for graphics drivers. The T550 seems to suffer from [[Intel_graphics#Loss_of_horizontal_sync_when_switching_TTYs]] - but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] seems to fix it.<br />
<br />
===Backlight===<br />
The backlight uses the Intel driver, with the sysfs class located at {{ic|/sys/class/backlight/intel_backlight}} Changing via {{ic|xbacklight}} seems to work fine.<br />
<br />
==Hardware==<br />
===Fn Keys===<br />
Function/Fn keys do not work without the FnLock on. To enable the FnLock, press {{ic|Fn+Esc}}. The green light on the Fn key should turn on. Now you can use the Fn ley like normal - i.e. with FnLock on {{ic|Fn+F1}} would equate to an XF86AudioMute}} to be handled by X/WM/whathaveyou.</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Laptop/Lenovo&diff=380556Laptop/Lenovo2015-06-30T23:19:11Z<p>Slowbro: Add T550 page</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Laptops navigation}}<br />
<br><br />
== IBM/Lenovo ==<br />
<br />
=== ThinkPad ===<br />
<br />
{{HCL/Laptops table header}}<br />
| IBM ThinkPad 380ED || NA|| NA || NA || NA || No || NA || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T21]] || Yes* || Yes || Yes || NA || NA || Yes* || NA || NA || See below ||<br />
|-<br />
| [[IBM ThinkPad T23]] || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad T42]] || Yes || Yes || Yes || Yes || NA || Yes || NA || NA || ||<br />
|-<br />
| IBM ThinkPad T60 || Yes || Yes || Yes || Yes || Yes || Yes || ? || NA || ||<br />
|-<br />
| IBM ThinkPad T60p || Yes || Yes || Yes || Yes || Yes || Yes || ? || ThinkFinger || ||<br />
|-<br />
| [[IBM ThinkPad T61]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad T61p || Yes || Yes || Yes || Yes || Yes || Yes || NA || || ||<br />
|-<br />
| IBM ThinkPad X23 || Yes || Yes || Yes || NA || NA || Yes || NA || NA || ||<br />
|-<br />
| [[IBM ThinkPad X60s]] || Yes|| Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo ThinkPad X61s || Yes || Yes || Yes || Yes || Yes || Yes || Yes || SD slot || ||<br />
|-<br />
| Lenovo ThinkPad R60 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| Lenovo 3000 N200 || Yes || Yes* || Yes || Yes || Yes || Yes* || NA || NA || See below ||<br />
|-<br />
| IBM ThinkPad R50,R52 || Yes || Yes || Yes || Yes || NA || Yes || Yes || Infrared* || ||<br />
|-<br />
| [[Lenovo ThinkPad X100e]] || Yes|| Yes || Yes || Yes || Yes || Yes || Not tested || SD card (Yes), Webcam (Yes) || ||<br />
|-<br />
| [[Lenovo ThinkPad X200]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad X201]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || ||<br />
|-<br />
| [[Lenovo IdeaPad S10]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad S400 Touch]] || Yes || Yes || Yes || Yes || Yes || Yes || Not tested || NA || ||<br />
|-<br />
| [[Lenovo IdeaPad Flex 10]] || Yes || Yes* || Yes || NA || Yes || Yes || Yes || NA || Touchscreen* || ||<br />
|-<br />
| [[Lenovo ThinkPad T400]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T400s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T410]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T420]] || Yes || Yes || Yes || Yes || Yes || Yes* || Yes* || Not tested || ||<br />
|-<br />
| [[Lenovo ThinkPad T420s]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || Card Reader || See below ||<br />
|-<br />
| [[#Lenovo_ThinkPad_T440p|Lenovo ThinkPad T440p]] || Yes || Yes || Yes || Yes || Yes || Yes* || NA || Card Reader || See below ||<br />
|-<br />
| Lenovo ThinkPad T500 || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T520]] || Yes || Yes || Yes || Yes || Yes || Yes || NA || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T530]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad T550]] || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad E420s || Yes || Yes || Yes || Yes || Not tested || Yes || NA || SDcard (Yes), Webcam (Yes), Trackpoint (No) || ||<br />
|-<br />
| Lenovo ThinkPad L420 || Yes || Yes || Yes || Yes || Yes || Not tested || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad L430 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint* ||<br />
|-<br />
| Lenovo ThinkPad L530 || Yes || Yes || Yes || Yes || Yes || Yes || Yes || NA || Trackpoint*, Fingerprint reader ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E330]] || NA || Yes || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E335]] || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| ThinkPad X1 Carbon 3rd || NA || Yes || Yes || Yes || Yes || NA || Yes || NA || ||<br />
|-<br />
| [[Lenovo ThinkPad Edge E430]] || Yes || Yes || Yes* || Yes* || Not tested || Yes || NA || SD card (yes) || ||<br />
|-<br />
| [[Lenovo Thinkpad Edge E455]] || 2015.04.01 || Yes* || Yes || Yes || Yes || Yes || Yes || NA || ||<br />
|-<br />
| Lenovo ThinkPad Edge E530 || Yes || Yes || Yes* || Yes* || Yes || Yes || NA || SD card (yes), Finger Print (not tested) || ||<br />
|-<br />
|}<br />
<br />
=== B series ===<br />
<br />
{{HCL/Laptops table header}}<br />
| Lenovo B50 || NA || Yes || Yes || Yes || Yes || Not tested || Not tested || Not tested || ||<br />
|-<br />
|}<br />
<br />
== Special Notes (*): ==<br />
<br />
=== ThinkPad X1 Carbon 3rd ===<br />
<br />
* http://natalian.org/archives/2015/02/18/Archlinux_on_a_Lenovo_X1C3/<br />
<br />
=== IBM ThinkPad T21 ===<br />
<br />
* Video: <br />
** Incapable of running DRM at 1024x768 and 24-bit color due to 8 MB VRAM. Must drop color or resolution to get DRM.<br />
** For whatever reason, external VGA output (for an external monitor) was disabled. This was fixed by doing this:<br />
*** {{ic|echo 1 > /proc/acpi/video/VID/DOS}}<br />
<br />
=== Lenovo 3000 N200 ===<br />
<br />
* Sound:<br />
** You may have to append <code>options snd_hda_intel model=lenovo</code> to <code>/etc/modprobe.d/modprobe.conf</code> for sound to work.<br />
<br />
=== IBM ThinkPad R52 ===<br />
<br />
* USB network tethering<br />
** Inbound networking via interface ''usb0'' works.<br />
<br />
=== Lenovo ThinkPad T440p ===<br />
<br />
Nearly everything Just Works out of the box. Gotchas:<br />
<br />
* UEFI. gummiboot works fine, and dual-booting Windows works nicely.<br />
* ClickPad: the whole trackpad clicks, and disabling the trackpad using synclient makes the trackpoint essentially unusable.<br />
** If you don't use the trackpoint, that shouldn't be a problem.<br />
** If you ''do'' use the trackpoint, read [http://who-t.blogspot.com.au/2014/03/xorg-synaptics-support-for-lenovo-t440.html this article] (as yet untested, but the [http://who-t.blogspot.com.au/2013/12/lenovo-t440-touchpad-button.html previous version] works "fine").<br />
** There are a couple of alternative touchpad/clickpad drivers in the aur [https://aur.archlinux.org/packages/xf86-input-synlx40 here] and [https://aur.archlinux.org/packages/xf86-input-mtrack here] <br />
* Audio:<br />
** HDMI audio is the default audio output device. Consult the [[ALSA]] page for details on changing the default.<br />
** Like the X100e/Mini10, it's possible to mute the headset and speaker outputs separately to the master. Bizarrely, muting the speaker output improves bass output on the headset port.<br />
* The fingerprint sensor is a Validity VFS5011, which requires [https://github.com/abbradar/fprint_vfs5011 a patched fprintd] and is apparently highly unreliable.<br />
* thinkpad_acpi:<br />
** Controlling the Fn-Lock, Mute, Mic Mute or 'glowing I' LEDs is apparently not possible.<br />
** fan control doesn't seem to work.<br />
* Graphics and Video:<br />
** With the integrated GPU, [[xrandr]] can crash while attaching or detaching displays connected via the dock.<br />
** The built-in miniDisplayPort will sometimes spew I²C issues into the kernel log.<br />
** [[VA-API]] is highly recommended as it performs significantly better than CPU decoding of large media files.<br />
** '''The BIOS should not be upgraded past version 1.14, as newer BIOSes cause memory corruption when used with Bumblebee.''' See [https://github.com/Bumblebee-Project/bbswitch/issues/78#issuecomment-42741698 Bumblebee GitHub]<br />
* Connectivity:<br />
** Bluetooth is ''extremely'' fragile. The controller works fine most of the time, but can cause the system to wedge totally on sleep/wake cycles, especially if a connection was active at sleep. Disable the controller using {{ic|bluetoothctl}} before sleeping.<br />
<br />
=== Lenovo ThinkPad L430/L530 ===<br />
<br />
==== tpacpi-bat ====<br />
<br />
There is an issue with tpacpi-bat not reporting the right value for the stop threshold. This seems to be related to a buggy BIOS and can not be fixed application wise. <br />
<br />
See https://github.com/teleshoes/tpacpi-bat/issues/44<br />
<br />
==== Trackpoint ====<br />
<br />
{{Merge|TrackPoint}}<br />
<br />
{{Note|As of kernel 3.17, this workaround is no longer necessary, as the trackpoint fully works out of the box.}}<br />
<br />
There are some issues regarding the trackpoint on the ThinkPad L530 and L430 series. See https://bugzilla.kernel.org/show_bug.cgi?id=33292<br />
<br />
{{Warning|The following solution will remove the two-finger-scroll functionality of the touchpad}}<br />
<br />
Load the kernelmodule psmouse with the options proto=bare:<br />
<br />
# echo "options psmouse proto=bare" | sudo tee /etc/modprobe.d/trackpoint-elantech.conf <br />
<br />
To activate the scroll function, create the file {{ic|/usr/share/X11/xorg.conf.d/11-trackpoint-elantech.conf}}:<br />
<br />
{{bc|Section "InputClass"<br />
Identifier "Elantech Trackpoint"<br />
MatchProduct "PS/2 Generic Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheelTimeout" "200" <br />
Option "YAxisMapping" "4 5" # vertikales Scrollen<br />
Option "XAxisMapping" "6 7" # horizontales Scrollen<br />
EndSection}}<br />
<br />
Reload the kernelmodule, the trackpoint should now be usable:<br />
<br />
# modprobe -rv psmouse<br />
# modprobe -v psmouse <br />
<br />
{{Note|For more information see: http://wiki.ubuntuusers.de/Trackpoint#Trackpoint-wird-nicht-erkannt-nur-ThinkPad-L430-530 (German)}}<br />
<br />
== See also ==<br />
* [http://www.thinkwiki.org/wiki Think wiki]</div>Slowbrohttps://wiki.archlinux.org/index.php?title=Lenovo_ThinkPad_T550&diff=380555Lenovo ThinkPad T5502015-06-30T23:17:42Z<p>Slowbro: intial t550 page; WIP</p>
<hr />
<div>[[Category:Lenovo]]<br />
<br />
==Base System==<br />
The basic setup in [[Beginners' Guide]] works fine.<br />
<br />
==Video==<br />
===Drivers===<br />
Use {{ic|xf86-video-intel}} for graphics drivers. The T550 seems to suffer from [[Intel_graphics#Loss_of_horizontal_sync_when_switching_TTYs]] - but changing the [[Intel_graphics#SNA_issues|Graphics Acceleration to UXA]] seems to fix it.<br />
<br />
===Backlight===<br />
The backlight does not seem to respond to the Fn keys. Unable to find a reliable fix at this time. Changing via {{ic|xbacklight}} seems to work fine.</div>Slowbro