https://wiki.archlinux.org/api.php?action=feedcontributions&user=Physicist1616&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:50:20ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Ethereum&diff=494515Ethereum2017-10-30T19:50:35Z<p>Physicist1616: /* Ethereum-Go */ Fixed a command-line typo for console attach.</p>
<hr />
<div>[[Category:Cryptocurrencies]]<br />
The [https://ethereum.org/ Ethereum Project] provides an open-source, distributed, blockchain-based platform for so-called [[wikipedia:Smart contracts]].<br />
<br />
== Clients == <br />
<br />
{{Expansion|Note several implementations exist in non-/AUR packages, configuration, tips, troubleshooting etc.}}<br />
===Ethereum-Go===<br />
The Ethereum {{pkg|geth}} package is Ethereum.org's Golang implementation of their node, client, and optionally CPU Miner.<br />
<br />
Create an account with {{ic|geth account new}}.<br />
<br />
The client can be started with {{ic|geth}}, and it will proceed to download several gigabytes of blockchain data.<br />
<br />
Optionally, start the client with {{ic|geth console}} to get a JavaScript console for more meaningful interaction.<br />
This console can then be attached-to from another terminal or remotely with {{ic|geth attach [hostname:port defaults to localhost]}}.<br />
<br />
To check balances in the console or attach modes, use {{ic|web3.fromWei(eth.getBalance(eth.coinbase), "ether")}}.<br />
<br />
To start CPU mining, use {{ic|geth --mine}}. This is far less efficient than GPU mining, and ethereum.org does not recommend it.<br />
<br />
====GPU Mining with geth====<br />
{{Expansion|There is a way to make a 3rd party Ethereum miner work with geth.}}<br />
<br />
=== Ethereum Wallet ===<br />
<br />
You can install the Ethereum Wallet via the {{AUR|mist}} package or the GitHub [https://github.com/ethereum/mist/releases releases].<br />
<br />
If you use a GitHub release, download the most recent Linux one with the zip extension: {{ic|Ethereum-Wallet-linux64-''version''.zip}}; unzip the file and run {{ic|./ethereumwallet}}.<br />
<br />
If the application fails to start with {{ic|error while loading shared libraries: libgtk-x11-2.0.so: cannot open shared object file: No such file or directory}}, install the [[GTK+|GTK+ 2]] library.<br />
<br />
The wallet also implements an Ethereum node.</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&diff=494195Talk:Bitcoin2017-10-27T19:05:24Z<p>Physicist1616: /* Other Cryptocurrencies */ Commented on the storied past of this talk page.</p>
<hr />
<div>== Other Cryptocurrencies ==<br />
<br />
I noticed this is the only real and complete page on any cryptocurrency in the Arch Wiki, perhaps with a bit too much information. Maybe it needs a split or more generalities?<br />
<br />
More importantly, from the perspective of OS Users, it seems like we might be better served by something that addresses cryptocurrencies as a whole, or maybe 2 pages: Cryptocurrency Mining and Cryptocurrency User/Trading that delves into setup of each of the roles for each currency in Arch. I suspect this could eventually split into pages per currency. Discussion? [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 00:03, 24 October 2017 (UTC)<br />
<br />
:Which cryptocurrencies do you have in mind? Note that most of the previous discussions lead to [https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&action=history flame wars], so let's avoid that. Any controversial topic will simply not be covered on this wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:59, 24 October 2017 (UTC)<br />
<br />
::Bitcoin (Obviously, but also ASIC miners and the main intermediary currency), Ethereum (GPU miners and recently successful), and Monero (CPU miners and allegedly more focused on privacy than others). I'm not shilling for any of those and so would be fine discussing an alternative to any or adding more to the list. The diversity in how each of those three are mined attracted me. <s>I can't imagine what flame wars could happen other than, "mine is better than yours". Perhaps that's just a failure of imagination.</s> Ok, read the history; yeah, philosophy doesn't belong here, nor does excess detail on how and why or where BTC is going/splitting/etc. This is an OS wiki. [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 16:58, 27 October 2017 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&diff=494189Talk:Bitcoin2017-10-27T16:58:40Z<p>Physicist1616: /* Other Cryptocurrencies */ Signing a coment.</p>
<hr />
<div>== Other Cryptocurrencies ==<br />
<br />
I noticed this is the only real and complete page on any cryptocurrency in the Arch Wiki, perhaps with a bit too much information. Maybe it needs a split or more generalities?<br />
<br />
More importantly, from the perspective of OS Users, it seems like we might be better served by something that addresses cryptocurrencies as a whole, or maybe 2 pages: Cryptocurrency Mining and Cryptocurrency User/Trading that delves into setup of each of the roles for each currency in Arch. I suspect this could eventually split into pages per currency. Discussion? [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 00:03, 24 October 2017 (UTC)<br />
<br />
:Which cryptocurrencies do you have in mind? Note that most of the previous discussions lead to [https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&action=history flame wars], so let's avoid that. Any controversial topic will simply not be covered on this wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:59, 24 October 2017 (UTC)<br />
<br />
::Bitcoin (Obviously, but also ASIC miners and the main intermediary currency), Ethereum (GPU miners and recently successful), and Monero (CPU miners and allegedly more focused on privacy than others). I'm not shilling for any of those and so would be fine discussing an alternative to any or adding more to the list. The diversity in how each of those three are mined attracted me. I can't imagine what flame wars could happen other than, "mine is better than yours". Perhaps that's just a failure of imagination. [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 16:58, 27 October 2017 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&diff=494188Talk:Bitcoin2017-10-27T16:58:07Z<p>Physicist1616: /* Other Cryptocurrencies */ Elaborated on more currencies.</p>
<hr />
<div>== Other Cryptocurrencies ==<br />
<br />
I noticed this is the only real and complete page on any cryptocurrency in the Arch Wiki, perhaps with a bit too much information. Maybe it needs a split or more generalities?<br />
<br />
More importantly, from the perspective of OS Users, it seems like we might be better served by something that addresses cryptocurrencies as a whole, or maybe 2 pages: Cryptocurrency Mining and Cryptocurrency User/Trading that delves into setup of each of the roles for each currency in Arch. I suspect this could eventually split into pages per currency. Discussion? [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 00:03, 24 October 2017 (UTC)<br />
<br />
:Which cryptocurrencies do you have in mind? Note that most of the previous discussions lead to [https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&action=history flame wars], so let's avoid that. Any controversial topic will simply not be covered on this wiki. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:59, 24 October 2017 (UTC)<br />
<br />
::Bitcoin (Obviously, but also ASIC miners and the main intermediary currency), Ethereum (GPU miners and recently successful), and Monero (CPU miners and allegedly more focused on privacy than others). I'm not shilling for any of those and so would be fine discussing an alternative to any or adding more to the list. The diversity in how each of those three are mined attracted me. I can't imagine what flame wars could happen other than, "mine is better than yours". Perhaps that's just a failure of imagination.</div>Physicist1616https://wiki.archlinux.org/index.php?title=Ethereum&diff=493950Ethereum2017-10-24T00:31:57Z<p>Physicist1616: /* Clients */ Added basic use information for getting started with geth.</p>
<hr />
<div>[[Category:Cryptocurrencies]]<br />
The [https://github.com/ethereum/go-ethereum Ethereum] project provides an open-source, distributed, blockchain-based platform for so-called [[wikipedia:Smart contracts]].<br />
<br />
== Clients == <br />
<br />
{{Expansion|Note several implementations exist in non-/AUR packages, configuration, tips, troubleshooting etc.}}<br />
===Ethereum-Go===<br />
The Ethereum `geth` package is Ethereum.org's Golang implemenation of their node, client, and optionally CPU Miner.<br />
<br />
Create an account with `geth account new`.<br />
<br />
The client can be started with `geth`, and it will proceed to download several gigabytes of blockchain data.<br />
<br />
Optionally, start the client with `geth console` to get a javascript console for more meaningful interaction. This console can then be attached-to from another terminal or remotely with `geth attach [hostname:port | defaults to localhost]`.<br />
<br />
To check balances in the console or attach modes, use `web3.fromWei(eth.getBalance(eth.coinbase), "ether")`.<br />
<br />
To start CPU mining, use `geth --mine`. This is far less efficient than GPU mining, and ethereum.org doesn't recommend it.<br />
<br />
====GPU Mining with geth====<br />
{{Expansion|There is a way to make a 3rd party Ethereum miner work with geth.}}<br />
<br />
=== Ethereum Wallet ===<br />
<br />
You can install the Ethereum Wallet via the {{AUR|mist}} package or the GitHub [https://github.com/ethereum/mist/releases releases].<br />
<br />
If you use a GitHub release, download the most recent Linux one with the zip extension: {{ic|Ethereum-Wallet-linux64-''version''.zip}}; unzip the file and run {{ic|./ethereumwallet}}.<br />
<br />
If the application fails to start with {{ic|error while loading shared libraries: libgtk-x11-2.0.so: cannot open shared object file: No such file or directory}}, install the [[GTK+|GTK+ 2]] library.<br />
<br />
The wallet also implements an Ethereum node.</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:Bitcoin&diff=493949Talk:Bitcoin2017-10-24T00:03:01Z<p>Physicist1616: /* Other Cryptocurrencies */ new section</p>
<hr />
<div>== Other Cryptocurrencies ==<br />
<br />
I noticed this is the only real and complete page on any cryptocurrency in the Arch Wiki, perhaps with a bit too much information. Maybe it needs a split or more generalities?<br />
<br />
More importantly, from the perspective of OS Users, it seems like we might be better served by something that addresses cryptocurrencies as a whole, or maybe 2 pages: Cryptocurrency Mining and Cryptocurrency User/Trading that delves into setup of each of the roles for each currency in Arch. I suspect this could eventually split into pages per currency. Discussion? [[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 00:03, 24 October 2017 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:QEMU&diff=483734Talk:QEMU2017-08-03T19:32:32Z<p>Physicist1616: /* -enable-kvm vs -machine type=pc,accel=kvm */ Bumbing discussion</p>
<hr />
<div>== Linear RAID ==<br />
<br />
When I was updating the article yesterday, I had tried to fit the section about linear raid (boot a VM from a partition by prepending a MBR to it) into the article better. But I'm not sure the technique described is the right one at all. It looks like it works, but wouldn't it be easier to install a bootloader directly to the partition (e.g. syslinux)? Then the VM could be booted directly from the partition simply by using it as its virtual disk.<br />
--[[User:Synchronicity|Synchronicity]] ([[User talk:Synchronicity|talk]]) 19:23, 9 May 2012 (UTC)<br />
<br />
:What about Windows installations then? [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:18, 4 October 2016 (UTC)<br />
<br />
== Creating bridge manually ==<br />
<br />
I really don't know what to do with this section. I'd say it has been superseded by [[QEMU#Creating bridge using qemu-bridge-helper]] (available since qemu-1.1, we now have qemu-1.5) - or is someone still using this method? Perhaps link to https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces or http://wiki.qemu.org/Documentation/Networking/NAT is sufficient. What do you think? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:42, 22 July 2013 (UTC)<br />
<br />
:Actually, I've become a happy user of this method. I've written some scripts to easily create bridge interface, TAP interface, and combined with Xyne's [http://xyne.archlinux.ca/notes/network/dhcp_with_dns.html excellent scripts] to set up NAT and launch DHCP server, I have complete solution to easily manage multiple VMs on one (or even more) bridge.<br />
:My scripts are available on github: [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-launcher.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-tap-helper.sh], [https://github.com/lahwaacz/archlinux-dotfiles/blob/master/Scripts/qemu-mac-hasher.py] but I won't probably integrate them into the wiki, I'l just leave a note when I do some more testing.<br />
:The thing is, what to do with the current content? Personally I think that links to [https://en.wikibooks.org/wiki/QEMU/Networking#TAP_interfaces], [http://wiki.qemu.org/Documentation/Networking/NAT] and my scripts are sufficient (of course others are welcome). I'd also leave the note at the end to ''disable the firewall on the bridge'', I find it extremely useful.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:24, 5 September 2013 (UTC)<br />
<br />
:I would not remove something that works still heh.--[[User:Webdawg|Webdawg]] ([[User talk:Webdawg|talk]]) 07:31, 17 July 2016 (UTC)<br />
<br />
== Starting QEMU virtual machines with systemd ==<br />
The custom systemd service script does not work. It always fails with {{ic|Failed at step EXEC spawning /usr/bin/qemu-{type}: No such file or directory}}. To Fix this modify the ExecStart command {{bc|1=ExecStart=/usr/bin/sh -c "/usr/bin/qemu-${type} -name %i -nographic ${args}"}}<br />
Also {{ic|echo 'system_powerdown' &#124; nc localhost 7101}} kills the VM immediatly. To fix this change the stop script. It simply checks each second if the main process is still running. {{bc|1=ExecStop=/usr/bin/sh -c "${haltcmd} && while [[ $(pidof qemu-${type} | grep $MAINPID) ]]; do sleep 1; done"}}<br />
{{ic|gnu-netcat}} does not work to connect to the monitor. You need to use {{ic|openbsd-netcat}}. -- [[User:Ant32|Ant32]] ([[User talk:Ant32|talk]]) 17:48, 5 September 2013 (UTC)<br />
<br />
:The first problem related to starting the service seems rather strange - didn't you have typo error in your local {{ic|qemu@.service}} file (missing the dollar sign {{ic|$}} in {{ic|${type} }})?<br />
:The second problem is valid, systemd kills the main process when the ExecStop command exits (see {{ic|systemd.service(5)}}). If your workaround really works, it could be added to the wiki with a proper description.<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:17, 7 September 2013 (UTC)<br />
<br />
::Relevant thread on systemd-devel mailing list: [http://lists.freedesktop.org/archives/systemd-devel/2013-September/012982.html] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 00:00, 15 September 2013 (UTC)<br />
<br />
== Kexec Hackery When Using a Real Partition ==<br />
<br />
After banging my head against a wall long enough and figuring out what {{ic|-kernel}} and {{ic|-initrd}} were really calling, I put a note above the appropriate section and mentioned two ways to use the guest's images. (Otherwise, you'll have to worry if the host and guest images match.) The first -- mount the partition(s) -- is more appropriate for "low-volume-handling" of VMs. The second -- using kexec -- becomes more useful when you're juggling more than a few VMs.<br />
<br />
I'm only mentioning this hack because (as of now) [[Kexec]] only mentions use for rebooting into another kernel, not switching out the kernel before the system is even up. This hack comes from from https://digitalocean.uservoice.com/forums/136585-digitalocean/suggestions/2814988-give-option-to-use-the-droplet-s-own-bootloader- which has two suggestions. The most recent, using systemd units by jkuan, doesn't work because jkuan tried to copy a {{ic|.target}} file into a {{ic|.service}} file and systemd wants {{ic|ExecStart}} in a {{ic|.service}} file. The second one, replacing {{ic|/usr/bin/init}} by andrew_sparks, works for me on my Arch instance at DigitalOcean.<br />
<br />
Adaptation from said post:<br />
<br />
# pacman -S kexec-tools<br />
# pacman -R systemd-sysvcompat<br />
<br />
{{hc|1=/tmp/init|2=<br />
#!/bin/sh<br />
<br />
kexec --load /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --append="root=/dev/sda init=/usr/lib/systemd/systemd" &&<br />
mount -o ro,remount / && kexec -e<br />
exec /usr/lib/systemd/systemd<br />
}}<br />
<br />
# cd [/path/to/vm]/usr/bin<br />
# mv init init.dist<br />
# cp /tmp/init ./<br />
# chmod 755 init<br />
<br />
I'm leaving this on the Talk page as I haven't even tried it out in QEMU myself. Also, my eyes are about ready to pop out of my head, so I'm barring myself from figuring out the appropriate way to edit this in for the time being. [[User:BrainwreckedTech|BrainwreckedTech]] ([[User talk:BrainwreckedTech|talk]]) 21:23, 14 January 2014 (UTC)<br />
<br />
== Replace -net with -netdev ==<br />
<br />
The {{ic|-net}} option is deprecated and replaced by {{ic|-netdev}}. I think this article should be modified to reflect that.<br />
http://en.wikibooks.org/wiki/QEMU/Networking#cite_ref-1<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 18:12, 1 July 2014 (UTC)<br />
<br />
:Yes {{ic|-net}} is the old syntax as stated in [https://wiki.gentoo.org/wiki/QEMU/Options#Pass-through Gentoo's Wiki] where we should use {{ic|1=-netdev user,id=vmnic -device virtio-net,netdev=vmnic}} [[User:Pickfire|Pickfire]] ([[User talk:Pickfire|talk]]) 04:11, 31 March 2017 (UTC)<br />
<br />
== I'm rewriting the network section ==<br />
<br />
https://wiki.archlinux.org/index.php/User:Axper/sandbox/qemu_network<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 20:07, 2 July 2014 (UTC)<br />
<br />
::I think a lot of networking topics could be moved outside of the QEMU page. Many virtualization applications share the same basic principles with regards to networking, such as tun/tap creating, bridges, VDE, etc. There are a few networking schemes that are QEMU-specific, for example multicast sockets and {{ic|-net socket,...}}, and these could be mentioned on the QEMU page, although these are less reliable and rarely used in comparison to tap devices. We should also of course note the QEMU-specific command line options in the QEMU page, but for general concepts and commands independent of the virtualization applications, they could go on pages dedicated to the task. The best example is VDE, which is in no way limited to QEMU, yet it still doesn't have its own page on the Arch wiki.<br />
<br />
::Incidentally, I'm planning on rewriting [[User Mode Linux]] (yes, I promise I will get around to it), which happens to share the "tap with bridge" and VDE concepts with QEMU. It would be nice if I could link to pages dedicated to those topics and only write UML-specific commands in the page, instead of duplicating a bunch of general information. I'm not familiar very familiar with Xen or LXC or Docker or the like, but I would suspect that they also share some networking infrastructure. We could possibly even create a category just for these types of pages, for example "Virtual Networking" or "Advanced Networking". [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 13:32, 19 February 2015 (UTC)<br />
<br />
== -enable-kvm vs -machine type=pc,accel=kvm ==<br />
<br />
The section [[QEMU#Enabling_KVM]] recommends {{ic|-enable-kvm}}, while [[QEMU#Virtual_machine_runs_too_slowly]] recommends {{ic|1=-machine type=pc,accel=kvm}}. Is there any difference between the two? Is one preferred over the other? Should we just link to the former section from the latter (and possibly move both command line switches to the same section)? [[User:EscapedNull|EscapedNull]] ([[User talk:EscapedNull|talk]]) 17:23, 18 January 2015 (UTC)<br />
<br />
:2.5 years later... Has anyone found an answer to the question of `-enable-kvm` VS `-machine type=pc,accel=kvm`? -[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 19:32, 3 August 2017 (UTC)<br />
<br />
== virtio-gpu ==<br />
<br />
Any tutorial on using the new virtio-gpu which is introduced in qemu-2.4 and kernel 4.2? [[User:Adam900710|Adam900710]] ([[User talk:Adam900710|talk]]) 02:44, 19 August 2015 (UTC)<br />
<br />
:Should be "plug and play" with recent kernel and other packages: [https://www.kraxel.org/blog/2016/09/using-virtio-gpu-with-libvirt-and-spice/ article]. The article is about libvirt, but I've run Arch guest on Arch host successfully with qemu script. [[User:Nesk|Nesk]] ([[User talk:Nesk|talk]]) 09:24, 4 October 2016 (UTC)<br />
<br />
== host only networking ==<br />
<br />
I added a quick and easy method but it was deleted. I found errors in what is here. Is it worth my time to correct them or will they be deleted? {{unsigned|16:39, 4 January 2016|Netskink}}<br />
<br />
:You are welcome to make any corrections. Nobody can tell you if they will be kept or reverted beforehand, but if you're afraid to waste your time feel free to just point them out using an [[Help:Template|Article status templates|article status template]] (should be less time consuming). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:28, 21 February 2016 (UTC)<br />
<br />
== Windows 7 specific issues ==<br />
<br />
I have noticed that for me, any attempts at installing Windows 7 using qemu with virt-manager as a frontend stalls on "Starting Windows." This is immediately after booting the computer for the first time. In Virt-manager, I am able to change the Display from QXL to Cirrus to fix the issue. I'm not sure if this applies to this page in particular, but if so, might be worth adding to the "Troubleshooting" section -- [[User:Ephreal|Ephreal]] ([[User talk:Ephreal|talk]]) 14:25, 10 August 2016 (UTC)<br />
<br />
== Using existing partition on GPT disk (with linear RAID or otherwise) ==<br />
<br />
[https://wiki.archlinux.org/index.php/QEMU#Simulate_virtual_disk_with_MBR_using_linear_RAID Section on using existing partition] is pretty awesome, but it is MBR-specific. Can someone with enough knowledge create a similar section about GPT disk please?</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:Simple_stateful_firewall&diff=483502Talk:Simple stateful firewall2017-08-01T23:19:07Z<p>Physicist1616: /* iptables CT target */ new section</p>
<hr />
<div>== Question about section "Protection against spoofing attacks" ==<br />
The rule when rp_filter is 0 checks the source address.<br />
Previously I only read about checking the destination address with the comment "Reject external connections '''for''' internal networks".<br /><br />
As I'm still a network/firewall newbie I cannot distinguish what is correct or if both are needed?<br />
-I INPUT ! -i lo '''-d''' 127.0.0.0/8 -j DROP<br />
Same for the "IPv6" section.<br />
<br />
[[User:Maddes.b|Maddes.b]] ([[User talk:Maddes.b|talk]]) 16:39, 26 August 2014 (UTC)<br />
<br />
== ICMP rate limiting considered harmful ==<br />
I'd say that the ping rate limiter has little value. Processing those takes little effort for the kernel, especially compared to TCP. Anyhow, if you want to do proper traffic control, use tc, and look at queuing disciplines instead of arbitrary rate limits which may only be ephemerally valid and not applicable to most people.<br />
<br />
I'm considering removing it soon.<br />
<br />
[[User:Alp|Alp]] ([[User talk:Alp|talk]]) 16:26, 18 February 2015 (UTC)<br />
<br />
:I guess you refer to [[Simple_stateful_firewall#Block_ping_request]]? I agree, but instead of removing it I would find it more useful if you would rephrase the intro of the section to account for your arguments (it already says "You should only do this for education purposes."). tc easily is overkill/off-track for most readers of this article. What do you think? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 17:22, 18 February 2015 (UTC)<br />
<br />
:I have reread it and changed my mind. Added [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&diff=368993&oldid=368980] to this item. The one part we should take care it is covered elsewhere appropriately before deleting is the paragraph that explains where to put the rule (before or after RELATED,ESTABLISHED). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:04, 8 April 2015 (UTC)<br />
<br />
== ICMP blocking ==<br />
<br />
I am not an expert, but for example according to [http://serverfault.com/questions/84963/why-not-block-icmp#answer-84981 this post on Serverfault] blocking ICMP in general is not a good idea. Especially for IPv6 it, ICMP, is quite important.<br />
Unfortunately I have no IPv6 address at home (and am too lazy to set up my own router, with 6to4), but my Debian VPS was unable to get proper ping-replies on IPv6 with the provided rule.<br />
<br />
Hence, I would suggest the following rules:<br />
-A INPUT -p {,ipv6-}icmp -j ACCEPT<br />
<br />
[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 13:01, 30 March 2016 (UTC)<br />
<br />
:I think you have a point there. We should at least need an additional rule like <br />
: # ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 129 -j ACCEPT<br />
:since ipv6 has a separate type (129) for echo-replies. Can you test, if your VPS gets the replies if you add this one? <br />
:Maybe some more are useful (should not be related to your problem though), e.g. <br />
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type destination-unreachable -j ACCEPT<br />
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT<br />
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type time-exceeded -j ACCEPT<br />
:# ip6tables -A INPUT -p icmpv6 --icmpv6-type parameter-problem -j ACCEPT<br />
:([https://www.cert.org/downloads/IPv6/ip6tables_rules.txt source]) --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:56, 30 March 2016 (UTC)<br />
<br />
::IPv4 does also have a separate echo-reply type, see `iptables -p icmp -h'. I initially thought the reply should be accepted as ESTABLISHED,RELATED by the first rule, however this appears to be wrong.<br />
::I have experimented a little, which was not simplified by the fact that the rules are apparently not immediately applied by `ip6tables-restore', and found out that allowing type 128, 129 and the ones you specified above, without state restriction, does not help, however the followig does (with no other ICMP rule in effect):<br />
::{{bc|<nowiki>-A INPUT -p ipv6-icmp -m state --state UNTRACKED -j ACCEPT</nowiki>}}<br />
::I might try to narrow it down further, however I still do not think that one should block ICMP at all. Are there any serious security concerns?<br />
::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 17:13, 30 March 2016 (UTC)<br />
<br />
:::Thanks for the quick feedback. I share your 'technical position' with respect to ipv6 unavailability at current. In general I am strongly in favour of allowing icmp in general; it's a backbone of efficient packet handling. Thing for ipv6 is, though, that a lot more is handled with it. See the limits for router-solicitation etc in the source file I linked for example. I.e. an "untracked" remote system can learn a lot more about your network topology with ipv6-icmp than ever was the case for ipv4 pings. If you get certain by looking into it, please share references and go ahead to add to the existing right away. Otherwise I suggest we take our time to look into it, perhaps other replies come, or direct edits which bring the section further. I have added [https://wiki.archlinux.org/index.php?title=Simple_stateful_firewall&type=revision&diff=428750&oldid=422671] for that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:08, 30 March 2016 (UTC)<br />
<br />
::::Just to add some information, the corresponding RFC can be found [https://tools.ietf.org/html/rfc4443 here]. I will hopefully find the time to look into it and possibly other documents.<br />
::::In general, if we intend to add more specific rules, I would suggest creating a separate ICMP chain for it. -- [[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 18:44, 30 March 2016 (UTC)<br />
<br />
== Suggest opening incoming TCP connections on port 53 for the DNS server in addition to UDP? ==<br />
<br />
In the 'Opening portsfor inncoming connections' sub-section there is suggestion on accepting "Incoming UDP streams on port 53 for DNS server". After I did that I also had to open TCP in similar fashion, otherwise the server would fail the test (it's part of the OpenNIC infrastructure, they have a tool to test the server through their web interface). My question is, should that extra rule for TCP connections be added to the wiki article?<br />
<br />
I was going to add '''''iptables -A TCP -p tcp --dport 53 -j ACCEPT'''''<br />
<br />
--[[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 09:35, 1 July 2017 (UTC)<br />
<br />
:Sounds reasonable. Go ahead.<br />
:It might be noted, however, that those examples listed are nothing but examples. Anybody running a DNS server should know, which ports to open.<br />
:[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 12:57, 1 July 2017 (UTC)<br />
<br />
::Done.<br />
::How about a note saying: "The following rules are nothing but examples, make sure they match your particular setup before implementing any of the ''suggestions'' below." on top of that section?<br />
::--[[User:Soocki|Soocki]] ([[User talk:Soocki|talk]]) 14:52, 1 July 2017 (UTC)<br />
<br />
:::Well, I think the current ''Note'' should suffice.<br />
:::I just wanted to somehow relativate my former statement, i.e. to say, that there is no need to cover every use case.<br />
:::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 15:30, 1 July 2017 (UTC)<br />
<br />
:[https://en.wikipedia.org/wiki/Domain_Name_System#Protocol_transport Wikipedia says], that DNS uses the TCP protocol only for responses (which are not to/from port 53) and only if the response size is too big. If OpenNIC relies on the TCP port 53, it's specific to their test and hence inappropriate for this general page. I'll undo the change. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:01, 1 July 2017 (UTC)<br />
<br />
::To me, this is not obvious from the Wikipedia entry. In contrast, [https://tools.ietf.org/html/rfc7766#page-6 RFC7766] states "Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons." and "In addition, it is noted that all recursive and authoritative servers MUST send responses using the same transport as the query arrived on."<br />
::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 22:50, 1 July 2017 (UTC)<br />
<br />
:::To me that part still sounds like talking about the responses, i.e. what the resolver sends back. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:11, 2 July 2017 (UTC)<br />
<br />
::::The (stub) resolver is the client. I.e. it speaks first. Hence, I understand the quoted statements as demanding a nameserver to accept and reply to TCP queries (using TCP). Also, it is stated: "TCP MAY be used before sending any UDP queries." By the way, dig(1) has an option `+tcp'.<br />
::::[[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 21:26, 2 July 2017 (UTC)<br />
<br />
::::Due to no further reply, I have reverted the change now. -- [[User:Respiranto|Respiranto]] ([[User talk:Respiranto|talk]]) 12:16, 9 July 2017 (UTC)<br />
<br />
== iptables CT target ==<br />
<br />
Found this in dmesg:<br />
<br />
[15393.042447] nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.<br />
<br />
Does this mean "-m conntrack" is deprecated in favor of something like "-j CT"?<br />
<br />
(Disclaimer, ran across this in Ubuntu's logs when using this guide; just say so if it's Ubuntu doing dumb things)<br />
[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 23:19, 1 August 2017 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=473696Arch boot process2017-04-11T18:34:13Z<p>Physicist1616: /* Getty */ Odd formatting issue fixed.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-hans:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
A BIOS or Basic Input-Output System is the very first program (firmware) that is executed once the system is switched on. In most cases it is stored in a flash memory in the motherboard itself and independent of the system storage. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
UEFI has support for reading both the partition table as well as understanding filesystems. Hence it is not limited by 440 byte code limitation (MBR boot code) as in BIOS systems. It does not use the MBR boot code at all.<br />
<br />
The commonly used UEFI firmwares support both MBR and GPT [[partition table]]. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called '''EFI System Partition''' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI System Partition without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one [[boot loader]] to load another OS.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/passwd}} and {{ic|/etc/shadow}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=473695Arch boot process2017-04-11T18:33:05Z<p>Physicist1616: /* Getty */ Ok, it checks both.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-hans:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
A BIOS or Basic Input-Output System is the very first program (firmware) that is executed once the system is switched on. In most cases it is stored in a flash memory in the motherboard itself and independent of the system storage. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
UEFI has support for reading both the partition table as well as understanding filesystems. Hence it is not limited by 440 byte code limitation (MBR boot code) as in BIOS systems. It does not use the MBR boot code at all.<br />
<br />
The commonly used UEFI firmwares support both MBR and GPT [[partition table]]. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called '''EFI System Partition''' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI System Partition without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one [[boot loader]] to load another OS.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/passwd}}<br />
and {{ic|/etc/shadow}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Arch_boot_process&diff=473694Arch boot process2017-04-11T18:31:54Z<p>Physicist1616: /* Getty */ Getty checks against /etc/shadow, not /etc/passwd.</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:About Arch]]<br />
[[ar:Arch boot process]]<br />
[[cs:Arch boot process]]<br />
[[es:Arch boot process]]<br />
[[fr:Processus de boot]]<br />
[[it:Arch boot process]]<br />
[[ja:Arch ブートプロセス]]<br />
[[ru:Arch boot process]]<br />
[[zh-hans:Arch boot process]]<br />
{{Related articles start}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|mkinitcpio}}<br />
{{Related|init}}<br />
{{Related|systemd}}<br />
{{Related|fstab}}<br />
{{Related|Autostarting}}<br />
{{Related articles end}}<br />
<br />
In order to boot Arch Linux, a Linux-capable [[boot loader]] such as [[GRUB]] or [[Syslinux]] must be installed to the [[Master Boot Record]] or the [[GUID Partition Table]]. The boot loader is responsible for loading the kernel and [[initial ramdisk]] before initiating the boot process. The procedure is quite different for [[Wikipedia:BIOS|BIOS]] and [[UEFI]] systems, the detailed description is given on this or linked pages.<br />
<br />
== Firmware types ==<br />
=== BIOS ===<br />
<br />
A BIOS or Basic Input-Output System is the very first program (firmware) that is executed once the system is switched on. In most cases it is stored in a flash memory in the motherboard itself and independent of the system storage. <br />
<br />
The BIOS loads the beginning 512 bytes ([[Master Boot Record]]) of the first valid disk in the BIOS disk order. Of these 512 bytes, the first 440 contains the first stage of a boot loader like [[GRUB]], [[Syslinux]] or [[LILO]]. Since very little can be achieved by a program of this size, the second stage (residing on the next disk sectors) is loaded from here and looks up a file stored on the partition itself (the actual bootloader). This then loads an operating system by either chain-loading or directly loading the operating system kernel.<br />
<br />
=== UEFI ===<br />
UEFI has support for reading both the partition table as well as understanding filesystems. Hence it is not limited by 440 byte code limitation (MBR boot code) as in BIOS systems. It does not use the MBR boot code at all.<br />
<br />
The commonly used UEFI firmwares support both MBR and GPT [[partition table]]. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Intel Macs can also access HFS/HFS+ filesystems, in addition to the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called '''EFI System Partition''' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32 or (less commonly) FAT16.<br />
<br />
== System initialization ==<br />
<br />
=== Under BIOS ===<br />
<br />
# System switched on - [[Wikipedia:Power-on self-test|Power-on self-test]] or POST process<br />
# After POST, BIOS initializes the necessary system hardware for booting (disk, keyboard controllers etc.)<br />
# BIOS launches the first 440 bytes ([[Master Boot Record]]) of the first disk in the BIOS disk order<br />
# The MBR boot code then takes control from BIOS and launches its next stage code (if any) (mostly [[boot loader]] code)<br />
# The launched actual boot loader<br />
<br />
=== Under UEFI ===<br />
<br />
# System switched on. The Power On Self Test (POST) is executed.<br />
# UEFI firmware is loaded. Firmware initializes the hardware required for booting.<br />
# Firmware reads the boot entries in the firmware's boot manager to determine which UEFI application to be launched and from where (i.e. from which disk and partition).<br />
# Firmware launches the UEFI application.<br />
#* This could be the Arch kernel itself (since [[EFISTUB]] is enabled by default).<br />
#* It could be some other application such as a shell or a graphical boot manager.<br />
#* Or the boot entry could simply be a disk. In this case the firmware looks for an [[EFI System Partition]] on that disk and tries to run the fallback UEFI application {{ic|\EFI\BOOT\BOOTX64.EFI}} ({{ic|BOOTIA32.EFI}} on 32-bit systems). This is how UEFI bootable thumb drives work.<br />
<br />
If [[Secure Boot]] is enabled, the boot process will verify authenticity of the EFI binary by signature.<br />
<br />
{{Note|On some (poorly-designed) UEFI systems the only way to boot is using a disk boot entry with the fallback UEFI application path.}}<br />
<br />
=== Multibooting in UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI System Partition without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one [[boot loader]] to load another OS.<br />
<br />
See also [[Dual boot with Windows]].<br />
<br />
== Boot loader ==<br />
<br />
The boot loader is the first piece of software started by the [[Wikipedia:BIOS|BIOS]] or [[UEFI]]. It is responsible for loading the kernel with the wanted [[kernel parameters]], and [[mkinitcpio|initial RAM disk]] based on config files. <br />
<br />
== Kernel ==<br />
The kernel is the core of an operating system. It functions on a low level (''kernelspace'') interacting between the hardware of the machine and the programs which use the hardware to run. To make efficient use of the CPU, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion of many tasks being executed simultaneously.<br />
<br />
== initramfs ==<br />
After the kernel is loaded, it unpacks the [[initramfs]] (initial RAM filesystem), which becomes the initial root filesystem. The kernel then executes {{ic|/init}} as the first process. The ''early userspace'' starts.<br />
<br />
The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem (see [[FHS]] for details). This means that any modules that are required for devices like IDE, SCSI, SATA, USB/FW (if booting from an external drive) must be loadable from the initramfs if not built into the kernel; once the proper modules are loaded (either explicitly via a program or script, or implicitly via [[udev]]), the boot process continues. For this reason, the initramfs only needs to contain the modules necessary to access the root filesystem; it does not need to contain every module one would ever want to use. The majority of modules will be loaded later on by udev, during the init process.<br />
<br />
== Init process ==<br />
At the final stage of early userspace, the real root is mounted, and then replaces the initial root filesystem. {{ic|/sbin/init}} is executed, replacing the {{ic|/init}} process. Arch uses [[systemd]] as the default [[init]].<br />
<br />
== Getty ==<br />
[[init]] calls [[getty]] once for each [[Wikipedia:Virtual console|virtual terminal]] (typically six of them), which initializes each tty and asks for a username and password. Once the username and password are provided, getty checks them against {{ic|/etc/shadow}}, then calls [[#Login|login]], which begins a session for the user, and executes the user's shell according to {{ic|/etc/passwd}}. Alternatively, getty may start a display manager if one is present on the system.<br />
<br />
== Display Manager ==<br />
A [[display manager]] can be configured to replace the getty login prompt on a tty.<br />
<br />
== Login ==<br />
The ''login'' program begins a session for the user by setting environment variables and starting the user's shell, based on {{ic|/etc/passwd}}.<br />
<br />
=== Message of the day ===<br />
<br />
The ''login'' program displays the contents of [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) after a successful login, just before it executes the login shell.<br />
<br />
It is a good place to display your Terms of Service to remind users of your local policies or anything you wish to tell them.<br />
<br />
== Shell ==<br />
Once the user's [[shell]] is started, it will typically run a runtime configuration file, such as [[bashrc]], before presenting a prompt to the user. If the account is configured to [[Start X at login]], the runtime configuration file will call [[startx]] or [[xinit]].<br />
<br />
== xinit ==<br />
[[xinit]] runs the user's [[xinitrc]] runtime configuration file, which normally starts a [[window manager]]. When the user is finished and exits the window manager, xinit, startx, the shell, and login will terminate in that order, returning to getty.<br />
<br />
== See also ==<br />
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]<br />
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]<br />
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]<br />
* [[Wikipedia:Linux startup process]]<br />
* [[Wikipedia:initrd]]<br />
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]<br />
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=403664Mkinitcpio2015-10-07T17:08:28Z<p>Physicist1616: /* Image creation and activation */ Clarified mkinitcpio.conf editing is what makes you need to regenerate the image, not bootloader editing.</p>
<hr />
<div>{{DISPLAYTITLE:mkinitcpio}}<br />
[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[da:Mkinitcpio]]<br />
[[de:Mkinitcpio]]<br />
[[es:Mkinitcpio]]<br />
[[fr:mkinitcpio]]<br />
[[it:Mkinitcpio]]<br />
[[ja:Mkinitcpio]]<br />
[[ru:Mkinitcpio]]<br />
[[zh-CN:Mkinitcpio]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Kernel modules}}<br />
{{Related articles end}}<br />
'''mkinitcpio''' is the next generation of [[Wikipedia:initrd|initramfs]] creation.<br />
<br />
== Overview ==<br />
mkinitcpio is a Bash script used to create an initial ramdisk environment. From the [https://projects.archlinux.org/mkinitcpio.git/tree/man/mkinitcpio.8.txt mkinitcpio man page]:<br />
<br />
:''The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root file systems and root file systems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.''<br />
<br />
Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the [[boot process]] before mounting the root file system and passing control to {{ic|init}}. However, as technology advances, these tasks have become increasingly complex. <br />
<br />
Nowadays, the root file system may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root file system may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. <br />
<br />
See also: [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 &raquo; Blog Archive &raquo; Early Userspace in Arch Linux].<br />
<br />
mkinitcpio is a modular tool for building an initramfs CPIO image, offering many advantages over alternative methods; these advantages include:<br />
<br />
* The use of [http://www.busybox.net/ BusyBox] to provide a small and lightweight base for early userspace.<br />
* Support for '''[[udev]]''' for hardware auto-detection at runtime, thus preventing the loading of unnecessary modules.<br />
* Using an extendable hook-based init script, which supports custom hooks that can easily be included in [[pacman]] packages.<br />
* Support for '''LVM2''', '''dm-crypt''' for both legacy and LUKS volumes, '''mdadm''', and '''swsusp''' and '''suspend2''' for resuming and booting from USB mass storage devices.<br />
* The ability to allow many features to be configured from the kernel command line without needing to rebuild the image.<br />
<br />
mkinitcpio has been developed by the Arch Linux developers and from community contributions. See the [https://projects.archlinux.org/mkinitcpio.git/ public Git repository].<br />
<br />
== Installation ==<br />
The {{Pkg|mkinitcpio}} package is available in the [[official repositories]] and is a dependency of the {{Pkg|linux}} package.<br />
<br />
Advanced users may wish to install the latest development version of mkinitcpio from Git:<br />
<nowiki>$ git clone git://projects.archlinux.org/mkinitcpio.git</nowiki><br />
<br />
{{Note|It is '''highly''' recommended that you follow the [https://mailman.archlinux.org/mailman/listinfo/arch-projects arch-projects mailing list] if you use mkinitcpio from Git!}}<br />
<br />
== Image creation and activation ==<br />
By default, the mkinitcpio script generates two images after kernel installation or upgrades: {{ic|/boot/initramfs-linux.img}} and {{ic|/boot/initramfs-linux-fallback.img}}. The ''fallback'' image utilizes the same configuration file as the ''default'' image, except the '''autodetect''' hook is skipped during creation, thus including a full range of modules. The '''autodetect''' hook detects required modules and tailors the image for specific hardware, shrinking the initramfs. <br />
<br />
Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified for the bootloader, often in its [[Boot Loader#Configuration files|configuration file]]. After changes are made to the mkinitcpio configuration file, the image must be regenerated. For the stock Arch Linux kernel, {{Pkg|linux}}, this is done by running this command with root privileges:<br />
<br />
# mkinitcpio -p linux<br />
<br />
The {{ic|-p}} switch specifies a ''preset'' to utilize; most kernel packages provide a related mkinitcpio preset file, found in {{ic|/etc/mkinitcpio.d}} (e.g. {{ic|/etc/mkinitcpio.d/linux.preset}} for {{ic|linux}}). A preset is a predefined definition of how to create an initramfs image instead of specifying the configuration file and output file every time.<br />
<br />
{{Warning|''preset'' files are used to automatically regenerate the initramfs after a kernel update; be careful when editing them.}}<br />
<br />
Users can manually create an image using an alternative configuration file. For example, the following will generate an initramfs image according to the directions in {{ic|/etc/mkinitcpio-custom.conf}} and save it at {{ic|/boot/linux-custom.img}}.<br />
<br />
# mkinitcpio -c /etc/mkinitcpio-custom.conf -g /boot/linux-custom.img<br />
<br />
If creating an image for a kernel other than the one currently running, add the kernel version to the command line. You can see available kernel versions in {{ic|/usr/lib/modules}}.<br />
<br />
# mkinitcpio -g /boot/linux.img -k 3.3.0-ARCH<br />
<br />
== Configuration ==<br />
The primary configuration file for '''mkinitcpio''' is {{ic|/etc/mkinitcpio.conf}}. Additionally, preset definitions are provided by kernel packages in the {{ic|/etc/mkinitcpio.d}} directory (e.g. {{ic|/etc/mkinitcpio.d/linux.preset}}).<br />
<br />
{{Warning|'''lvm2''', '''mdadm''', and '''encrypt''' are '''NOT''' enabled by default. Please read this section carefully for instructions if these hooks are required.}}<br />
<br />
{{Note|Users with multiple hardware disk controllers that use the same node names but different kernel modules (e.g. two SCSI/SATA or two IDE controllers) should ensure the correct order of modules is specified in {{ic|/etc/mkinitcpio.conf}}. Otherwise, the root device location may change between boots, resulting in kernel panics.<br />
<br />
A more elegant alternative is to use [[persistent block device naming]] to ensure that the right devices are mounted.}}<br />
<br />
{{Note|'''PS/2 keyboard users''': In order to get keyboard input during early init, if you do not have it already, add the '''keyboard''' hook to the {{ic|HOOKS}}.<br />
<br />
On some motherboards (mostly ancient ones, but also a few new ones), the i8042 controller cannot be automatically detected. It is rare, but some people will surely be without keyboard. You can detect this situation in advance. If you have a PS/2 port and get {{ic|i8042: PNP: No PS/2 controller found. Probing ports directly}} message, add '''atkbd''' to the {{ic|MODULES}}.}}<br />
<br />
<br />
Users can modify six variables within the configuration file:<br />
<br />
; {{ic|MODULES}}: Kernel modules to be loaded before any boot hooks are run. <br />
; {{ic|BINARIES}}: Additional binaries to be included in the initramfs image.<br />
; {{ic|FILES}}: Additional files to be included in the initramfs image.<br />
; {{ic|HOOKS}}: Hooks are scripts that execute in the initial ramdisk.<br />
; {{ic|COMPRESSION}}: Used to compress the initramfs image.<br />
; {{ic|COMPRESSION_OPTIONS}}: Extra arguments to pass to the {{ic|COMPRESSION}} program. Usage of this setting is strongly discouraged. mkinitcpio will handle special requirements for compressors (e.g. passing {{ic|1=--check=crc32}} to xz), and misusage can easily lead to an unbootable system.<br />
<br />
=== MODULES ===<br />
The MODULES array is used to specify modules to load before anything else is done.<br />
<br />
Modules suffixed with a {{ic|?}} will not throw errors if they are not found. This might be useful for custom kernels that compile in modules which are listed explicitly in a hook or config file.<br />
<br />
{{Note|If using '''reiser4''', it ''must'' be added to the modules list. Additionally, if you will be needing any file system during the boot process that is not live when you run mkinitcpio — for example, if your LUKS encryption key file is on an '''ext2''' file system but no '''ext2''' file systems are mounted when you run mkinitcpio — that file system module must also be added to the MODULES list. See [[Dm-crypt/System configuration#cryptkey]] for more details.}}<br />
<br />
=== BINARIES and FILES ===<br />
These options allow users to add files to the image. Both {{ic|BINARIES}} and {{ic|FILES}} are added before hooks are run, and may be used to override files used or provided by a hook. {{ic|BINARIES}} are auto-located within a standard {{ic|PATH}} and dependency-parsed, meaning any required libraries will also be added. {{ic|FILES}} are added ''as-is''. For example:<br />
<br />
FILES="/etc/modprobe.d/modprobe.conf"<br />
<br />
BINARIES="kexec"<br />
<br />
For both, {{ic|BINARIES}} and {{ic|FILES}}, multiple entries can be added delimited with spaces.<br />
<br />
=== HOOKS ===<br />
The {{ic|HOOKS}} setting is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. For some hooks, they will also contain a runtime component which provides additional behavior, such as starting a daemon, or assembling a stacked block device. Hooks are referred to by their name, and executed in the order they exist in the {{ic|HOOKS}} setting in the config file.<br />
<br />
The default {{ic|HOOKS}} setting should be sufficient for most simple, single disk setups. For root devices which are stacked or multi-block devices such as [[LVM]], [[Software_RAID_and_LVM|mdadm]], or [[dm-crypt]], see the respective wiki pages for further necessary configuration.<br />
<br />
==== Build hooks ====<br />
Build hooks are found in {{ic|/usr/lib/initcpio/install}}. These files are sourced by the bash shell during runtime of mkinitcpio and should contain two functions: {{ic|build}} and {{ic|help}}. The {{ic|build}} function describes the modules, files, and binaries which will be added to the image. An API, documented by mkinitcpio(8), serves to facilitate the addition of these items. The {{ic|help}} function outputs a description of what the hook accomplishes.<br />
<br />
For a list of all available hooks:<br />
<br />
$ mkinitcpio -L<br />
<br />
Use mkinitcpio's {{ic|-H}} option to output help for a specific hook, for example:<br />
<br />
$ mkinitcpio -H udev<br />
<br />
==== Runtime hooks ====<br />
Runtime hooks are found in {{ic|/usr/lib/initcpio/hooks}}. For any runtime hook, there should always be a build hook of the same name, which calls {{ic|add_runscript}} to add the runtime hook to the image. These files are sourced by the busybox ash shell during early userspace. With the exception of cleanup hooks, they will always be run in the order listed in the {{ic|HOOKS}} setting. Runtime hooks may contain several functions:<br />
<br />
{{ic|run_earlyhook}}: Functions of this name will be run once the API file systems have been mounted and the kernel command line has been parsed. This is generally where additional daemons, such as udev, which are needed for the early boot process are started from.<br />
<br />
{{ic|run_hook}}: Functions of this name are run shortly after the early hooks. This is the most common hook point, and operations such as assembly of stacked block devices should take place here.<br />
<br />
{{ic|run_latehook}}: Functions of this name are run after the root device has been mounted. This should be used, sparingly, for further setup of the root device, or for mounting other file systems, such as {{ic|/usr}}.<br />
<br />
{{ic|run_cleanuphook}}: Functions of this name are run as late as possible, and in the reverse order of how they are listed in the {{ic|HOOKS}} setting in the config file. These hooks should be used for any last minute cleanup, such as shutting down any daemons started by an early hook.<br />
<br />
==== Common hooks ====<br />
A table of common hooks and how they affect image creation and runtime follows. Note that this table is not complete, as packages can provide custom hooks.<br />
<br />
{| class="wikitable sortable"<br />
|+ '''Current hooks'''<br />
|-<br />
! Hook || Installation || Runtime<br />
|-<br />
| '''base''' || Sets up all initial directories and installs base utilities and libraries. Always add this hook as the first hook unless you know what you are doing. || --<br />
|-<br />
| '''systemd''' || This will install a basic systemd setup in your initramfs, and is meant to replace the ''base'', ''usr'' and ''udev'' hooks. Other hooks (like encryption) would need to be ported, and may not work as intended. It is '''required''', if you use any other systemd specific hooks ("sd-*") from below. As of {{Pkg|systemd}} 207, this hook does not work as intended when combined with lvm2 and may break your boot. Use the ''sd-lvm2'' hook instead of the ''lvm2'' one. You also may wish to still include the ''base'' hook (before this hook) to ensure that a rescue shell exists on your initramfs. As of {{Pkg|systemd}} 217 this hook also installs the service and binary helper needed for resuming from [[hibernation]].<br />
<br />
{{Warning|The emergency shell feature provided by this hook is non-functional as of 2015-07-07. A separate hook has to provide a shell, {{ic|/sbin/sulogin}}, {{ic|/etc/shadow}}, {{ic|/etc/gshadow}}, as well as ensure a keyboard driver module like {{ic|atkbd}} is loaded. The '''base''' hook only provides the shell. See {{bug|36265}}, {{bug|45480}}.}}<br />
|| --<br />
|-<br />
| '''btrfs''' || Sets the required modules to enable [[Btrfs]] for root and the use of subvolumes. || Runs {{ic|btrfs device scan}} to assemble a multi-device Btrfs root file system when no udev hook is present. The {{Pkg|btrfs-progs}} package is required for this hook.<br />
|-<br />
| '''udev''' || Adds udevd, udevadm, and a small subset of udev rules to your image. || Starts the udev daemon and processes uevents from the kernel; creating device nodes. As it simplifies the boot process by not requiring the user to explicitly specify necessary modules, using the udev hook is recommended.<br />
|-<br />
| '''autodetect''' || Shrinks your initramfs to a smaller size by creating a whitelist of modules from a scan of sysfs. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. || --<br />
|-<br />
| '''modconf''' || Includes modprobe configuration files from {{ic|/etc/modprobe.d}} and {{ic|/usr/lib/modprobe.d}} || --<br />
|-<br />
| '''block''' || Adds all block device modules, formerly separately provided by the ''fw'', ''mmc'', ''pata'', ''sata'', ''scsi'', ''usb'', and ''virtio'' hooks. || --<br />
|-<br />
| '''pcmcia''' || Adds the necessary modules for PCMCIA devices. You need to have {{Pkg|pcmciautils}} installed to use this. || --<br />
|-<br />
| '''net''' || Adds the necessary modules for a network device. For PCMCIA net devices, please add the '''pcmcia''' hook too. || Provides handling for an NFS-based root file system.<br />
|-<br />
| '''dmraid''' || Provides support for fakeRAID root devices. You must have {{Pkg|dmraid}} installed to use this. Note that it is preferred to use {{ic|mdadm}} with the '''mdadm_udev''' hook with fakeRAID if your controller supports it. || Locates and assembles fakeRAID block devices using {{ic|dmraid}}.<br />
|-<br />
| '''mdadm''' || Provides support for assembling RAID arrays from {{ic|/etc/mdadm.conf}}, or autodetection during boot. You must have {{Pkg|mdadm}} installed to use this. The '''mdadm_udev''' hook is preferred over this hook. || Locates and assembles software RAID block devices using {{ic|mdassemble}}.<br />
|-<br />
| '''mdadm_udev''' || Provides support for assembling RAID arrays via udev. You must have {{Pkg|mdadm}} installed to use this. If you use this hook with a FakeRAID array, it is recommended to include {{ic|mdmon}} in the binaries section and add the '''shutdown''' hook in order to avoid unnecessary RAID rebuilds on reboot. || Locates and assembles software RAID block devices using {{ic|udev}} and {{ic|mdadm}} incremental assembly. This is the preferred method of mdadm assembly (rather than using the above ''mdadm'' hook). <br />
|-<br />
| '''keyboard''' || Adds the necessary modules for keyboard devices. Use this if you have an USB keyboard and need it in early userspace (either for entering encryption passphrases or for use in an interactive shell). As a side effect, modules for some non-keyboard input devices might be added to, but this should not be relied on. || --<br />
|-<br />
| '''keymap''' || Adds the specified keymap(s) from {{ic|/etc/vconsole.conf}} to the initramfs. || Loads the specified keymap(s) from {{ic|/etc/vconsole.conf}} during early userspace.<br />
|-<br />
| '''consolefont''' || Adds the specified console font from {{ic|/etc/vconsole.conf}} to the initramfs. || Loads the specified console font from {{ic|/etc/vconsole.conf}} during early userspace.<br />
|-<br />
| '''sd-vconsole''' || Adds the keymap(s) and console font specified in {{ic|/etc/vconsole.conf}} to the systemd-based initramfs. || Loads the specified keymap(s) and console font during early userspace.<br />
|-<br />
| '''encrypt''' || Adds the {{ic|dm_crypt}} kernel module and the {{ic|cryptsetup}} tool to the image. You must have {{Pkg|cryptsetup}} installed to use this. || Detects and unlocks an encrypted root partition. See [[#Runtime customization]] for further configuration.<br />
|-<br />
| '''sd-encrypt''' || This hook allows for an encrypted root device with systemd initramfs.<br />
<br />
See the man page of systemd-cryptsetup-generator(8) for available kernel<br />
command line options. Alternatively, if the file {{ic|/etc/crypttab.initramfs}}<br />
exists, it will be added to the initramfs as {{ic|/etc/crypttab}}. See the<br />
crypttab(5) manpage for more information on crypttab syntax.<br />
| --<br />
|-<br />
| '''lvm2''' || Adds the device mapper kernel module and the {{ic|lvm}} tool to the image. You must have {{Pkg|lvm2}} installed to use this. || Enables all LVM2 volume groups. This is necessary if you have your root file system on [[LVM]].<br />
|-<br />
| '''fsck''' || Adds the fsck binary and file system-specific helpers. If added after the '''autodetect''' hook, only the helper specific to your root file system will be added. Usage of this hook is '''strongly''' recommended, and it is required with a separate {{ic|/usr}} partition. || Runs fsck against your root device (and {{ic|/usr}} if separate) prior to mounting. The default configuration of the bootloader is suitable, if in doubt read this [https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 explanation].<br />
|-<br />
| '''resume''' || -- || Tries to resume from the "suspend to disk" state. Works with both ''swsusp'' and ''[[TuxOnIce]]''. See [[Hibernation]] for further configuration. Intended to work along with the {{ic|base}} hook, the {{ic|systemd}} hook provides its own resume mechanism.<br />
|-<br />
| '''filesystems''' || This includes necessary file system modules into your image. This hook is '''required''' unless you specify your file system modules in MODULES. || --<br />
|-<br />
| '''shutdown''' || Adds shutdown initramfs support. Usage of this hook was strongly recommended before mkinitcpio 0.16, if you have a separate {{ic|/usr}} partition or encrypted root. From mkinitcpio 0.16 onwards, it is deemed [https://mailman.archlinux.org/pipermail/arch-dev-public/2013-December/025742.html not necessary]. || Unmounts and disassembles devices on shutdown.<br />
|-<br />
| '''usr''' || Add supports for {{ic|/usr}} on a separate partition. || Mounts the {{ic|/usr}} partition after the real root has been mounted.<br />
|}<br />
<br />
=== COMPRESSION ===<br />
The kernel supports several formats for compression of the initramfs - gzip, bzip2, lzma, xz (also known as lzma2), lzo, and lz4. For most use cases, gzip, lzop, and lz4 provide the best balance of compressed image size and decompression speed.<br />
COMPRESSION="gzip"<br />
COMPRESSION="bzip2" # since kernel 2.6.30<br />
COMPRESSION="lzma" # since kernel 2.6.30<br />
COMPRESSION="lzop" # since kernel 2.6.34<br />
COMPRESSION="xz" # since kernel 2.6.38<br />
COMPRESSION="lz4" # since kernel 3.11; also '''requires''' {{Pkg|mkinitcpio}}>=16-2<br />
<br />
Specifying no {{ic|COMPRESSION}} will result in a gzip-compressed initramfs file. To create an uncompressed image, specify {{ic|1=COMPRESSION=cat}} in the config or use {{ic|-z cat}} on the command line.<br />
<br />
Make sure you have the correct file compression utility installed for the method you wish to use.<br />
<br />
=== COMPRESSION_OPTIONS ===<br />
These are additional flags passed to the program specified by {{ic|COMPRESSION}}, such as:<br />
<br />
COMPRESSION_OPTIONS='-9'<br />
<br />
In general these should never be needed as mkinitcpio will make sure that any supported compression method has the necessary flags to produce a working image. Furthermore, misusage of this option can lead to an unbootable system if the kernel is unable to unpack the resultant archive.<br />
<br />
== Runtime customization ==<br />
{{Expansion|Which options work with the {{ic|systemd}} hook and which are {{ic|base}}-only?}}<br />
Runtime configuration options can be passed to {{ic|init}} and certain hooks via the kernel command line. Kernel command-line parameters are often supplied by the bootloader. The options discussed below can be appended to the kernel command line to alter default behavior. See [[Kernel parameters]] and [[Arch boot process]] for more information.<br />
<br />
=== init from base hook ===<br />
; {{ic|root}}: This is the most important parameter specified on the kernel command line, as it determines what device will be mounted as your proper root device. mkinitcpio is flexible enough to allow a wide variety of formats, for example:<br />
root=/dev/sda1 # /dev node<br />
root=LABEL=CorsairF80 # label<br />
root=UUID=ea1c4959-406c-45d0-a144-912f4e86b207 # UUID<br />
root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 # GPT partition UUID<br />
<br />
{{Note|The following boot parameters alter the default behavior of {{ic|init}} in the initramfs environment. See {{ic|/usr/lib/initcpio/init}} for details. They will not work when {{ic|systemd}} hook is being used since the {{ic|init}} from {{ic|base}} hook is replaced.}}<br />
<br />
; {{ic|break}}: If {{ic|break}} or {{ic|1=break=premount}} is specified, {{ic|init}} pauses the boot process (after loading hooks, but before mounting the root file system) and launches an interactive shell which can be used for troubleshooting purposes. This shell can be launched after the root has been mounted by specifying {{ic|1=break=postmount}}. Normal boot continues after exiting from the shell.<br />
<br />
; {{ic|disablehooks}}: Disable hooks at runtime by adding {{ic|1=disablehooks=hook1[,hook2,...]}}. For example: {{bc|1=disablehooks=resume}}<br />
<br />
; {{ic|earlymodules}}: Alter the order in which modules are loaded by specifying modules to load early via {{ic|1=earlymodules=mod1[,mod2,...]}}. (This may be used, for example, to ensure the correct ordering of multiple network interfaces.)<br />
<br />
See [[Boot debugging]] and [https://projects.archlinux.org/mkinitcpio.git/tree/man/mkinitcpio.8.txt#n212 man mkinitcpio] for other parameters.<br />
<br />
=== Using RAID ===<br />
First, add the {{ic|mdadm_udev}} or {{ic|mdadm}} hook to the {{ic|HOOKS}} array and any required RAID modules (e.g. raid456, ext4) to the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
Using the {{ic|mdadm}} hook, you no longer need to configure your RAID array in the [[kernel parameters]]. The {{ic|mdadm}} hook will either use your {{ic|/etc/mdadm.conf}} file or automatically detect the array(s) during the init phase of boot.<br />
<br />
Assembly via udev is also possible using the {{ic|mdadm_udev}} hook. Upstream prefers this method of assembly. {{ic|/etc/mdadm.conf}} will still be read for purposes of naming the assembled devices if it exists.<br />
<br />
=== Using net ===<br />
{{Warning|NFSv4 is not yet supported.}}<br />
<br />
'''Required Packages'''<br />
<br />
{{ic|net}} requires the {{Pkg|mkinitcpio-nfs-utils}} package from the [[official repositories]].<br />
<br />
'''Kernel Parameters''' <br />
<br />
Comprehensive and up-to-date information can be found in the official [https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt kernel documentation].<br />
<br />
'''ip='''<br />
<br />
This parameter tells the kernel how to configure IP addresses of devices and also how to set up the IP routing table. It can take up to nine arguments separated by colons: {{ic|1=ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>}}.<br />
<br />
If this parameter is missing from the kernel command line, all fields are assumed to be empty, and the defaults mentioned in the [https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt kernel documentation] apply. In general this means that the kernel tries to configure everything using autoconfiguration.<br />
<br />
The {{ic|<autoconf>}} parameter can appear alone as the value to the 'ip' parameter (without all the ':' characters before). If the value is "ip=off" or "ip=none", no autoconfiguration will take place, otherwise autoconfiguration will take place. The most common way to use this is "ip=dhcp".<br />
<br />
For parameters explanation, see the [https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt kernel doc].<br />
<br />
; Examples<br />
ip=127.0.0.1:::::lo:none --> Enable the loopback interface.<br />
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.<br />
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.<br />
<br />
{{Note|Make sure to use kernel device names (e.g. ''eth0'') for the {{ic|<device>}} parameter, and not [[Network_configuration#Device_names|udev]] ones (e.g. ''enp2s0'') as those will not work.}}<br />
<br />
'''BOOTIF='''<br />
<br />
If you have multiple network cards, this parameter can include the MAC address of the interface you are booting from. This is often useful as interface numbering may change, or in conjunction with pxelinux IPAPPEND 2 or IPAPPEND 3 option.<br />
If not given, eth0 will be used.<br />
<br />
''Example:''<br />
BOOTIF=01-A1-B2-C3-D4-E5-F6 # Note the prepended "01-" and capital letters.<br />
<br />
'''nfsroot='''<br />
<br />
If the {{ic|nfsroot}} parameter is NOT given on the command line, the default {{ic|/tftpboot/%s}} will be used.<br />
<br />
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]<br />
<br />
''Parameter explanation:''<br />
<br />
<server-ip> Specifies the IP address of the NFS server. If this field<br />
is not given, the default address as determined by the<br />
`ip' variable (see below) is used. One use of this<br />
parameter is for example to allow using different servers<br />
for RARP and NFS. Usually you can leave this blank.<br />
<br />
<root-dir> Name of the directory on the server to mount as root. If<br />
there is a "%s" token in the string, the token will be<br />
replaced by the ASCII-representation of the client's IP<br />
address.<br />
<br />
<nfs-options> Standard NFS options. All options are separated by commas.<br />
If the options field is not given, the following defaults<br />
will be used:<br />
port = as given by server portmap daemon<br />
rsize = 1024<br />
wsize = 1024<br />
timeo = 7<br />
retrans = 3<br />
acregmin = 3<br />
acregmax = 60<br />
acdirmin = 30<br />
acdirmax = 60<br />
flags = hard, nointr, noposix, cto, ac<br />
<br />
'''root=/dev/nfs'''<br />
<br />
If you do not use the {{ic|nfsroot}} parameter, you need to set {{ic|1=root=/dev/nfs}} to boot from an NFS root via automatic configuration.<br />
<br />
=== Using LVM ===<br />
If your root device is on [[LVM]], see [[LVM#Add_lvm2_hook_to_mkinitcpio.conf_for_root_on_LVM|Add lvm2 hook to mkinitcpio.conf for root on LVM]].<br />
<br />
=== Using encrypted root ===<br />
If using an [[Dm-crypt/Encrypting_an_entire_system|encrypted root]], the {{ic|encrypt}} hook must be added before {{ic|filesystems}} and other hooks may be needed. Specific kernel command line parameters also need to be passed depending on your bootloader: see [[Dm-crypt/System configuration#mkinitcpio]] for detailed information.<br />
<br />
=== /usr as a separate partition ===<br />
<br />
If you keep {{ic|/usr}} as a separate partition, you must adhere to the following requirements:<br />
<br />
* Enable {{ic|mkinitcpio-generate-shutdown-ramfs.service}} '''or''' add the {{ic|shutdown}} hook.<br />
* Add the {{ic|fsck}} hook, mark {{ic|/usr}} with a {{ic|passno}} of {{ic|0}} in {{ic|/etc/fstab}}. While recommended for everyone, it is mandatory if you want your {{ic|/usr}} partition to be fsck'ed at boot-up. Without this hook, {{ic|/usr}} will never be fsck'd.<br />
* Add the {{ic|usr}} hook. This will mount the {{ic|/usr}} partition after root is mounted. Prior to 0.9.0, mounting of {{ic|/usr}} would be automatic if it was found in the real root's {{ic|/etc/fstab}}.<br />
<br />
== Troubleshooting ==<br />
=== Extracting the image ===<br />
If you are curious about what is inside the initrd image, you can extract it and poke at the files inside of it. <br />
<br />
The initrd image is an SVR4 CPIO archive, generated via the {{ic|find}} and {{ic|bsdcpio}} commands, optionally compressed with a compression scheme understood by the kernel. For more information on the compression schemes, see [[#COMPRESSION]].<br />
<br />
mkinitcpio includes a utility called {{ic|lsinitcpio}} which will list and extract the contents of initramfs images.<br />
<br />
You can list the files in the image with:<br />
$ lsinitcpio /boot/initramfs-linux.img<br />
<br />
And to extract them all in the current directory:<br />
$ lsinitcpio -x /boot/initramfs-linux.img<br />
<br />
You can also get a more human-friendly listing of the important parts in the image:<br />
$ lsinitcpio -a /boot/initramfs-linux.img<br />
<br />
=== "/dev must be mounted" when it already is ===<br />
The test used by mkinitcpio to determine if /dev is mounted is to see if /dev/fd/ is there. If everything else looks fine, it can be "created" manually by:<br />
# ln -s /proc/self/fd /dev/<br />
<br />
(Obviously, /proc must be mounted as well. mkinitcpio requires that anyway, and that is the next thing it will check.)<br />
<br />
=== Using systemd HOOKS in a LUKS/LVM/resume setup ===<br />
Using {{ic|systemd/sd-encrypt/sd-lvm2}} '''HOOKS''' instead of the traditional {{ic|encrypt/lvm2/resume}} requires different initrd parameters to be passed by your bootloader. See this post on forum for details [https://bbs.archlinux.org/viewtopic.php?pid=1480241].<br />
<br />
=== Possibly missing firmware for module XXXX ===<br />
<br />
When initramfs are being rebuild after a kernel update, you might get these two warnings:<br />
<br />
==> WARNING: Possibly missing firmware for module: aic94xx<br />
==> WARNING: Possibly missing firmware for module: smsmdtv <br />
<br />
These appear to any Arch Linux users, especially those who have not installed these firmware modules. If you do not use hardware which uses these firmwares you can safely ignore this message.<br />
<br />
=== Boot succeeds on one machine and fails on another ===<br />
''mkinitcpio'''s {{ic|autodetect}} hook filters unneeded [[kernel modules]] in the primary initramfs scanning {{ic|/sys}} and the modules loaded at the time it is run. If you transfer your {{ic|/boot}} directory to another machine and the boot sequence fails during early userspace, it may be because the new hardware is not detected due to missing kernel modules. <br />
<br />
To fix, first try choosing the [[#Image_creation_and_activation|fallback]] image from your [[bootloader]], as it is not filtered by {{ic|autodetect}}. Once booted, run ''mkinitcpio'' on the new machine to rebuild the primary image with the correct modules. If the fallback image fails, try booting into an Arch Linux live CD/USB, chroot into the installation, and run ''mkinitcpio'' on the new machine. As a last resort, try [[#MODULES|manually]] adding modules to the initramfs.<br />
<br />
== See also ==<br />
* [[Boot debugging]] - Debugging with GRUB<br />
* Linux Kernel documentation on [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/filesystems/ramfs-rootfs-initramfs.txt;hb=HEAD initramfs]<br />
* Linux Kernel documentation on [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/initrd.txt;hb=HEAD initrd]<br />
* Wikipedia article on [https://en.wikipedia.org/wiki/initrd initrd]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403445PCI passthrough via OVMF2015-10-05T17:36:19Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Kernel 4.2.2-1 seems to have temporarily broken this. Consider going with {{Pkg|linux-lts}} or {{AUR|linux-vfio-lts}}.<br />
[https://bbs.archlinux.org/viewtopic.php?id=203240]}}<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403444PCI passthrough via OVMF2015-10-05T17:35:05Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Kernel 4.2.2-1 seems to have temporarily broken this. Consider going with {{Pkg|linux-lts}} or {{AUR|linux-vfio-lts}}.<br />
[https://bbs.archlinux.org/viewtopic.php?id"="203240]}}<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403443PCI passthrough via OVMF2015-10-05T17:33:37Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Kernel 4.2.2-1 seems to have temporarily broken this. Consider going with {{PKG|linux-lts}} or {{AUR|linux-vfio-lts}}.<br />
[https://bbs.archlinux.org/viewtopic.php?id"="203240]}}<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403442PCI passthrough via OVMF2015-10-05T17:31:35Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
{{Note|Kernel 4.2.2-1 seems to have temporarily broken this. Consider going with {{PKG|linux-lts}} or {{AUR|linux-vfio-lts}}.<br />
[https://bbs.archlinux.org/viewtopic.php?id"="203240]}}<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403440PCI passthrough via OVMF2015-10-05T17:28:05Z<p>Physicist1616: /* Installation */ Added note about 4.2.2-1 breakage.</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
{{bc|<nowiki><br />
Note: Kernel 4.2.2-1 seems to have temporarily broken this. Consider going with {{PKG|linux-lts}} or {{AUR|linux-vfio-lts}}.<br />
https://bbs.archlinux.org/viewtopic.php?id=203240<br />
</nowiki>}}<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403438PCI passthrough via OVMF2015-10-05T17:18:59Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
[[Install]] {{Pkg|qemu}} and {{Pkg|rpmextract}}. Consider installing {{AUR|linux-vfio}} if you need the kernel with the patches.<br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:PCI_passthrough_via_OVMF&diff=403437Talk:PCI passthrough via OVMF2015-10-05T17:17:40Z<p>Physicist1616: /* Article Specificity */</p>
<hr />
<div>== Missing links ==<br />
<br />
"cp -R ./usr/share /usr/share" creates "/usr/share/share" with the contents of .usr/share in it. I don't think you can do the copy with one command.<br />
Do you have plans to update the missing links? I'm referring to this paragraph: "This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post." [[User:Wmarler|Wmarler]] ([[User talk:Wmarler|talk]]) 05:42, 3 April 2015 (UTC)<br />
<br />
== Qemu permissions ==<br />
<br />
I didn't need to change the qemu permissions to make passing through vfio devices work. Here's what I have:<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
#user = "root"<br />
group="78"<br />
#clear_emulator_capabilities = 1<br />
...<br />
#cgroup_device_acl = [<br />
# "/dev/null", "/dev/full", "/dev/zero",<br />
# "/dev/random", "/dev/urandom",<br />
# "/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
# "/dev/rtc","/dev/hpet", "/dev/vfio/vfio"<br />
#]<br />
...</nowiki>}}<br />
<br />
[[User:M01|M01]] ([[User talk:M01|talk]])<br />
<br />
== Article Specificity ==<br />
<br />
I see that this article's title is focused on OVMF, but it seems to allow an alternate method as well.<br />
<br />
Considering that PCI Passthrough would be a user's goal and the "via OVMF" is only one of several details involved in the "How", it makes sense to me to move the article to "PCI Passthrough". Am I by-chance just not seeing the actual page-title of the main article on this subject?<br />
<br />
Thoughts?<br />
<br />
(Sidenote, adding info about the [[linux-vfio]] packages in AUR to the Installation section.)<br />
<br />
[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 17:09, 5 October 2015 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=PCI_passthrough_via_OVMF&diff=403436PCI passthrough via OVMF2015-10-05T17:12:36Z<p>Physicist1616: /* Installation */</p>
<hr />
<div>[[Category:Virtualization]]<br />
{{Expansion|Missing introduction and descriptions of ''why'' the steps are necessary (it may be explained in the external sources, but still...)}}<br />
<br />
This is a guide on how to do PCI VGA Passthrough on QEMU. Since kernel 3.9 and a change in QEMU, it is now possible to passthrough a graphics card, offering the VM native graphics performance which is useful when doing graphic-intensive tasks such as gaming. To do this, you need two graphics cards, one for the host and one for the VM; it is possible to use integrated graphics for the host. Your processor and motherboard also need to support AMD-VI/VT-D.<br />
<br />
==Installation==<br />
<br />
[[Install]] {{AUR|linux-vfio}}, {{Pkg|qemu}} and {{Pkg|rpmextract}}. <br />
<br />
Install edk2.git-ovmf-x64 from [https://www.kraxel.org/repos/jenkins/edk2/ Gerd Hoffman's repository].<br />
<br />
Extract that archive to /usr:<br />
<br />
{{bc|# rpmextract.sh edk2.git-ovmf-x64-0-20150223.b877.ga8577b3.noarch.rpm<br />
# cp -R ./usr/share/* /usr/share}}<br />
<br />
Ensure /usr/share/edk2.git/ovmf-x64 contains these files:<br />
{{hc|$ ls /usr/share/edk2.git/ovmf-x64/*pure*.fd|<br />
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd<br />
/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}}<br />
<br />
This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post.<br />
<br />
==Setting up libvirt==<br />
<br />
See [[Polkit#Bypass password prompt]] to bypass the password prompt, then [[enable]] and start {{ic|libvirtd.service}}.<br />
<br />
Start ''virt-manager'' and configure the hypervisor. Virtmanager should connect to the qemu session.<br />
<br />
==Enabling IOMMU==<br />
<br />
Ensure that AMD-VI/VT-D is enabled in your BIOS settings.<br />
<br />
If your processor is Intel, add {{ic|intel_iommu<nowiki>=</nowiki>on}} to your [[Kernel_parameters|bootloader kernel options]]. Simlarly, if you have an AMD processor, add {{ic|amd_iommu<nowiki>=</nowiki>on}}.<br />
<br />
After rebooting, check dmesg to confirm IOMMU is 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 />
==Isolating the GPU==<br />
<br />
Find your target card's PCI location:<br />
{{hc|lspci -nn<nowiki>|</nowiki>grep -iP "NVIDIA<nowiki>|</nowiki>Radeon"|<br />
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman PRO [Radeon HD 6950] [1002:6719]<br />
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Cayman/Antilles HDMI Audio [Radeon HD 6900 Series] [1002:aa80]<br />
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G73 [GeForce 7600 GS] [10de:0392] (rev a1)}}<br />
<br />
In this case, the three locations we're after are {{ic|1002:6719 1002:aa80 10de:0392}}. Make note of any locations you intend to pass through to the VM.<br />
<br />
To allow the VM access to your passthrough'd devices, you'll need to claim it before the host drivers do. This can be achieved with either one of two kernel modules, {{ic|vfio-pci}} or {{ic|pci-stub}}.<br />
<br />
vfio-pci is available in kernel v4.1+, and is the recommended option if your kernel supports it. You can check if this module is available by running:<br />
<br />
$ modprobe vfio-pci<br />
<br />
If there is no output, you're good to go. If instead you recieve {{ic|modprobe: FATAL: Module vfio-pci not found}}, use the guide further down for {{ic|pci-stub}} instead.<br />
<br />
=== vfio-pci ===<br />
<br />
Ensure the vfio-pci driver is loaded on bootup through {{ic|modprobe.d}}. It is necessary to tell the vfio-pci driver which PCI devices to bind. If you were adding all three of the PCI devices listed above, your modprobe.d launch config would have the following contents:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/vfio.conf</nowiki>|<nowiki><br />
options vfio-pci ids=1002:6719,1002:aa80,10de:0392<br />
</nowiki>}}<br />
<br />
Next we'll want to ensure the kernel loads the necessary modules for vfio-pci when starting up:<br />
<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
MODULES="vfio vfio_iommu_type1 vfio_pci vfio_virqfd"<br />
...</nowiki>}}<br />
<br />
Save the changes to the initial ramdisk environment:<br />
<br />
# mkinitcpio -p linux<br />
{{Note|If you're using a non-standard kernel, replace "linux" with whichever kernel you intend to use.}}<br />
<br />
When using the 'base' hook in the initramfs, all modules specified in the MODULES array are loaded statically early in the boot process. The same behavior can be achieved with the 'systemd' hook by using the 'rd.modules-load' kernel parameter to specify modules that should be statically loaded early.<br />
<br />
rd.modules-load=vfio-pci,...<br />
<br />
Reboot and check dmesg output for successful assignment of the device(s) to vfio-pci:<br />
<br />
{{hc|dmesg <nowiki>|</nowiki> grep -i vfio|...<br />
[ 0.456472] VFIO - User Level meta-driver version: 0.3<br />
[ 0.470269] vfio_pci: add [10de:13c2[ffff:ffff]] class 0x000000/00000000<br />
[ 0.483631] vfio_pci: add [10de:0fbb[ffff:ffff]] class 0x000000/00000000<br />
[ 0.496998] vfio_pci: add [8086:8ca0[ffff:ffff]] class 0x000000/00000000<br />
[ 2.420184] vfio-pci 0000:0a:00.0: enabling device (0000 -> 0003)<br />
[ 38.590395] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x1e@0x258<br />
[ 38.590413] vfio_ecap_init: 0000:0a:00.0 hiding ecap 0x19@0x900<br />
[ 38.606881] vfio-pci 0000:0a:00.1: enabling device (0000 -> 0002)<br />
[ 38.620241] vfio-pci 0000:00:1b.0: enabling device (0000 -> 0002)<br />
...}}<br />
<br />
You can cross reference devices id's with {{ic|lspci -nn}}'s output.<br />
<br />
=== pci-stub ===<br />
<br />
If your kernel does not support vfio-pci, you can use the pci-stub module instead.<br />
<br />
Add {{ic|pci-stub}} to {{ic|/etc/mkinitcpio.conf}}:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>MODULES="... pci-stub ..."</nowiki>}}<br />
If it doesn't work, try adding it to /etc/modules-load.d/ as well:<br />
$ echo "pci-stub" > sude tee /etc/modules-load.d/vfio.conf<br />
<br />
Add the relevant PCI locations to the kernel command line:<br />
{{hc|<nowiki>/etc/mkinitcpio.conf</nowiki>|<nowiki>...<br />
GRUB_CMDLINE_LINUX_DEFAULT="... pci-stub.ids=1002:6719,1002:aa80,10de:0392 ..."<br />
...</nowiki>}}<br />
<br />
If your graphics card has audio as a separated PCI device, it must be added as well:<br />
pci-stub.ids=1002:6719,1002:aa80<br />
<br />
Reload the grub configuration:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
Check dmesg output for successful assignment of the device to pci-stub:<br />
{{hc|dmesg <nowiki>|</nowiki> grep pci-stub|<br />
...<br />
[ 2.390128] pci-stub: add 1002:6719 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390143] pci-stub 0000:01:00.0: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:AA80 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:01:00.1: claimed by stub<br />
[ 2.390150] pci-stub: add 1002:0392 sub<nowiki>=</nowiki>FFFFFFFF:FFFFFFFF cls<nowiki>=</nowiki>00000000/00000000<br />
[ 2.390159] pci-stub 0000:04:00.0: claimed by stub<br />
...}}<br />
<br />
=== Blacklisting modules ===<br />
<br />
Alternatively, if your host does not require the driver of the PCI device you intend to pass through (i.e. your host and VM are not using the same GPU vendor), you can blacklist {{ic|radeon}} and {{ic|fglrx}} for AMD GPUs, or {{ic|nouveau}} and {{ic|nvidia}} for NVIDIA GPus in {{ic|/etc/modprobe.d/blacklist.conf}}.<br />
<br />
Example, blacklisting the opensource radeon module:<br />
{{hc|/etc/modprobe.d/modprobe.conf|blacklist radeon}}<br />
<br />
=== Binding to VFIO ===<br />
<br />
There are many methods to bind the card to vfio, here is one example:<br />
*[http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1 webpage]. Check the part after grub2-mkconfig.<br />
<br />
== IOMMU groups ==<br />
<br />
Only complete IOMMU groups can be attached to the guest VM. To see which groups each of your PCI devices are assigned to:<br />
<br />
{{hc|# find /sys/kernel/iommu_groups/ -type l|<br />
/sys/kernel/iommu_groups/0/devices/0000:00:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:00:01.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.0<br />
/sys/kernel/iommu_groups/1/devices/0000:01:00.1<br />
/sys/kernel/iommu_groups/2/devices/0000:00:02.0<br />
/sys/kernel/iommu_groups/3/devices/0000:00:16.0<br />
/sys/kernel/iommu_groups/4/devices/0000:00:1a.0<br />
/sys/kernel/iommu_groups/5/devices/0000:00:1b.0<br />
/sys/kernel/iommu_groups/6/devices/0000:00:1c.0<br />
/sys/kernel/iommu_groups/7/devices/0000:00:1c.5<br />
/sys/kernel/iommu_groups/8/devices/0000:00:1c.6<br />
/sys/kernel/iommu_groups/9/devices/0000:00:1c.7<br />
/sys/kernel/iommu_groups/9/devices/0000:05:00.0<br />
/sys/kernel/iommu_groups/10/devices/0000:00:1d.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.0<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.2<br />
/sys/kernel/iommu_groups/11/devices/0000:00:1f.3<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.0<br />
/sys/kernel/iommu_groups/12/devices/0000:02:00.1<br />
/sys/kernel/iommu_groups/13/devices/0000:03:00.0<br />
/sys/kernel/iommu_groups/14/devices/0000:04:00.0}}<br />
<br />
=== ACS Override Patch ===<br />
If you find your PCI devices grouped among others that you don't 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'll 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 />
== QEMU permissions ==<br />
<br />
Give QEMU access to hardware (there may be safer ways of doing this):<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
user = "root"<br />
group = "root"<br />
clear_emulator_capabilities = 0</nowiki>}}<br />
<br />
QEMU also needs acces to VFIO files. Include every numbered file in /dev/vfio:<br />
<br />
ls -1 /dev/vfio<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
cgroup_device_acl = [<br />
"/dev/null", "/dev/full", "/dev/zero",<br />
"/dev/random", "/dev/urandom",<br />
"/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
"/dev/rtc","/dev/hpet", "/dev/vfio/vfio",<br />
"/dev/vfio/1"<br />
]<br />
...</nowiki>}}<br />
<br />
Referenced from [http://www.firewing1.com/howtos/fedora-20/create-gaming-virtual-machine-using-vfio-pci-passthrough-kvm firewing1's webpage].<br />
<br />
== QEMU commands ==<br />
<br />
This is the command to run QEMU with VGA Passthrough:<br />
cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd<br />
qemu-system-x86_64 \<br />
-enable-kvm \<br />
-m 2048 \<br />
-cpu host,kvm=off \<br />
-vga none \<br />
-device vfio-pci,host=01:00.0 \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \<br />
-drive if=pflash,format=raw,file=/tmp/my_vars.fd<br />
<br />
{{ic|1=-enable KVM}} - enables KVM for your system, using AMD-VI/VT-D for hardware virtualisation.<br />
<br />
{{ic|1=-m [number]}} - sets the amount of memory the VM should have.<br />
<br />
{{ic|1=-cpu host, kvm=off}} - emulate the host's exact CPU. {{ic|1=kvm=off}} is used for NVIDIA cards to stop it detecting a hypervisor and therefore exiting with an error.<br />
<br />
{{ic|1=-vga none}} - disables the built in graphics card emulation.<br />
<br />
{{ic|1=-device vfio-pci,host=01:00.0 \}} - graphics card(s) you are using for VGA passthrough.<br />
<br />
{{ic|1=-drive if=flash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd}} BIOS location.<br />
<br />
For more commands see [https://wiki.archlinux.org/index.php/QEMU QEMU.]<br />
<br />
==Create and configure VM for OVMF==<br />
<br />
[http://vfio.blogspot.com/2014/08/primary-graphics-assignment-without-vga.html Alex Williamson's blog]<br />
<br />
Use virsh to edit the VM with these changes:<br />
<br />
{{bc|<nowiki><domain type='kvm'></nowiki>}}<br />
<br />
{{bc|<nowiki><os><br />
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader><br />
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/><br />
</os></nowiki>}}<br />
{{bc|<nowiki><hyperv><br />
<relaxed state='off'/><br />
<vapic state='off'/><br />
<spinlocks state='off'/><br />
</hyperv></nowiki>}}<br />
{{bc|<nowiki><features><br />
<kvm><br />
<hidden state='on'/><br />
</kvm><br />
</features></nowiki>}}<br />
{{bc|<nowiki><clock><br />
<timer name='hypervclock' present='no'/><br />
</clock></nowiki>}}<br />
<br />
== Complete example for QEMU (CLI-based) without libvirtd ==<br />
<br />
This script starts Samba and Synergy, runs the VM and closes everything after the VM is shut down. Note that this method does '''not''' require libvirtd to be running or configured, although the second statement hasn't been verified.<br />
<br />
#!/bin/bash<br />
<br />
echo "Starting Samba"<br />
sudo systemctl start smbd.service<br />
sudo systemctl start nmbd.service<br />
<br />
echo "Starting Synergy"<br />
/usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
# This is probably not neccesary, except when updating the OVMF bios<br />
# echo "Removing old OVMF variables"<br />
# rm -v ./Windows_ovmf_vars_x64.bin<br />
# echo "Copying new OVMF variables"<br />
# cp -v /usr/share/ovmf/x64/ovmf_vars_x64.bin ./Windows_ovmf_vars_x64.bin<br />
<br />
echo "Exporting PulseAudio driver"<br />
export QEMU_AUDIO_DRV="pa"<br />
<br />
echo "Starting VM"<br />
sudo \<br />
qemu-system-x86_64 \<br />
-serial none \<br />
-parallel none \<br />
-nodefaults \<br />
-nodefconfig \<br />
-enable-kvm \<br />
-name Windows \<br />
-cpu host,kvm=off,check \<br />
-smp sockets=1,cores=4,threads=2 \<br />
-m 12288 \<br />
-soundhw hda \<br />
-device ich9-usb-uhci3,id=uhci \<br />
-device usb-ehci,id=ehci \<br />
-device nec-usb-xhci,id=xhci \<br />
-drive if=pflash,format=raw,readonly,file=/usr/share/ovmf/x64/ovmf_code_x64.bin \<br />
-drive if=pflash,format=raw,file=./Windows_ovmf_vars_x64.bin \<br />
-rtc base=localtime \<br />
-boot order=c \<br />
-net nic,vlan=0,macaddr=52:54:00:00:00:01,model=virtio,name=net0 \<br />
-net bridge,vlan=0,name=bridge0,br=br0 \<br />
-drive if=virtio,id=drive0,file=./Windows.img,format=raw,cache=none,aio=native \<br />
-nographic \<br />
-device vfio-pci,host=04:00.0,addr=09.0,multifunction=on \<br />
-device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# For GPU sound<br />
# add ",multifunction=on" to GPU<br />
# -device vfio-pci,host=04:00.1,addr=09.1<br />
<br />
# Standard VGA<br />
# Remove "-nographic \" and "-device vfio-pci" lines<br />
# -vga std<br />
<br />
# Install<br />
# In addination to the steps "Standard VGA", add or change these options<br />
# -boot order=d \<br />
# -device ide-cd,drive=drive-cd-disk1,id=cd-disk1,unit=0,bus=ide.0 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/Windows_10.img,if=none,id=drive-cd-disk1,media=cdrom \<br />
# -device ide-cd,drive=drive-cd-disk2,id=cd-disk2,unit=0,bus=ide.1 \<br />
# -drive file=/run/media/melvin/primarydata/Data/OS/virtio-win-0.1.109.iso,if=none,id=drive-cd-disk2,media=cdrom \<br />
<br />
echo "VM closed"<br />
<br />
echo "Stopping Synergy"<br />
pkill synergys<br />
<br />
echo "Stopping Samba"<br />
sudo systemctl stop smbd.service<br />
sudo systemctl stop nmbd.service<br />
<br />
<br />
For more information regarding this example see [https://www.redhat.com/archives/vfio-users/2015-August/msg00020.html this email at Red Hat's vfio-users list].<br />
<br />
== Control VM via 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). See [[Synergy]] arch wiki page for more information.<br />
<br />
To control the VM using Synergy, first [[pacman|install]] the {{pkg|synergy}} package.<br />
<br />
Additionally, ensure that you are not passing your keyboard or mouse through to the VM, as the Synergy server will be running on the host and thus need access to those devices.<br />
<br />
Create the synergy server config.<br />
<br />
{{hc|<nowiki>/etc/synergy.conf</nowiki>|<nowiki># Example config<br />
section: screens<br />
vm:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
host:<br />
halfDuplexCapsLock = false<br />
halfDuplexNumLock = false<br />
halfDuplexScrollLock = false<br />
xtestIsXineramaUnaware = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end<br />
<br />
section: aliases<br />
vm:<br />
10.0.2.15 # default for vm<br />
host:<br />
10.0.2.2 # default for host<br />
end<br />
<br />
section: links<br />
vm:<br />
right = host<br />
host:<br />
left = vm<br />
end<br />
<br />
section: options<br />
relativeMouseMoves = false<br />
screenSaverSync = true<br />
win32KeepForeground = false<br />
switchCorners = none <br />
switchCornerSize = 0<br />
end</nowiki>}}<br />
<br />
Replace {{ic|1=vm}} and {{ic|1=host}} with the hostnames of your Virtual Machine and host OS respectively.<br />
<br />
Before you start qemu or within your startup script:<br />
<br />
$ /usr/bin/synergys --daemon --config /etc/synergy.conf<br />
<br />
Now download and configure synergy as a client on the Virtual Machine. Exact configurations depend on the virtual OS. However, if you are running QEMU in User Networking Mode (default), the default IP of the host is {{ic|1=10.0.2.2}}.<br />
<br />
== Operating system ==<br />
<br />
Depending on your operating system, you may find that it may refuse to boot after a certain point. To work around this, simply replace {{ic|-vga none}} to {{ic|-vga qxl}}, install your operating system, check Device Manager and see if your graphics card has PCI device id equal to your actual GPU and install the graphics card driver, and then change it back to {{ic|-vga none}}.<br />
<br />
== Make Nvidia's GeForce Experience work ==<br />
<br />
If GeForce Experience complains about an unsupported CPU being present and some features, e.g. game optimization, don't work, passing the {{ic|1=ignore_msrs=1}} option to the KVM module will most likely solve the problem by ignoring accesses to unimplemented MSRs:<br />
<br />
{{hc|<nowiki>/etc/modprobe.d/kvm.conf</nowiki>|<nowiki>...<br />
options kvm ignore_msrs=1<br />
...</nowiki>}}<br />
<br />
{{Warning|Silently ignoring unknown MSR accesses could potentially break other software within the VM or other VMs.}}<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]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Talk:PCI_passthrough_via_OVMF&diff=403435Talk:PCI passthrough via OVMF2015-10-05T17:09:41Z<p>Physicist1616: /* Article Specificity */ new section</p>
<hr />
<div>== Missing links ==<br />
<br />
"cp -R ./usr/share /usr/share" creates "/usr/share/share" with the contents of .usr/share in it. I don't think you can do the copy with one command.<br />
Do you have plans to update the missing links? I'm referring to this paragraph: "This will be the BIOS that the VM will use. Non-UEFI users may need to use i440fx without OVMF, and the i915 vga arbiter patch for Intel graphics as host, see this forum thread. For users that do have a UEFI compatible motherboard but a UEFI incompatible graphics card, look at this post." [[User:Wmarler|Wmarler]] ([[User talk:Wmarler|talk]]) 05:42, 3 April 2015 (UTC)<br />
<br />
== Qemu permissions ==<br />
<br />
I didn't need to change the qemu permissions to make passing through vfio devices work. Here's what I have:<br />
<br />
{{hc|<nowiki>/etc/libvirt/qemu.conf</nowiki>|<nowiki>...<br />
#user = "root"<br />
group="78"<br />
#clear_emulator_capabilities = 1<br />
...<br />
#cgroup_device_acl = [<br />
# "/dev/null", "/dev/full", "/dev/zero",<br />
# "/dev/random", "/dev/urandom",<br />
# "/dev/ptmx", "/dev/kvm", "/dev/kqemu",<br />
# "/dev/rtc","/dev/hpet", "/dev/vfio/vfio"<br />
#]<br />
...</nowiki>}}<br />
<br />
[[User:M01|M01]] ([[User talk:M01|talk]])<br />
<br />
== Article Specificity ==<br />
<br />
I see that this article's title is focused on OVMF, but it seems to allow an alternate method as well.<br />
<br />
Considering that PCI Passthrough would be a user's goal and the "via OVMF" is only one of several details involved in the "How", it makes sense to me to move the article to "PCI Passthrough". Am I by-chance just not seeing the actual page-title of the main article on this subject?<br />
<br />
Thoughts?<br />
<br />
(Sidenote, adding info about the [[linux-vfio]] packages in AUR to the Installation section... they look like the crux of the whole thing and I didn't know they existed because no mention of them exists anywhere else on the wiki.)<br />
<br />
[[User:Physicist1616|Physicist1616]] ([[User talk:Physicist1616|talk]]) 17:09, 5 October 2015 (UTC)</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361824Mad Catz Mouse2015-02-19T11:19:20Z<p>Physicist1616: /* RAT7 or RAT9 Partial Fix */</p>
<hr />
<div>[[Category:Mice]]<br />
Mad Catz produces a series of gaming mice, for example the Saitek Cyborg R.A.T.3 Mouse (7 buttons USB wired) or the R.A.T9 (7 buttons USB wireless). The mice do not work properly in X without some reconfiguration. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
* Closing certain windows restores functionality until the mouse locks into a new window.<br />
<br />
<br />
==The Disable Button Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
== RAT7 or RAT9 Partial Fix==<br />
This is the configuration file that will get your R.A.T. 7 or R.A.T. 9 mouse working properly under linux. <br />
*Does not fix the change-profile button for RAT9, this profile needs more adjustment or just don't push it.<br />
<br />
{{ic|/etc/X11/xorg.conf.d/910-rat.conf}}:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz M.M.O.7 Mouse"<br />
MatchIsPointer "true"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Buttons" "24"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"<br />
Option "AutoReleaseButtons" "13 14 15"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
You can define different keystrokes applied to each mouse button by defining them in {{ic|~/.xbindkeysrc}} eg.:<br />
<br />
# pressing mouse button 7 sends keystroke: 2<br />
"xvkbd -text 2"<br />
m:0x0 + b:7<br />
# pressing mouse button 8 sends keystroke: Space<br />
"xvkbd -text "\[SPACE]""<br />
m:0x0 + b:8<br />
# pressing mouse button 9 sends keystroke: F8<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:9<br />
# pressing mouse button 10 sends keystroke: CursorLeft<br />
"xvkbd -text "\[Left]""<br />
m:0x0 + b:10<br />
# pressing mouse button 11 sends keystroke: Shift+F2<br />
"xvkbd -text "\[Shift]\[F2]""<br />
m:0x0 + b:11<br />
<br />
A very good article on setting up the Mad Catz M.M.O.7 mouse with Linux is written [https://delightlylinux.wordpress.com/2013/07/29/using-the-mad-catz-m-m-o-7-with-linux-mint-and-ubuntu/ here].<br />
<br />
==Manual Button Mapping Fix==<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361823Mad Catz Mouse2015-02-19T11:19:07Z<p>Physicist1616: /* RAT7 or RAT9 Full Fix */ Noted that one button listed in the RAT7&9 section isn't working yet.</p>
<hr />
<div>[[Category:Mice]]<br />
Mad Catz produces a series of gaming mice, for example the Saitek Cyborg R.A.T.3 Mouse (7 buttons USB wired) or the R.A.T9 (7 buttons USB wireless). The mice do not work properly in X without some reconfiguration. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
* Closing certain windows restores functionality until the mouse locks into a new window.<br />
<br />
<br />
==The Disable Button Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
== RAT7 or RAT9 Partial Fix==<br />
This is the configuration file that will get your R.A.T. 7 or R.A.T. 9 mouse working properly under linux. <br />
**Does not fix the change-profile button for RAT9, this profile needs more adjustment or just don't push it.**<br />
<br />
{{ic|/etc/X11/xorg.conf.d/910-rat.conf}}:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz M.M.O.7 Mouse"<br />
MatchIsPointer "true"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Buttons" "24"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"<br />
Option "AutoReleaseButtons" "13 14 15"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
You can define different keystrokes applied to each mouse button by defining them in {{ic|~/.xbindkeysrc}} eg.:<br />
<br />
# pressing mouse button 7 sends keystroke: 2<br />
"xvkbd -text 2"<br />
m:0x0 + b:7<br />
# pressing mouse button 8 sends keystroke: Space<br />
"xvkbd -text "\[SPACE]""<br />
m:0x0 + b:8<br />
# pressing mouse button 9 sends keystroke: F8<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:9<br />
# pressing mouse button 10 sends keystroke: CursorLeft<br />
"xvkbd -text "\[Left]""<br />
m:0x0 + b:10<br />
# pressing mouse button 11 sends keystroke: Shift+F2<br />
"xvkbd -text "\[Shift]\[F2]""<br />
m:0x0 + b:11<br />
<br />
A very good article on setting up the Mad Catz M.M.O.7 mouse with Linux is written [https://delightlylinux.wordpress.com/2013/07/29/using-the-mad-catz-m-m-o-7-with-linux-mint-and-ubuntu/ here].<br />
<br />
==Manual Button Mapping Fix==<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mouse_buttons&diff=361821Mouse buttons2015-02-19T10:58:02Z<p>Physicist1616: /* Mad Catz M.M.O.7 Mouse */ Rephrased heading to make it more brand generic.</p>
<hr />
<div>[[ru:Get All Mouse Buttons Working]]<br />
[[zh-TW:Get All Mouse Buttons Working]]<br />
[[Category:Mice]]<br />
[[Category:X Server]]<br />
{{out of date|rc.conf refs, style still to fix, unclear sections}}<br />
This article is for users that have a mouse with more than 7 mouse buttons and want to be able to use all of them. Logitech makes several of these (if you have a [http://www.logitech.com/index.cfm/mice_pointers/trackballs/devices/156&cl=us,en Logitech Marble&reg; Mouse] you can also look at [[Logitech_Marble_Mouse|this page]]), and Microsoft makes a few as well.<br />
<br />
== Prerequisites ==<br />
<br />
{{Note|These are helper comments, and can be ignored if you are looking for nothing but raw information. Due to community feedback, I decided to add a bit more commenting that describes what's going on "behind the scenes" with this configuration.}}<br />
<br />
We will be using the {{ic|evdev}} driver for Xorg. EVentDEVice is an advanced driver for USB input devices which offers much greater power over the standard Xorg {{ic|mouse}} driver. It is also more "direct" than the {{ic|mouse}} driver, allowing lower latency and less translation issues.<br />
<br />
*Note that {{Ic|evdev}} is both a kernel module and an Xorg input driver. All the Arch kernels come with the {{Ic|evdev}} module.<br />
<br />
With the newer Xorg 11R7.0 it seems only the following changes to {{ic|/etc/X11/xorg.conf}} need to be made with nothing else needing to be done.<br />
<br />
== Finding the mouse name ==<br />
<br />
{{Note|To get accurate information it is sometimes required to execute this command from a boot where no Xorg or mouse drivers have been loaded.}}<br />
<br />
The first step is to find the name of the mouse. To do this, execute the following command:<br />
$ egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
This should output something like this:<br />
N: Name="Logitech USB Gaming Mouse"<br />
H: Handlers=mouse0 event0 ts0 <br />
N: Name="HID 0566:3002"<br />
H: Handlers=kbd event1 <br />
<br />
The mouse is the one that has the {{Ic|<nowiki>Handlers=mouse0</nowiki>}}, so the name of the device is {{ic|Logitech USB Gaming Mouse}}.<br />
<br />
{{Note|My mouse is a Logitech G5; your mouse is probably different, and therefore the {{Ic|Name}} will be different.}}<br />
<br />
Copy the name of the device, and open up {{ic|/etc/X11/xorg.conf}}.<br />
<br />
== Configuring Xorg ==<br />
<br />
Now, we need an entry in {{ic|xorg.conf}} that tells X how to use this mouse. It should look something like this:<br />
<br />
Section "InputDevice"<br />
Identifier "Evdev Mouse"<br />
Driver "evdev"<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "evBits" "+1-2"<br />
Option "keyBits" "~272-287"<br />
Option "relBits" "~0-2 ~6 ~8"<br />
Option "Pass" "3"<br />
Option "CorePointer"<br />
EndSection<br />
<br />
Replace the {{Ic|Name}} option with the name you copied from above. You may also omit the {{ic|CorePointer}} option if you use multiple mice or experience errors when attempting to load Xorg. The other options are all basic mouse configurations for evdev and should work with most mice.<br />
<br />
Next, we need to tell X to use the mouse, so look in {{ic|xorg.conf}} for {{Ic|ServerLayout}}.<br />
<br />
Modify the {{ic|ServerLayout}} section to use "Evdev Mouse" as the device. When you are done, it should look something like this:<br />
<br />
Section "ServerLayout"<br />
Identifier "Default Layout"<br />
Screen 0 "Monitor0" 0 0<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
InputDevice "Evdev Mouse" "CorePointer"<br />
EndSection<br />
<br />
The only thing you should change in the layout is the {{ic|InputDevice}} line that refers to your mouse.<br />
<br />
That should be all that is required.<br />
<br />
* Edit by: xxsashixx <br />
This is for Logitech G5 Mouse users. I have not tested this for other mice, but if you do not add this, your mouse ''MAY'' not work.<br />
If you do not need to add this, then don't.<br />
<br />
Put <br />
Option "Device" "/dev/input/event[#]"<br />
in the {{Ic|InputDevice}} section or else the mouse will not be picked up.<br />
<br />
[#] = The number you got from:<br />
egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
* Edit by: bapman<br />
With the above method, your mouse might not to work after reboot (event number changes). To fix this, you can use symlinks in {{ic|/dev/input/by-id}}. For example:<br />
Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse"<br />
To find the appropriate id, do:<br />
ls /dev/input/by-id/<br />
<br />
* Edit by: Diamir<br />
{{Out of date|The udev rule will not work, the {{ic|1=SYSFS=}} and {{ic|1=BUS=}} keys have been removed [https://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021795.html].}}<br />
With a Desktop type keyboard-mouse, this does not work because there is only one USB attachment and {{ic|/dev/input/by-id}} contains only the keyboard.<br />
In this case, we can create a udev rule to get a consistent link.<br />
The following rules create the link {{ic|/dev/input/usbmouse}} which points on the correct event entry:<br />
KERNEL=="event[0-9]*", BUS=="usb", SYSFS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00", SYMLINK+="input/usbmouse"<br />
<br />
You can call it {{ic|z10_usb_mouse.rules}} and put it in {{ic|/etc/udev/rules.d}}<br />
<br />
The cryptic value to use for {{ic|SYSFS(modalias)}} can be get the following way:<br />
<br />
enter the command {{ic|cat /proc/bus/input/devices}}<br />
<br />
You will find the keyboard and the mouse and see event4 is the mouse in this case: <br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input0<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.0/input/input3<br />
U: Uniq=<br />
H: Handlers=kbd event0 <br />
B: EV=120013<br />
B: KEY=1000000000007 ff800000000007ff febeffdff3cfffff fffffffffffffffe<br />
B: MSC=10<br />
B: LED=107<br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input1<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.1/input/input4<br />
U: Uniq=<br />
H: Handlers=kbd mouse0 event1 <br />
B: EV=17<br />
B: KEY=3000000000000 0 1f0000 f8400244000 601878d800d448 1e000000000000 0<br />
B: REL=7c3<br />
B: MSC=10<br />
<br />
So I enter the following command (adapt event # to your particular case):<br />
{{bc|1=udevinfo -a -p $(udevinfo -q path -n /dev/input/event4) &#124; grep modalias<br />
ATTRS{modalias}=="input:b0003v045Ep008Ae0111-0,1,2,4,k71,72,73,74,83,86,8A,8C,8E,8F,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,B5,B6,CE,D2,D5,E2,E7,E8,E9,EA,EB,110,111,112,113,114,1B0,1B1,r0,1,6,7,8,9,A,am4,lsfw"<br />
ATTRS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00"<br />
ATTRS{modalias}=="pci:v00001106d00003038sv00001043sd000080EDbc0Csc03i00"}}<br />
<br />
grab the ATTRS which becomes with usb: to complete "SYSFS{modalias}== " entry<br />
<br />
And finally, use {{ic|usbmouse}} as the Device Option in {{ic|xorg.conf}}:<br />
Option "Device" "/dev/input/usbmouse"<br />
<br />
== Post Configuration ==<br />
<br />
=== Google Chrome ===<br />
<br />
It works. Horizontal scroll works out of the box - push the scroll wheel left or right. Thumb buttons also work as next/previous page.<br />
<br />
=== Opera ===<br />
<br />
It works. Note: buttons can be mapped to functions easily in {{Ic|Preferences > Advanced > Shortcuts > Mouse set-up}}. For example, to bind ''button 8'' to ''back'':<br />
<br />
# Navigate to mouse set-up and expand the ''Application'' drop-down<br />
# In the input column, type: ''Button 8''<br />
# In the actions column, type: ''Back''<br />
<br />
=== Firefox ===<br />
<br />
==== Horizontal scroll ====<br />
<br />
<br />
=====Firefox 20 and Newer=====<br />
(Tested in version 32)<br />
To get back and forward enabled, instead of scroll left/right, change the following settings in {{ic|about:config}}:<br />
<br />
mousewheel.default.action.override_x 2<br />
mousewheel.default.delta_multiplier_x -100<br />
<br />
=====Older Versions=====<br />
<br />
By default, left right scroll on a FX/MX mouse translates into back/forward, respectively. If you do not like this, open {{ic|about:config}} and change a few values:<br />
<br />
mousewheel.horizscroll.withnokey.action 0<br />
mousewheel.horizscroll.withnokey.numlines -3<br />
<br />
OR (tested on Logitech G5)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines 2<br />
<br />
NOTE: If you use a positive value for numlines, your left/right will switch, ie: pressing left scrolls the window to the right.<br />
<br />
=== Firefox 3 ===<br />
<br />
OR (tested on Microsoft Wireless Intellimouse explorer 2.0)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines -1<br />
mousewheel.horizscroll.withnokey.sysnumlines false<br />
<br />
{{Note | If you use the true value for numlines, your left/right will be inverted.}}<br />
<br />
<br />
==== Thumb Buttons - forward and back ====<br />
<br />
{{Note | The following maybe redundant depending on whether xev detects all your mouse buttons correctly (functions can be mapped on a per-app basis) or you want to change the default behaviour.}}<br />
<br />
To do this we need to map keystrokes to the desired mouse buttons and install {{Pkg|xvkbd}} and {{Pkg|xbindkeys}}.<br />
<br />
In most modern applications which use back/forward features, XF86Back is mapped to back and XF86Forward is mapped to forward by default. On most MX mice the thumb buttons resolve to 8 & 9. If your mouse is different, check button numbers using xev and replace the numbers used in the example (b:8 & b:9).<br />
<br />
So if you have an MX mouse you would create the file ~/.xbindkeysrc, containing:<br />
<br />
# Mouse Buttons<br />
"xvkbd -xsendevent -text "\[XF86Back]""<br />
m:0x0 + b:8 <br />
"xvkbd -xsendevent -text "\[XF86Forward]""<br />
m:0x0 + b:9<br />
<br />
Now to test... Run the following command and if it works as expected remember to add xbindkeys to {{ic|.xinitrc}} or somewhere where it will be executed each time X starts. Also, this should work with Epiphany and Konqueror without any additional configuration or use of [[Imwheel]].<br />
xbindkeys<br />
<br />
The above info and more help may be found in the [[MX1000_Buttons]] wiki.<br />
<br />
=== xmodmap tweaking ===<br />
<br />
{{Note | None of the below is necessary with evdev, but it's here for non-evdev users. Unless something doesn't work on your mouse, ignore this whole section!}}<br />
<br />
If you use .xinitrc to load X, then add this to {{ic|.xinitrc}} (change for the number of buttons you have):<br />
xmodmap -e "pointer = 1 2 3 6 7 8 9 10 11 12 4 5" &<br />
<br />
Note that buttons 4 and 5 '''must go on the end''' or else your scroll wheel won't work.<br />
<br />
If you use GDM/XDM/KDM instead of .xinitrc, then create the file {{ic|~/.Xmodmap}} and add this to it (change for the number of buttons you have):<br />
pointer = 1 2 3 6 7 8 9 10 11 12 4 5<br />
<br />
* GDM/XDM/KDM read the {{ic|~/.Xmodmap}} file if it's present, whereas {{Ic|startx}} does not. Another solution would be to add this to your ~/.xinitrc: {{Ic|xmodmap -e $(cat ~/.Xmodmap)}}. This would allow you to use *DM and {{Ic|startx}} while only having to edit {{ic|~/.Xmodmap}} when you need to make changes.<br />
<br />
You may have to play with these numbers a bit to get your desired behavior. Some mice use buttons 6 and 7 for the scroll wheel, in which case those buttons would have to be the last numbers. Keep playing with it until it works!<br />
<br />
You can also check to see which buttons are being read with a program called 'xev', which is part of XOrg. When xev is run, it will show a box on your desktop that you can put the cursor into and click buttons to find out what buttons have been mapped.<br />
<br />
== Alternate methods ==<br />
<br />
The following methods use standard X.org mouse input driver (xf86-input-mouse) instead of using the evdev driver. It works on mice up to 7 buttons. Edit {{ic|/etc/X11/xorg.conf}} InputDevice section for your mouse to reflect the changes shown below. Then restart X and you're done.<br />
<br />
=== Method 1 - IMPS/2 ===<br />
<br />
This has been tested on an IntelliMouse Explorer 3.0. Your mileage may vary, as this does not seem to work for all said mice.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
<br />
=== Method 2 - ExplorerPS/2 ===<br />
<br />
This has been tested on a Logitech MX400 and MX518 and should work on any mx series mouse with up to 7 buttons. <br />
<br />
Driver "mouse"<br />
Option "Protocol" "ExplorerPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
Settings from above also works for Microsoft InteliMouse Explorer 3.0 that connects through USB.<br />
<br />
=== Method 3 - Auto ===<br />
<br />
This has been tested on a Logitech MX400 and should work on most mice with up to 7 buttons.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
This has been tested to work with Logitech MX1000.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "12"<br />
Option "ZAxisMapping" "4 5 7 6 8 9"<br />
<br />
=== Method 4 - btnx ===<br />
<br />
{{Deletion|Though very convenient, btnx is no longer available. Its developper states "btnx might not work as intended on some distros anymore" and it is advised to use {{Pkg|easystroke}} instead.}}<br />
[http://www.ollisalonen.com/btnx/ btnx: Button Extension &ndash; a GNU/GPL mouse tool for GNU/Linux]<br />
<br />
This allows the use of all buttons on the Logitech MX Revolution and reportedly other multi-button mice as well. Provides greater control & configuration than the evdev driver.<br />
<br />
btnx is a daemon, as such it needs to be configured as root, and its actions are available to all users.<br />
<br />
Install via AUR: {{AUR|btnx-config}} then {{AUR|btnx}}. Be sure the {{ic|xorg.conf}} "Device" is at the default {{ic|/dev/input/mice}} rather than {{ic|evdev}}.<br />
<br />
Then configure your buttons by running btnx-config as root:<br />
btnx-config<br />
Save your configuration and start btnx daemon (as root):<br />
rc.d start btnx<br />
You're likely to want this daemon to be started during boot, so add it to the DAEMONS array of you're /etc/rc.conf<br />
DAEMONS=(.... @btnx ....)<br />
<br />
=== Method 5 - easystroke ===<br />
<br />
[http://sourceforge.net/projects/easystroke/ easystroke is a gesture-recognition application for X11]<br />
<br />
easystroke is a mouse gesture application, but it can be used to manage mouse buttons as well. It's main advantage o-ver btnx is that it's more versatile. On the other hand, it's user-based, so any user has to configure it to reflect his own needs. <br />
<br />
In order to set up easystroke to manage your extra mouse buttons, you'll need to do this (example features Back/Forward mouse buttons) :<br />
run:<br />
easystroke -g<br />
Go to Preferences tab > Additional buttons > Add, and add any special button.<br />
{{Note|In case of easystroke doesn't automatically detect mouse buttons, you can specify it manually. Button identifiers (numbers) can be viewed by xev.}}<br />
<br />
Go to ''Action tab > Add action'', give the new action a name, as Type choose "Key", as Details set "Alt+Left" for Back button, "Alt+Right" for Forward button, as Stroke click the proper mouse button (confirm if a warning is displayed), and voilà! Your mouse button is configured.<br />
<br />
{{Note|Since Firefox 3, buttons 6 + 7 are no longer mapped to back and forward as in Firefox 2. Therefore, if using the above methods in Xorg, refer further to corrective methods below if necessary.}}<br />
<br />
=== Firefox 3 button 6 + 7 correction ===<br />
<br />
For MX518, try changing the above ButtonMapping Option to:<br />
Option "ButtonMapping" "1 2 3 8 9" <br />
And restart X. (Successfully tested on MX518)<br />
<br />
Another method:<br />
<br />
Leave back/forward mapped to 6+7 in xorg. In Firefox 3 about:config change the following keys:<br />
<br />
mousewheel.horizscroll.withnokey.action = 2<br />
mousewheel.horizscroll.withnokey.numlines = -1<br />
mousewheel.horizscroll.withnokey.sysnumlines = false<br />
<br />
== Binding keyboard to mouse buttons ==<br />
<br />
=== xvkbd and xbindkeys ===<br />
<br />
Let's say we want to bind some mouse buttons to keyboard ones. The problem we will encounter is that we do not know how to emulate a key press. Here comes in handy {{Pkg|xvkbd}}. We can use it along with {{Pkg|xbindkeys}}. <br />
<br />
$ xbindkeys --defaults >> ~/.xbindkeysrc<br />
$ xbindkeys<br />
<br />
To restart xbindkeys type:<br />
<br />
$ pkill -f xbindkeys<br />
$ xbindkeys <br />
<br />
Here's example {{Ic|~/.xbindkeysrc}} config:<br />
<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:8<br />
"xvkbd -text "\[Shift]\[Left]""<br />
m:0x0 + b:9<br />
"xvkbd -text "\[Shift]\[Right]""<br />
m:0x0 + b:10<br />
"xvkbd -text 2"<br />
m:0x0 + b:11<br />
"xvkbd -text 3"<br />
m:0x0 + b:12<br />
<br />
If you want to check your mouse buttons number use xev. Don't forget to type capital letters in xvkbd -text usage and to escape opening bracket with \ or you get simply [Shift] written.<br />
<br />
Here is an example for xbindkeys to enable x selection paste(third click pasting), you need both xsel and xvkbd installed, What it does it executes that command whenever button 13 of the mouse is pressed (in ~/.xbindkeysrc) :<br />
<br />
"xvkbd -no-jump-pointer -text "\D1$(xsel)" 2>/dev/null"<br />
b:13<br />
<br />
=== Why standard methods are not enough? ===<br />
<br />
This will work great for X servers, but it seems not to work in some specific situations, like in Enemy Territory game. So I will describe a bit more advanced configuration, which work with my logitech G5 buttons - I can use all my 5 additional buttons along with 3 standard and a scroll, which gives overall 10 events to use in Enemy Territory. So here we go:<br />
<br />
{{Note | '''Update:''' evrouter can now simulate X11 key events so it is now possible to skip [[Get_All_Mouse_Buttons_Working#kbde|kbde]] and only use [[Get_All_Mouse_Buttons_Working#evrouter|evrouter]] to bind keyboard buttons to your mouse. }}<br />
<br />
=== kbde ===<br />
<br />
To emulate keystroke which will be later detected in Enemy Territory we need something more advanced than xvkbd. Here comes in handy kbde, but it doesn't exist in the AUR yet &ndash; we've got to compile it by ourselves. We need two programs: kbde and kbde-driver. Kbde website is located on sourceforge [http://kbde.sourceforge.net/], check it for download, you need only kbde-driver. Apparently, it doesn't work for me without some hacking. Use your editor and add <br />
<br />
#include <linux/version.h><br />
<br />
somewhere near other includes in the driver/kbde.c file. (OK, I'm not sure whether it is a proper way to compile it, but it works).<br />
Assuming that you've already done that try:<br />
<br />
tar -zxvf kbde-driver-1*<br />
cd kbde-driver-1*<br />
make<br />
# if you do not have sudo just use su and type this as root<br />
sudo make install mknod<br />
modprobe kbde<br />
<br />
and now you should have kbde working. If you want to use it as a non-root (yes, you want) change permissions, the quickest and dirtiest way is (note that I added my startup scripts at the end of this text):<br />
<br />
chgrp users /dev/kbde<br />
chmod 220 /dev/kbde<br />
<br />
If not try reading installation instructions on the site. Now we can use it to emulate keystrokes visible even in login shells:<br />
<br />
kbde --press 5 --release 5 -b<br />
<br />
this will press 5 for about three times. If you want to type a string using this, rather than this use --asci=STRING, as press sometimes generates 3 strokes before it is released.<br />
<br />
=== evrouter ===<br />
<br />
Now we need something which will work when Enemy Territory is loaded. Apparently, xbindkeys does not work here, so we need another program: evrouter [http://www.bedroomlan.org/~alexios/coding_evrouter.html], which can be found in the AUR: {{AUR|evrouter}}<br />
<br />
OK, so now we must have evdev and we can NOT use it in X, so here is how my example {{ic|/etc/X11/xorg.conf}} mouse section looks like:<br />
<br />
Section "InputDevice"<br />
<br />
Identifier "Logitech G5"<br />
<br />
Driver "mouse"<br />
Option "Protocol" "Auto"<br />
Option "Device" "/dev/input/mouse1" # probably you'll need here mouse0<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "Buttons" "8" # set this to your number of buttons<br />
Option "ZAxisMapping" "4 5"<br />
<br />
EndSection<br />
<br />
and now we have to restart the X server. <br />
You will run this as user, and event devices are owned by root, so you got to change the permissions at this point. Let us say we do it just like that, but I advise you to do this more carefully (note that I added my start-up scripts at the end of this text):<br />
<br />
chgrp users /dev/input/event*<br />
chmod 660 /dev/input/event*<br />
<br />
Now we can use the {{ic|--dump}} option to check what we will have to bind and to which device:<br />
<br />
evrouter --dump /dev/input/event*<br />
# here click buttons you would like to bind<br />
<br />
It will give you output similar to config. Here is my example config {{ic|~/.evrouterrc}} with kbde usage:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "SHELL/kbde --press 2 --release 2 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/279 "SHELL/kbde --press 3 --release 3 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/274 "SHELL/kbde --press 4 --release 4 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/277 "SHELL/kbde --press 5 --release 5 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/276 "SHELL/kbde --press 6 --release 6 -b"<br />
<br />
Same config using evrouters built in X11 key event emulator instead of kbde:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/2"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/3"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/4"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/5"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/6"<br />
<br />
This works great, even in Enemy Territory. The "none" modifier means that I have to only press the button, other options are {{ic|Ctrl+Alt}} and so on. Here I use "any" because "none" means that after pressing {{ic|Shift}}, {{ic|Ctrl}}, or {{ic|Alt}}, our buttons would not work. Also note that it accepts regular expressions for mouse name and event path. Then, after setting up a config, run service with:<br />
<br />
evrouter /dev/input/event* >> /dev/null<br />
<br />
or change the {{Ic|event*}} to a device corresponding to your mouse -- but be aware that the numbers are changing sometimes. It will work in background, while outputting some annoying messages, so we stream it to {{ic|/dev/null}}. If something went wrong, run it without streaming and check what it outputs. If you want to end it, you have to delete {{ic|/tmp/evrouter.*}} manually. Here is a script to kill evrouter:<br />
<br />
#!/bin/bash<br />
evrouter -q<br />
rm -f /tmp/.evrouter*<br />
<br />
and here is one to start it:<br />
<br />
#!/bin/bash<br />
mydevicename="Logitech USB Gaming Mouse"<br />
<br />
device=$(evrouter -D /dev/input/event* | grep "$mydevicename") | cut -d ":" -f 2<br />
evrouter $device > /dev/null<br />
<br />
You have to edit the {{Ic|mydevicename}} variable to its proper value (the one which is shown by {{Ic|evrouter -D}}), or just change it to listen on all events by changing device var to {{Ic|/dev/input/event*}}. OK, I have saved them in {{ic|/usr/bin/}}. Now, everything should be ready for use!<br />
<br />
=== Binding + and - in Logitech G5 mouse ===<br />
<br />
If you want to bind the buttons {{ic|+}} and {{ic|-}} in G5/7 mouse, which normally changes DPI, you have to use {{Ic|g5hack}} [http://piie.net/temp/g5_hiddev.c] released by a lomoco author.<br />
<br />
<nowiki>wget http://piie.net/temp/g5_hiddev.c</nowiki><br />
gcc -o g5hack g5_hiddev.c<br />
./g5hack /dev/usb/hiddev0 3<br />
<br />
This will change your DPI to 2000, light the 1st LED and disables DPI on-the-fly changing, so you can use it with evrouter. If you would use it frequently I suggest you to copy it to the {{ic|/usr/bin}} directory:<br />
<br />
# cp g5hack /usr/bin/<br />
<br />
If you want to bind your {{ic|+}} and {{ic|-}} buttons you must copy the line at the bottom (one with the comment '"-" button does not function anymore' above) to the mode you will be using, like, for example, under the "case 3:" you can put it on the line with the comment 'turn on third led' above (deleting the old one before of course).<br />
<br />
For the newest G5 mouse which is reported as "product 0xc049" original hack does not work. You have to simply change the {{ic|#define MOUSE_G5 0xc041}} to {{ic|#define MOUSE_G5 0xc049}} and recompile.<br />
<br />
=== startup scripts ===<br />
<br />
Currently, I am using a startup script with a few dirty methods, so if somebody can propose better, please edit. I have created an input group and made my user a member of it.<br />
<br />
{{ic|/etc/rc.local}}:<br />
<br />
#!/bin/bash<br />
# creating /dev/kbde nod and changing permissions<br />
# also do not forget to add kbde in modules line in /etc/rc.conf<br />
# to be honest, I'm not sure why we have to create /dev/kbde after each startup, but it seems that only this way it works<br />
# maybe first check if it's needed for you, too<br />
mknod --mode=220 /dev/kbde c 11 0 <br />
chgrp input /dev/kbde<br />
# changing permissions for event* -- evrouter needs that<br />
chmod 660 /dev/input/event*<br />
chgrp input /dev/input/event*<br />
# g5hack ran for a few times to make sure that it'll work...<br />
# note that I've add it to /usr/bin, you should probably put your full path here<br />
# you probably should skip this lines, especially if you do not have a Logitech g5/g3/g7<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
<br />
{{ic|~/.kde/Autostart/init}}:<br />
<br />
#!/bin/bash<br />
# there I use my script to start evrouter, which I have presented above<br />
evrouter-start<br />
# here I map my buttons so I can use G5 thumb button as push to talk in TS<br />
# note that I have to use it as middle button also on KDE<br />
# you probably do not need it<br />
xmodmap -e "pointer = 1 9 3 4 5 6 7 2 8 10 11 12"<br />
<br />
And voila, we've got it working immediately after KDE login.<br />
<br />
== User tools ==<br />
<br />
{{AUR|imwheel}} provides configurable mouse wheel and button mapping. It can be configured globally or for individual processes.<br />
<br />
Sample {{ic|~/.imwheelrc}} to enable back/forward thumb buttons for all applications and increased scroll speed in Chromium:<br />
"^chromium$"<br />
None, Up, Button4, 3<br />
None, Down, Button5, 3<br/><br />
".*"<br />
None, Thumb1, Alt_L|Left<br />
None, Thumb2, Alt_L|Right<br />
<br />
{{Pkg|lomoco}} for Logitech MX mice will help you set the proper resolution, enable or disable smart scroll (with boot time support too!), etc. lomoco is available from the {{Ic|[community]}} repository and can be installed with the following command:<br />
<br />
Be sure to look at {{ic|/etc/udev/lomoco_mouse.conf}} and set up the the options you want to be automatically applied when the mouse gets loaded by [[udev]].<br />
{{Note|The lomoco package may be out of date. There is a hack for newer Logitech mice: [http://piie.net/temp/g5_hiddev.c]}}<br />
<br />
==Device Specific Configuration Files==<br />
<br />
=== Mad Catz Mouse===<br />
<br />
[[Mad_Catz_Mouse]]<br />
<br />
== See also ==<br />
<br />
* http://www.gentoo-wiki.info/HOWTO_Advanced_Mouse<br />
For similar setup, specially for Logitech MX, see:<br />
* http://lotphelp.com/lotp/lotp-guide-logitech-mx-mouse-ubuntu</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mouse_buttons&diff=361819Mouse buttons2015-02-19T10:57:21Z<p>Physicist1616: /* Mad Catz M.M.O.7 Mouse */ Fixed improperly formatted intra-wiki link.</p>
<hr />
<div>[[ru:Get All Mouse Buttons Working]]<br />
[[zh-TW:Get All Mouse Buttons Working]]<br />
[[Category:Mice]]<br />
[[Category:X Server]]<br />
{{out of date|rc.conf refs, style still to fix, unclear sections}}<br />
This article is for users that have a mouse with more than 7 mouse buttons and want to be able to use all of them. Logitech makes several of these (if you have a [http://www.logitech.com/index.cfm/mice_pointers/trackballs/devices/156&cl=us,en Logitech Marble&reg; Mouse] you can also look at [[Logitech_Marble_Mouse|this page]]), and Microsoft makes a few as well.<br />
<br />
== Prerequisites ==<br />
<br />
{{Note|These are helper comments, and can be ignored if you are looking for nothing but raw information. Due to community feedback, I decided to add a bit more commenting that describes what's going on "behind the scenes" with this configuration.}}<br />
<br />
We will be using the {{ic|evdev}} driver for Xorg. EVentDEVice is an advanced driver for USB input devices which offers much greater power over the standard Xorg {{ic|mouse}} driver. It is also more "direct" than the {{ic|mouse}} driver, allowing lower latency and less translation issues.<br />
<br />
*Note that {{Ic|evdev}} is both a kernel module and an Xorg input driver. All the Arch kernels come with the {{Ic|evdev}} module.<br />
<br />
With the newer Xorg 11R7.0 it seems only the following changes to {{ic|/etc/X11/xorg.conf}} need to be made with nothing else needing to be done.<br />
<br />
== Finding the mouse name ==<br />
<br />
{{Note|To get accurate information it is sometimes required to execute this command from a boot where no Xorg or mouse drivers have been loaded.}}<br />
<br />
The first step is to find the name of the mouse. To do this, execute the following command:<br />
$ egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
This should output something like this:<br />
N: Name="Logitech USB Gaming Mouse"<br />
H: Handlers=mouse0 event0 ts0 <br />
N: Name="HID 0566:3002"<br />
H: Handlers=kbd event1 <br />
<br />
The mouse is the one that has the {{Ic|<nowiki>Handlers=mouse0</nowiki>}}, so the name of the device is {{ic|Logitech USB Gaming Mouse}}.<br />
<br />
{{Note|My mouse is a Logitech G5; your mouse is probably different, and therefore the {{Ic|Name}} will be different.}}<br />
<br />
Copy the name of the device, and open up {{ic|/etc/X11/xorg.conf}}.<br />
<br />
== Configuring Xorg ==<br />
<br />
Now, we need an entry in {{ic|xorg.conf}} that tells X how to use this mouse. It should look something like this:<br />
<br />
Section "InputDevice"<br />
Identifier "Evdev Mouse"<br />
Driver "evdev"<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "evBits" "+1-2"<br />
Option "keyBits" "~272-287"<br />
Option "relBits" "~0-2 ~6 ~8"<br />
Option "Pass" "3"<br />
Option "CorePointer"<br />
EndSection<br />
<br />
Replace the {{Ic|Name}} option with the name you copied from above. You may also omit the {{ic|CorePointer}} option if you use multiple mice or experience errors when attempting to load Xorg. The other options are all basic mouse configurations for evdev and should work with most mice.<br />
<br />
Next, we need to tell X to use the mouse, so look in {{ic|xorg.conf}} for {{Ic|ServerLayout}}.<br />
<br />
Modify the {{ic|ServerLayout}} section to use "Evdev Mouse" as the device. When you are done, it should look something like this:<br />
<br />
Section "ServerLayout"<br />
Identifier "Default Layout"<br />
Screen 0 "Monitor0" 0 0<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
InputDevice "Evdev Mouse" "CorePointer"<br />
EndSection<br />
<br />
The only thing you should change in the layout is the {{ic|InputDevice}} line that refers to your mouse.<br />
<br />
That should be all that is required.<br />
<br />
* Edit by: xxsashixx <br />
This is for Logitech G5 Mouse users. I have not tested this for other mice, but if you do not add this, your mouse ''MAY'' not work.<br />
If you do not need to add this, then don't.<br />
<br />
Put <br />
Option "Device" "/dev/input/event[#]"<br />
in the {{Ic|InputDevice}} section or else the mouse will not be picked up.<br />
<br />
[#] = The number you got from:<br />
egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
* Edit by: bapman<br />
With the above method, your mouse might not to work after reboot (event number changes). To fix this, you can use symlinks in {{ic|/dev/input/by-id}}. For example:<br />
Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse"<br />
To find the appropriate id, do:<br />
ls /dev/input/by-id/<br />
<br />
* Edit by: Diamir<br />
{{Out of date|The udev rule will not work, the {{ic|1=SYSFS=}} and {{ic|1=BUS=}} keys have been removed [https://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021795.html].}}<br />
With a Desktop type keyboard-mouse, this does not work because there is only one USB attachment and {{ic|/dev/input/by-id}} contains only the keyboard.<br />
In this case, we can create a udev rule to get a consistent link.<br />
The following rules create the link {{ic|/dev/input/usbmouse}} which points on the correct event entry:<br />
KERNEL=="event[0-9]*", BUS=="usb", SYSFS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00", SYMLINK+="input/usbmouse"<br />
<br />
You can call it {{ic|z10_usb_mouse.rules}} and put it in {{ic|/etc/udev/rules.d}}<br />
<br />
The cryptic value to use for {{ic|SYSFS(modalias)}} can be get the following way:<br />
<br />
enter the command {{ic|cat /proc/bus/input/devices}}<br />
<br />
You will find the keyboard and the mouse and see event4 is the mouse in this case: <br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input0<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.0/input/input3<br />
U: Uniq=<br />
H: Handlers=kbd event0 <br />
B: EV=120013<br />
B: KEY=1000000000007 ff800000000007ff febeffdff3cfffff fffffffffffffffe<br />
B: MSC=10<br />
B: LED=107<br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input1<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.1/input/input4<br />
U: Uniq=<br />
H: Handlers=kbd mouse0 event1 <br />
B: EV=17<br />
B: KEY=3000000000000 0 1f0000 f8400244000 601878d800d448 1e000000000000 0<br />
B: REL=7c3<br />
B: MSC=10<br />
<br />
So I enter the following command (adapt event # to your particular case):<br />
{{bc|1=udevinfo -a -p $(udevinfo -q path -n /dev/input/event4) &#124; grep modalias<br />
ATTRS{modalias}=="input:b0003v045Ep008Ae0111-0,1,2,4,k71,72,73,74,83,86,8A,8C,8E,8F,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,B5,B6,CE,D2,D5,E2,E7,E8,E9,EA,EB,110,111,112,113,114,1B0,1B1,r0,1,6,7,8,9,A,am4,lsfw"<br />
ATTRS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00"<br />
ATTRS{modalias}=="pci:v00001106d00003038sv00001043sd000080EDbc0Csc03i00"}}<br />
<br />
grab the ATTRS which becomes with usb: to complete "SYSFS{modalias}== " entry<br />
<br />
And finally, use {{ic|usbmouse}} as the Device Option in {{ic|xorg.conf}}:<br />
Option "Device" "/dev/input/usbmouse"<br />
<br />
== Post Configuration ==<br />
<br />
=== Google Chrome ===<br />
<br />
It works. Horizontal scroll works out of the box - push the scroll wheel left or right. Thumb buttons also work as next/previous page.<br />
<br />
=== Opera ===<br />
<br />
It works. Note: buttons can be mapped to functions easily in {{Ic|Preferences > Advanced > Shortcuts > Mouse set-up}}. For example, to bind ''button 8'' to ''back'':<br />
<br />
# Navigate to mouse set-up and expand the ''Application'' drop-down<br />
# In the input column, type: ''Button 8''<br />
# In the actions column, type: ''Back''<br />
<br />
=== Firefox ===<br />
<br />
==== Horizontal scroll ====<br />
<br />
<br />
=====Firefox 20 and Newer=====<br />
(Tested in version 32)<br />
To get back and forward enabled, instead of scroll left/right, change the following settings in {{ic|about:config}}:<br />
<br />
mousewheel.default.action.override_x 2<br />
mousewheel.default.delta_multiplier_x -100<br />
<br />
=====Older Versions=====<br />
<br />
By default, left right scroll on a FX/MX mouse translates into back/forward, respectively. If you do not like this, open {{ic|about:config}} and change a few values:<br />
<br />
mousewheel.horizscroll.withnokey.action 0<br />
mousewheel.horizscroll.withnokey.numlines -3<br />
<br />
OR (tested on Logitech G5)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines 2<br />
<br />
NOTE: If you use a positive value for numlines, your left/right will switch, ie: pressing left scrolls the window to the right.<br />
<br />
=== Firefox 3 ===<br />
<br />
OR (tested on Microsoft Wireless Intellimouse explorer 2.0)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines -1<br />
mousewheel.horizscroll.withnokey.sysnumlines false<br />
<br />
{{Note | If you use the true value for numlines, your left/right will be inverted.}}<br />
<br />
<br />
==== Thumb Buttons - forward and back ====<br />
<br />
{{Note | The following maybe redundant depending on whether xev detects all your mouse buttons correctly (functions can be mapped on a per-app basis) or you want to change the default behaviour.}}<br />
<br />
To do this we need to map keystrokes to the desired mouse buttons and install {{Pkg|xvkbd}} and {{Pkg|xbindkeys}}.<br />
<br />
In most modern applications which use back/forward features, XF86Back is mapped to back and XF86Forward is mapped to forward by default. On most MX mice the thumb buttons resolve to 8 & 9. If your mouse is different, check button numbers using xev and replace the numbers used in the example (b:8 & b:9).<br />
<br />
So if you have an MX mouse you would create the file ~/.xbindkeysrc, containing:<br />
<br />
# Mouse Buttons<br />
"xvkbd -xsendevent -text "\[XF86Back]""<br />
m:0x0 + b:8 <br />
"xvkbd -xsendevent -text "\[XF86Forward]""<br />
m:0x0 + b:9<br />
<br />
Now to test... Run the following command and if it works as expected remember to add xbindkeys to {{ic|.xinitrc}} or somewhere where it will be executed each time X starts. Also, this should work with Epiphany and Konqueror without any additional configuration or use of [[Imwheel]].<br />
xbindkeys<br />
<br />
The above info and more help may be found in the [[MX1000_Buttons]] wiki.<br />
<br />
=== xmodmap tweaking ===<br />
<br />
{{Note | None of the below is necessary with evdev, but it's here for non-evdev users. Unless something doesn't work on your mouse, ignore this whole section!}}<br />
<br />
If you use .xinitrc to load X, then add this to {{ic|.xinitrc}} (change for the number of buttons you have):<br />
xmodmap -e "pointer = 1 2 3 6 7 8 9 10 11 12 4 5" &<br />
<br />
Note that buttons 4 and 5 '''must go on the end''' or else your scroll wheel won't work.<br />
<br />
If you use GDM/XDM/KDM instead of .xinitrc, then create the file {{ic|~/.Xmodmap}} and add this to it (change for the number of buttons you have):<br />
pointer = 1 2 3 6 7 8 9 10 11 12 4 5<br />
<br />
* GDM/XDM/KDM read the {{ic|~/.Xmodmap}} file if it's present, whereas {{Ic|startx}} does not. Another solution would be to add this to your ~/.xinitrc: {{Ic|xmodmap -e $(cat ~/.Xmodmap)}}. This would allow you to use *DM and {{Ic|startx}} while only having to edit {{ic|~/.Xmodmap}} when you need to make changes.<br />
<br />
You may have to play with these numbers a bit to get your desired behavior. Some mice use buttons 6 and 7 for the scroll wheel, in which case those buttons would have to be the last numbers. Keep playing with it until it works!<br />
<br />
You can also check to see which buttons are being read with a program called 'xev', which is part of XOrg. When xev is run, it will show a box on your desktop that you can put the cursor into and click buttons to find out what buttons have been mapped.<br />
<br />
== Alternate methods ==<br />
<br />
The following methods use standard X.org mouse input driver (xf86-input-mouse) instead of using the evdev driver. It works on mice up to 7 buttons. Edit {{ic|/etc/X11/xorg.conf}} InputDevice section for your mouse to reflect the changes shown below. Then restart X and you're done.<br />
<br />
=== Method 1 - IMPS/2 ===<br />
<br />
This has been tested on an IntelliMouse Explorer 3.0. Your mileage may vary, as this does not seem to work for all said mice.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
<br />
=== Method 2 - ExplorerPS/2 ===<br />
<br />
This has been tested on a Logitech MX400 and MX518 and should work on any mx series mouse with up to 7 buttons. <br />
<br />
Driver "mouse"<br />
Option "Protocol" "ExplorerPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
Settings from above also works for Microsoft InteliMouse Explorer 3.0 that connects through USB.<br />
<br />
=== Method 3 - Auto ===<br />
<br />
This has been tested on a Logitech MX400 and should work on most mice with up to 7 buttons.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
This has been tested to work with Logitech MX1000.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "12"<br />
Option "ZAxisMapping" "4 5 7 6 8 9"<br />
<br />
=== Method 4 - btnx ===<br />
<br />
{{Deletion|Though very convenient, btnx is no longer available. Its developper states "btnx might not work as intended on some distros anymore" and it is advised to use {{Pkg|easystroke}} instead.}}<br />
[http://www.ollisalonen.com/btnx/ btnx: Button Extension &ndash; a GNU/GPL mouse tool for GNU/Linux]<br />
<br />
This allows the use of all buttons on the Logitech MX Revolution and reportedly other multi-button mice as well. Provides greater control & configuration than the evdev driver.<br />
<br />
btnx is a daemon, as such it needs to be configured as root, and its actions are available to all users.<br />
<br />
Install via AUR: {{AUR|btnx-config}} then {{AUR|btnx}}. Be sure the {{ic|xorg.conf}} "Device" is at the default {{ic|/dev/input/mice}} rather than {{ic|evdev}}.<br />
<br />
Then configure your buttons by running btnx-config as root:<br />
btnx-config<br />
Save your configuration and start btnx daemon (as root):<br />
rc.d start btnx<br />
You're likely to want this daemon to be started during boot, so add it to the DAEMONS array of you're /etc/rc.conf<br />
DAEMONS=(.... @btnx ....)<br />
<br />
=== Method 5 - easystroke ===<br />
<br />
[http://sourceforge.net/projects/easystroke/ easystroke is a gesture-recognition application for X11]<br />
<br />
easystroke is a mouse gesture application, but it can be used to manage mouse buttons as well. It's main advantage o-ver btnx is that it's more versatile. On the other hand, it's user-based, so any user has to configure it to reflect his own needs. <br />
<br />
In order to set up easystroke to manage your extra mouse buttons, you'll need to do this (example features Back/Forward mouse buttons) :<br />
run:<br />
easystroke -g<br />
Go to Preferences tab > Additional buttons > Add, and add any special button.<br />
{{Note|In case of easystroke doesn't automatically detect mouse buttons, you can specify it manually. Button identifiers (numbers) can be viewed by xev.}}<br />
<br />
Go to ''Action tab > Add action'', give the new action a name, as Type choose "Key", as Details set "Alt+Left" for Back button, "Alt+Right" for Forward button, as Stroke click the proper mouse button (confirm if a warning is displayed), and voilà! Your mouse button is configured.<br />
<br />
{{Note|Since Firefox 3, buttons 6 + 7 are no longer mapped to back and forward as in Firefox 2. Therefore, if using the above methods in Xorg, refer further to corrective methods below if necessary.}}<br />
<br />
=== Firefox 3 button 6 + 7 correction ===<br />
<br />
For MX518, try changing the above ButtonMapping Option to:<br />
Option "ButtonMapping" "1 2 3 8 9" <br />
And restart X. (Successfully tested on MX518)<br />
<br />
Another method:<br />
<br />
Leave back/forward mapped to 6+7 in xorg. In Firefox 3 about:config change the following keys:<br />
<br />
mousewheel.horizscroll.withnokey.action = 2<br />
mousewheel.horizscroll.withnokey.numlines = -1<br />
mousewheel.horizscroll.withnokey.sysnumlines = false<br />
<br />
== Binding keyboard to mouse buttons ==<br />
<br />
=== xvkbd and xbindkeys ===<br />
<br />
Let's say we want to bind some mouse buttons to keyboard ones. The problem we will encounter is that we do not know how to emulate a key press. Here comes in handy {{Pkg|xvkbd}}. We can use it along with {{Pkg|xbindkeys}}. <br />
<br />
$ xbindkeys --defaults >> ~/.xbindkeysrc<br />
$ xbindkeys<br />
<br />
To restart xbindkeys type:<br />
<br />
$ pkill -f xbindkeys<br />
$ xbindkeys <br />
<br />
Here's example {{Ic|~/.xbindkeysrc}} config:<br />
<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:8<br />
"xvkbd -text "\[Shift]\[Left]""<br />
m:0x0 + b:9<br />
"xvkbd -text "\[Shift]\[Right]""<br />
m:0x0 + b:10<br />
"xvkbd -text 2"<br />
m:0x0 + b:11<br />
"xvkbd -text 3"<br />
m:0x0 + b:12<br />
<br />
If you want to check your mouse buttons number use xev. Don't forget to type capital letters in xvkbd -text usage and to escape opening bracket with \ or you get simply [Shift] written.<br />
<br />
Here is an example for xbindkeys to enable x selection paste(third click pasting), you need both xsel and xvkbd installed, What it does it executes that command whenever button 13 of the mouse is pressed (in ~/.xbindkeysrc) :<br />
<br />
"xvkbd -no-jump-pointer -text "\D1$(xsel)" 2>/dev/null"<br />
b:13<br />
<br />
=== Why standard methods are not enough? ===<br />
<br />
This will work great for X servers, but it seems not to work in some specific situations, like in Enemy Territory game. So I will describe a bit more advanced configuration, which work with my logitech G5 buttons - I can use all my 5 additional buttons along with 3 standard and a scroll, which gives overall 10 events to use in Enemy Territory. So here we go:<br />
<br />
{{Note | '''Update:''' evrouter can now simulate X11 key events so it is now possible to skip [[Get_All_Mouse_Buttons_Working#kbde|kbde]] and only use [[Get_All_Mouse_Buttons_Working#evrouter|evrouter]] to bind keyboard buttons to your mouse. }}<br />
<br />
=== kbde ===<br />
<br />
To emulate keystroke which will be later detected in Enemy Territory we need something more advanced than xvkbd. Here comes in handy kbde, but it doesn't exist in the AUR yet &ndash; we've got to compile it by ourselves. We need two programs: kbde and kbde-driver. Kbde website is located on sourceforge [http://kbde.sourceforge.net/], check it for download, you need only kbde-driver. Apparently, it doesn't work for me without some hacking. Use your editor and add <br />
<br />
#include <linux/version.h><br />
<br />
somewhere near other includes in the driver/kbde.c file. (OK, I'm not sure whether it is a proper way to compile it, but it works).<br />
Assuming that you've already done that try:<br />
<br />
tar -zxvf kbde-driver-1*<br />
cd kbde-driver-1*<br />
make<br />
# if you do not have sudo just use su and type this as root<br />
sudo make install mknod<br />
modprobe kbde<br />
<br />
and now you should have kbde working. If you want to use it as a non-root (yes, you want) change permissions, the quickest and dirtiest way is (note that I added my startup scripts at the end of this text):<br />
<br />
chgrp users /dev/kbde<br />
chmod 220 /dev/kbde<br />
<br />
If not try reading installation instructions on the site. Now we can use it to emulate keystrokes visible even in login shells:<br />
<br />
kbde --press 5 --release 5 -b<br />
<br />
this will press 5 for about three times. If you want to type a string using this, rather than this use --asci=STRING, as press sometimes generates 3 strokes before it is released.<br />
<br />
=== evrouter ===<br />
<br />
Now we need something which will work when Enemy Territory is loaded. Apparently, xbindkeys does not work here, so we need another program: evrouter [http://www.bedroomlan.org/~alexios/coding_evrouter.html], which can be found in the AUR: {{AUR|evrouter}}<br />
<br />
OK, so now we must have evdev and we can NOT use it in X, so here is how my example {{ic|/etc/X11/xorg.conf}} mouse section looks like:<br />
<br />
Section "InputDevice"<br />
<br />
Identifier "Logitech G5"<br />
<br />
Driver "mouse"<br />
Option "Protocol" "Auto"<br />
Option "Device" "/dev/input/mouse1" # probably you'll need here mouse0<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "Buttons" "8" # set this to your number of buttons<br />
Option "ZAxisMapping" "4 5"<br />
<br />
EndSection<br />
<br />
and now we have to restart the X server. <br />
You will run this as user, and event devices are owned by root, so you got to change the permissions at this point. Let us say we do it just like that, but I advise you to do this more carefully (note that I added my start-up scripts at the end of this text):<br />
<br />
chgrp users /dev/input/event*<br />
chmod 660 /dev/input/event*<br />
<br />
Now we can use the {{ic|--dump}} option to check what we will have to bind and to which device:<br />
<br />
evrouter --dump /dev/input/event*<br />
# here click buttons you would like to bind<br />
<br />
It will give you output similar to config. Here is my example config {{ic|~/.evrouterrc}} with kbde usage:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "SHELL/kbde --press 2 --release 2 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/279 "SHELL/kbde --press 3 --release 3 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/274 "SHELL/kbde --press 4 --release 4 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/277 "SHELL/kbde --press 5 --release 5 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/276 "SHELL/kbde --press 6 --release 6 -b"<br />
<br />
Same config using evrouters built in X11 key event emulator instead of kbde:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/2"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/3"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/4"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/5"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/6"<br />
<br />
This works great, even in Enemy Territory. The "none" modifier means that I have to only press the button, other options are {{ic|Ctrl+Alt}} and so on. Here I use "any" because "none" means that after pressing {{ic|Shift}}, {{ic|Ctrl}}, or {{ic|Alt}}, our buttons would not work. Also note that it accepts regular expressions for mouse name and event path. Then, after setting up a config, run service with:<br />
<br />
evrouter /dev/input/event* >> /dev/null<br />
<br />
or change the {{Ic|event*}} to a device corresponding to your mouse -- but be aware that the numbers are changing sometimes. It will work in background, while outputting some annoying messages, so we stream it to {{ic|/dev/null}}. If something went wrong, run it without streaming and check what it outputs. If you want to end it, you have to delete {{ic|/tmp/evrouter.*}} manually. Here is a script to kill evrouter:<br />
<br />
#!/bin/bash<br />
evrouter -q<br />
rm -f /tmp/.evrouter*<br />
<br />
and here is one to start it:<br />
<br />
#!/bin/bash<br />
mydevicename="Logitech USB Gaming Mouse"<br />
<br />
device=$(evrouter -D /dev/input/event* | grep "$mydevicename") | cut -d ":" -f 2<br />
evrouter $device > /dev/null<br />
<br />
You have to edit the {{Ic|mydevicename}} variable to its proper value (the one which is shown by {{Ic|evrouter -D}}), or just change it to listen on all events by changing device var to {{Ic|/dev/input/event*}}. OK, I have saved them in {{ic|/usr/bin/}}. Now, everything should be ready for use!<br />
<br />
=== Binding + and - in Logitech G5 mouse ===<br />
<br />
If you want to bind the buttons {{ic|+}} and {{ic|-}} in G5/7 mouse, which normally changes DPI, you have to use {{Ic|g5hack}} [http://piie.net/temp/g5_hiddev.c] released by a lomoco author.<br />
<br />
<nowiki>wget http://piie.net/temp/g5_hiddev.c</nowiki><br />
gcc -o g5hack g5_hiddev.c<br />
./g5hack /dev/usb/hiddev0 3<br />
<br />
This will change your DPI to 2000, light the 1st LED and disables DPI on-the-fly changing, so you can use it with evrouter. If you would use it frequently I suggest you to copy it to the {{ic|/usr/bin}} directory:<br />
<br />
# cp g5hack /usr/bin/<br />
<br />
If you want to bind your {{ic|+}} and {{ic|-}} buttons you must copy the line at the bottom (one with the comment '"-" button does not function anymore' above) to the mode you will be using, like, for example, under the "case 3:" you can put it on the line with the comment 'turn on third led' above (deleting the old one before of course).<br />
<br />
For the newest G5 mouse which is reported as "product 0xc049" original hack does not work. You have to simply change the {{ic|#define MOUSE_G5 0xc041}} to {{ic|#define MOUSE_G5 0xc049}} and recompile.<br />
<br />
=== startup scripts ===<br />
<br />
Currently, I am using a startup script with a few dirty methods, so if somebody can propose better, please edit. I have created an input group and made my user a member of it.<br />
<br />
{{ic|/etc/rc.local}}:<br />
<br />
#!/bin/bash<br />
# creating /dev/kbde nod and changing permissions<br />
# also do not forget to add kbde in modules line in /etc/rc.conf<br />
# to be honest, I'm not sure why we have to create /dev/kbde after each startup, but it seems that only this way it works<br />
# maybe first check if it's needed for you, too<br />
mknod --mode=220 /dev/kbde c 11 0 <br />
chgrp input /dev/kbde<br />
# changing permissions for event* -- evrouter needs that<br />
chmod 660 /dev/input/event*<br />
chgrp input /dev/input/event*<br />
# g5hack ran for a few times to make sure that it'll work...<br />
# note that I've add it to /usr/bin, you should probably put your full path here<br />
# you probably should skip this lines, especially if you do not have a Logitech g5/g3/g7<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
<br />
{{ic|~/.kde/Autostart/init}}:<br />
<br />
#!/bin/bash<br />
# there I use my script to start evrouter, which I have presented above<br />
evrouter-start<br />
# here I map my buttons so I can use G5 thumb button as push to talk in TS<br />
# note that I have to use it as middle button also on KDE<br />
# you probably do not need it<br />
xmodmap -e "pointer = 1 9 3 4 5 6 7 2 8 10 11 12"<br />
<br />
And voila, we've got it working immediately after KDE login.<br />
<br />
== User tools ==<br />
<br />
{{AUR|imwheel}} provides configurable mouse wheel and button mapping. It can be configured globally or for individual processes.<br />
<br />
Sample {{ic|~/.imwheelrc}} to enable back/forward thumb buttons for all applications and increased scroll speed in Chromium:<br />
"^chromium$"<br />
None, Up, Button4, 3<br />
None, Down, Button5, 3<br/><br />
".*"<br />
None, Thumb1, Alt_L|Left<br />
None, Thumb2, Alt_L|Right<br />
<br />
{{Pkg|lomoco}} for Logitech MX mice will help you set the proper resolution, enable or disable smart scroll (with boot time support too!), etc. lomoco is available from the {{Ic|[community]}} repository and can be installed with the following command:<br />
<br />
Be sure to look at {{ic|/etc/udev/lomoco_mouse.conf}} and set up the the options you want to be automatically applied when the mouse gets loaded by [[udev]].<br />
{{Note|The lomoco package may be out of date. There is a hack for newer Logitech mice: [http://piie.net/temp/g5_hiddev.c]}}<br />
<br />
==Device Specific Configuration Files==<br />
<br />
=== Mad Catz M.M.O.7 Mouse===<br />
<br />
[[Mad_Catz_Mouse]]<br />
<br />
== See also ==<br />
<br />
* http://www.gentoo-wiki.info/HOWTO_Advanced_Mouse<br />
For similar setup, specially for Logitech MX, see:<br />
* http://lotphelp.com/lotp/lotp-guide-logitech-mx-mouse-ubuntu</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361817Mad Catz Mouse2015-02-19T10:52:19Z<p>Physicist1616: /* Manually ButtonMapping Fix */ Title adjustment</p>
<hr />
<div>[[Category:Mice]]<br />
Mad Catz produces a series of gaming mice, for example the Saitek Cyborg R.A.T.3 Mouse (7 buttons USB wired) or the R.A.T9 (7 buttons USB wireless). The mice do not work properly in X without some reconfiguration. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
* Closing certain windows restores functionality until the mouse locks into a new window.<br />
<br />
<br />
==The Disable Button Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
== RAT7 or RAT9 Full Fix==<br />
This is the configuration file that will get your R.A.T. 7 or R.A.T. 9 mouse working properly under linux.<br />
<br />
{{ic|/etc/X11/xorg.conf.d/910-rat.conf}}:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz M.M.O.7 Mouse"<br />
MatchIsPointer "true"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Buttons" "24"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"<br />
Option "AutoReleaseButtons" "13 14 15"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
You can define different keystrokes applied to each mouse button by defining them in {{ic|~/.xbindkeysrc}} eg.:<br />
<br />
# pressing mouse button 7 sends keystroke: 2<br />
"xvkbd -text 2"<br />
m:0x0 + b:7<br />
# pressing mouse button 8 sends keystroke: Space<br />
"xvkbd -text "\[SPACE]""<br />
m:0x0 + b:8<br />
# pressing mouse button 9 sends keystroke: F8<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:9<br />
# pressing mouse button 10 sends keystroke: CursorLeft<br />
"xvkbd -text "\[Left]""<br />
m:0x0 + b:10<br />
# pressing mouse button 11 sends keystroke: Shift+F2<br />
"xvkbd -text "\[Shift]\[F2]""<br />
m:0x0 + b:11<br />
<br />
A very good article on setting up the Mad Catz M.M.O.7 mouse with Linux is written [https://delightlylinux.wordpress.com/2013/07/29/using-the-mad-catz-m-m-o-7-with-linux-mint-and-ubuntu/ here].<br />
<br />
<br />
<br />
==Manual Button Mapping Fix==<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361816Mad Catz Mouse2015-02-19T10:51:46Z<p>Physicist1616: Added a full-featured fix from the All_Mouse_buttons_Working page for RAT 7 and 9.</p>
<hr />
<div>[[Category:Mice]]<br />
Mad Catz produces a series of gaming mice, for example the Saitek Cyborg R.A.T.3 Mouse (7 buttons USB wired) or the R.A.T9 (7 buttons USB wireless). The mice do not work properly in X without some reconfiguration. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
* Closing certain windows restores functionality until the mouse locks into a new window.<br />
<br />
<br />
==The Disable Button Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
== RAT7 or RAT9 Full Fix==<br />
This is the configuration file that will get your R.A.T. 7 or R.A.T. 9 mouse working properly under linux.<br />
<br />
{{ic|/etc/X11/xorg.conf.d/910-rat.conf}}:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz M.M.O.7 Mouse"<br />
MatchIsPointer "true"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Buttons" "24"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24"<br />
Option "AutoReleaseButtons" "13 14 15"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
You can define different keystrokes applied to each mouse button by defining them in {{ic|~/.xbindkeysrc}} eg.:<br />
<br />
# pressing mouse button 7 sends keystroke: 2<br />
"xvkbd -text 2"<br />
m:0x0 + b:7<br />
# pressing mouse button 8 sends keystroke: Space<br />
"xvkbd -text "\[SPACE]""<br />
m:0x0 + b:8<br />
# pressing mouse button 9 sends keystroke: F8<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:9<br />
# pressing mouse button 10 sends keystroke: CursorLeft<br />
"xvkbd -text "\[Left]""<br />
m:0x0 + b:10<br />
# pressing mouse button 11 sends keystroke: Shift+F2<br />
"xvkbd -text "\[Shift]\[F2]""<br />
m:0x0 + b:11<br />
<br />
A very good article on setting up the Mad Catz M.M.O.7 mouse with Linux is written [https://delightlylinux.wordpress.com/2013/07/29/using-the-mad-catz-m-m-o-7-with-linux-mint-and-ubuntu/ here].<br />
<br />
<br />
<br />
==Manually ButtonMapping Fix==<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mouse_buttons&diff=361815Mouse buttons2015-02-19T10:49:04Z<p>Physicist1616: Moving the meat of the Mad Catz specific information to the existing page full of fixes. Left a link to the new home.</p>
<hr />
<div>[[ru:Get All Mouse Buttons Working]]<br />
[[zh-TW:Get All Mouse Buttons Working]]<br />
[[Category:Mice]]<br />
[[Category:X Server]]<br />
{{out of date|rc.conf refs, style still to fix, unclear sections}}<br />
This article is for users that have a mouse with more than 7 mouse buttons and want to be able to use all of them. Logitech makes several of these (if you have a [http://www.logitech.com/index.cfm/mice_pointers/trackballs/devices/156&cl=us,en Logitech Marble&reg; Mouse] you can also look at [[Logitech_Marble_Mouse|this page]]), and Microsoft makes a few as well.<br />
<br />
== Prerequisites ==<br />
<br />
{{Note|These are helper comments, and can be ignored if you are looking for nothing but raw information. Due to community feedback, I decided to add a bit more commenting that describes what's going on "behind the scenes" with this configuration.}}<br />
<br />
We will be using the {{ic|evdev}} driver for Xorg. EVentDEVice is an advanced driver for USB input devices which offers much greater power over the standard Xorg {{ic|mouse}} driver. It is also more "direct" than the {{ic|mouse}} driver, allowing lower latency and less translation issues.<br />
<br />
*Note that {{Ic|evdev}} is both a kernel module and an Xorg input driver. All the Arch kernels come with the {{Ic|evdev}} module.<br />
<br />
With the newer Xorg 11R7.0 it seems only the following changes to {{ic|/etc/X11/xorg.conf}} need to be made with nothing else needing to be done.<br />
<br />
== Finding the mouse name ==<br />
<br />
{{Note|To get accurate information it is sometimes required to execute this command from a boot where no Xorg or mouse drivers have been loaded.}}<br />
<br />
The first step is to find the name of the mouse. To do this, execute the following command:<br />
$ egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
This should output something like this:<br />
N: Name="Logitech USB Gaming Mouse"<br />
H: Handlers=mouse0 event0 ts0 <br />
N: Name="HID 0566:3002"<br />
H: Handlers=kbd event1 <br />
<br />
The mouse is the one that has the {{Ic|<nowiki>Handlers=mouse0</nowiki>}}, so the name of the device is {{ic|Logitech USB Gaming Mouse}}.<br />
<br />
{{Note|My mouse is a Logitech G5; your mouse is probably different, and therefore the {{Ic|Name}} will be different.}}<br />
<br />
Copy the name of the device, and open up {{ic|/etc/X11/xorg.conf}}.<br />
<br />
== Configuring Xorg ==<br />
<br />
Now, we need an entry in {{ic|xorg.conf}} that tells X how to use this mouse. It should look something like this:<br />
<br />
Section "InputDevice"<br />
Identifier "Evdev Mouse"<br />
Driver "evdev"<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "evBits" "+1-2"<br />
Option "keyBits" "~272-287"<br />
Option "relBits" "~0-2 ~6 ~8"<br />
Option "Pass" "3"<br />
Option "CorePointer"<br />
EndSection<br />
<br />
Replace the {{Ic|Name}} option with the name you copied from above. You may also omit the {{ic|CorePointer}} option if you use multiple mice or experience errors when attempting to load Xorg. The other options are all basic mouse configurations for evdev and should work with most mice.<br />
<br />
Next, we need to tell X to use the mouse, so look in {{ic|xorg.conf}} for {{Ic|ServerLayout}}.<br />
<br />
Modify the {{ic|ServerLayout}} section to use "Evdev Mouse" as the device. When you are done, it should look something like this:<br />
<br />
Section "ServerLayout"<br />
Identifier "Default Layout"<br />
Screen 0 "Monitor0" 0 0<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
InputDevice "Evdev Mouse" "CorePointer"<br />
EndSection<br />
<br />
The only thing you should change in the layout is the {{ic|InputDevice}} line that refers to your mouse.<br />
<br />
That should be all that is required.<br />
<br />
* Edit by: xxsashixx <br />
This is for Logitech G5 Mouse users. I have not tested this for other mice, but if you do not add this, your mouse ''MAY'' not work.<br />
If you do not need to add this, then don't.<br />
<br />
Put <br />
Option "Device" "/dev/input/event[#]"<br />
in the {{Ic|InputDevice}} section or else the mouse will not be picked up.<br />
<br />
[#] = The number you got from:<br />
egrep "Name|Handlers" /proc/bus/input/devices<br />
<br />
* Edit by: bapman<br />
With the above method, your mouse might not to work after reboot (event number changes). To fix this, you can use symlinks in {{ic|/dev/input/by-id}}. For example:<br />
Option "Device" "/dev/input/by-id/usb-Logitech_USB_Receiver-event-mouse"<br />
To find the appropriate id, do:<br />
ls /dev/input/by-id/<br />
<br />
* Edit by: Diamir<br />
{{Out of date|The udev rule will not work, the {{ic|1=SYSFS=}} and {{ic|1=BUS=}} keys have been removed [https://mailman.archlinux.org/pipermail/arch-dev-public/2011-October/021795.html].}}<br />
With a Desktop type keyboard-mouse, this does not work because there is only one USB attachment and {{ic|/dev/input/by-id}} contains only the keyboard.<br />
In this case, we can create a udev rule to get a consistent link.<br />
The following rules create the link {{ic|/dev/input/usbmouse}} which points on the correct event entry:<br />
KERNEL=="event[0-9]*", BUS=="usb", SYSFS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00", SYMLINK+="input/usbmouse"<br />
<br />
You can call it {{ic|z10_usb_mouse.rules}} and put it in {{ic|/etc/udev/rules.d}}<br />
<br />
The cryptic value to use for {{ic|SYSFS(modalias)}} can be get the following way:<br />
<br />
enter the command {{ic|cat /proc/bus/input/devices}}<br />
<br />
You will find the keyboard and the mouse and see event4 is the mouse in this case: <br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input0<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.0/input/input3<br />
U: Uniq=<br />
H: Handlers=kbd event0 <br />
B: EV=120013<br />
B: KEY=1000000000007 ff800000000007ff febeffdff3cfffff fffffffffffffffe<br />
B: MSC=10<br />
B: LED=107<br />
<br />
I: Bus=0003 Vendor=045e Product=008a Version=0111<br />
N: Name="Microsoft Microsoft Wireless Optical Desktop� 1.00"<br />
P: Phys=usb-0000:00:10.0-2/input1<br />
S: Sysfs=/devices/pci0000:00/0000:00:10.0/usb1/1-2/1-2:1.1/input/input4<br />
U: Uniq=<br />
H: Handlers=kbd mouse0 event1 <br />
B: EV=17<br />
B: KEY=3000000000000 0 1f0000 f8400244000 601878d800d448 1e000000000000 0<br />
B: REL=7c3<br />
B: MSC=10<br />
<br />
So I enter the following command (adapt event # to your particular case):<br />
{{bc|1=udevinfo -a -p $(udevinfo -q path -n /dev/input/event4) &#124; grep modalias<br />
ATTRS{modalias}=="input:b0003v045Ep008Ae0111-0,1,2,4,k71,72,73,74,83,86,8A,8C,8E,8F,9B,9C,9E,9F,A3,A4,A5,A6,AB,AC,B5,B6,CE,D2,D5,E2,E7,E8,E9,EA,EB,110,111,112,113,114,1B0,1B1,r0,1,6,7,8,9,A,am4,lsfw"<br />
ATTRS{modalias}=="usb:v045Ep008Ad7373dc00dsc00dp00ic03isc00ip00"<br />
ATTRS{modalias}=="pci:v00001106d00003038sv00001043sd000080EDbc0Csc03i00"}}<br />
<br />
grab the ATTRS which becomes with usb: to complete "SYSFS{modalias}== " entry<br />
<br />
And finally, use {{ic|usbmouse}} as the Device Option in {{ic|xorg.conf}}:<br />
Option "Device" "/dev/input/usbmouse"<br />
<br />
== Post Configuration ==<br />
<br />
=== Google Chrome ===<br />
<br />
It works. Horizontal scroll works out of the box - push the scroll wheel left or right. Thumb buttons also work as next/previous page.<br />
<br />
=== Opera ===<br />
<br />
It works. Note: buttons can be mapped to functions easily in {{Ic|Preferences > Advanced > Shortcuts > Mouse set-up}}. For example, to bind ''button 8'' to ''back'':<br />
<br />
# Navigate to mouse set-up and expand the ''Application'' drop-down<br />
# In the input column, type: ''Button 8''<br />
# In the actions column, type: ''Back''<br />
<br />
=== Firefox ===<br />
<br />
==== Horizontal scroll ====<br />
<br />
<br />
=====Firefox 20 and Newer=====<br />
(Tested in version 32)<br />
To get back and forward enabled, instead of scroll left/right, change the following settings in {{ic|about:config}}:<br />
<br />
mousewheel.default.action.override_x 2<br />
mousewheel.default.delta_multiplier_x -100<br />
<br />
=====Older Versions=====<br />
<br />
By default, left right scroll on a FX/MX mouse translates into back/forward, respectively. If you do not like this, open {{ic|about:config}} and change a few values:<br />
<br />
mousewheel.horizscroll.withnokey.action 0<br />
mousewheel.horizscroll.withnokey.numlines -3<br />
<br />
OR (tested on Logitech G5)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines 2<br />
<br />
NOTE: If you use a positive value for numlines, your left/right will switch, ie: pressing left scrolls the window to the right.<br />
<br />
=== Firefox 3 ===<br />
<br />
OR (tested on Microsoft Wireless Intellimouse explorer 2.0)<br />
<br />
mousewheel.horizscroll.withnokey.action 2<br />
mousewheel.horizscroll.withnokey.numlines -1<br />
mousewheel.horizscroll.withnokey.sysnumlines false<br />
<br />
{{Note | If you use the true value for numlines, your left/right will be inverted.}}<br />
<br />
<br />
==== Thumb Buttons - forward and back ====<br />
<br />
{{Note | The following maybe redundant depending on whether xev detects all your mouse buttons correctly (functions can be mapped on a per-app basis) or you want to change the default behaviour.}}<br />
<br />
To do this we need to map keystrokes to the desired mouse buttons and install {{Pkg|xvkbd}} and {{Pkg|xbindkeys}}.<br />
<br />
In most modern applications which use back/forward features, XF86Back is mapped to back and XF86Forward is mapped to forward by default. On most MX mice the thumb buttons resolve to 8 & 9. If your mouse is different, check button numbers using xev and replace the numbers used in the example (b:8 & b:9).<br />
<br />
So if you have an MX mouse you would create the file ~/.xbindkeysrc, containing:<br />
<br />
# Mouse Buttons<br />
"xvkbd -xsendevent -text "\[XF86Back]""<br />
m:0x0 + b:8 <br />
"xvkbd -xsendevent -text "\[XF86Forward]""<br />
m:0x0 + b:9<br />
<br />
Now to test... Run the following command and if it works as expected remember to add xbindkeys to {{ic|.xinitrc}} or somewhere where it will be executed each time X starts. Also, this should work with Epiphany and Konqueror without any additional configuration or use of [[Imwheel]].<br />
xbindkeys<br />
<br />
The above info and more help may be found in the [[MX1000_Buttons]] wiki.<br />
<br />
=== xmodmap tweaking ===<br />
<br />
{{Note | None of the below is necessary with evdev, but it's here for non-evdev users. Unless something doesn't work on your mouse, ignore this whole section!}}<br />
<br />
If you use .xinitrc to load X, then add this to {{ic|.xinitrc}} (change for the number of buttons you have):<br />
xmodmap -e "pointer = 1 2 3 6 7 8 9 10 11 12 4 5" &<br />
<br />
Note that buttons 4 and 5 '''must go on the end''' or else your scroll wheel won't work.<br />
<br />
If you use GDM/XDM/KDM instead of .xinitrc, then create the file {{ic|~/.Xmodmap}} and add this to it (change for the number of buttons you have):<br />
pointer = 1 2 3 6 7 8 9 10 11 12 4 5<br />
<br />
* GDM/XDM/KDM read the {{ic|~/.Xmodmap}} file if it's present, whereas {{Ic|startx}} does not. Another solution would be to add this to your ~/.xinitrc: {{Ic|xmodmap -e $(cat ~/.Xmodmap)}}. This would allow you to use *DM and {{Ic|startx}} while only having to edit {{ic|~/.Xmodmap}} when you need to make changes.<br />
<br />
You may have to play with these numbers a bit to get your desired behavior. Some mice use buttons 6 and 7 for the scroll wheel, in which case those buttons would have to be the last numbers. Keep playing with it until it works!<br />
<br />
You can also check to see which buttons are being read with a program called 'xev', which is part of XOrg. When xev is run, it will show a box on your desktop that you can put the cursor into and click buttons to find out what buttons have been mapped.<br />
<br />
== Alternate methods ==<br />
<br />
The following methods use standard X.org mouse input driver (xf86-input-mouse) instead of using the evdev driver. It works on mice up to 7 buttons. Edit {{ic|/etc/X11/xorg.conf}} InputDevice section for your mouse to reflect the changes shown below. Then restart X and you're done.<br />
<br />
=== Method 1 - IMPS/2 ===<br />
<br />
This has been tested on an IntelliMouse Explorer 3.0. Your mileage may vary, as this does not seem to work for all said mice.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "IMPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
<br />
=== Method 2 - ExplorerPS/2 ===<br />
<br />
This has been tested on a Logitech MX400 and MX518 and should work on any mx series mouse with up to 7 buttons. <br />
<br />
Driver "mouse"<br />
Option "Protocol" "ExplorerPS/2"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
Settings from above also works for Microsoft InteliMouse Explorer 3.0 that connects through USB.<br />
<br />
=== Method 3 - Auto ===<br />
<br />
This has been tested on a Logitech MX400 and should work on most mice with up to 7 buttons.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 6 7"<br />
<br />
This has been tested to work with Logitech MX1000.<br />
<br />
Driver "mouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "12"<br />
Option "ZAxisMapping" "4 5 7 6 8 9"<br />
<br />
=== Method 4 - btnx ===<br />
<br />
{{Deletion|Though very convenient, btnx is no longer available. Its developper states "btnx might not work as intended on some distros anymore" and it is advised to use {{Pkg|easystroke}} instead.}}<br />
[http://www.ollisalonen.com/btnx/ btnx: Button Extension &ndash; a GNU/GPL mouse tool for GNU/Linux]<br />
<br />
This allows the use of all buttons on the Logitech MX Revolution and reportedly other multi-button mice as well. Provides greater control & configuration than the evdev driver.<br />
<br />
btnx is a daemon, as such it needs to be configured as root, and its actions are available to all users.<br />
<br />
Install via AUR: {{AUR|btnx-config}} then {{AUR|btnx}}. Be sure the {{ic|xorg.conf}} "Device" is at the default {{ic|/dev/input/mice}} rather than {{ic|evdev}}.<br />
<br />
Then configure your buttons by running btnx-config as root:<br />
btnx-config<br />
Save your configuration and start btnx daemon (as root):<br />
rc.d start btnx<br />
You're likely to want this daemon to be started during boot, so add it to the DAEMONS array of you're /etc/rc.conf<br />
DAEMONS=(.... @btnx ....)<br />
<br />
=== Method 5 - easystroke ===<br />
<br />
[http://sourceforge.net/projects/easystroke/ easystroke is a gesture-recognition application for X11]<br />
<br />
easystroke is a mouse gesture application, but it can be used to manage mouse buttons as well. It's main advantage o-ver btnx is that it's more versatile. On the other hand, it's user-based, so any user has to configure it to reflect his own needs. <br />
<br />
In order to set up easystroke to manage your extra mouse buttons, you'll need to do this (example features Back/Forward mouse buttons) :<br />
run:<br />
easystroke -g<br />
Go to Preferences tab > Additional buttons > Add, and add any special button.<br />
{{Note|In case of easystroke doesn't automatically detect mouse buttons, you can specify it manually. Button identifiers (numbers) can be viewed by xev.}}<br />
<br />
Go to ''Action tab > Add action'', give the new action a name, as Type choose "Key", as Details set "Alt+Left" for Back button, "Alt+Right" for Forward button, as Stroke click the proper mouse button (confirm if a warning is displayed), and voilà! Your mouse button is configured.<br />
<br />
{{Note|Since Firefox 3, buttons 6 + 7 are no longer mapped to back and forward as in Firefox 2. Therefore, if using the above methods in Xorg, refer further to corrective methods below if necessary.}}<br />
<br />
=== Firefox 3 button 6 + 7 correction ===<br />
<br />
For MX518, try changing the above ButtonMapping Option to:<br />
Option "ButtonMapping" "1 2 3 8 9" <br />
And restart X. (Successfully tested on MX518)<br />
<br />
Another method:<br />
<br />
Leave back/forward mapped to 6+7 in xorg. In Firefox 3 about:config change the following keys:<br />
<br />
mousewheel.horizscroll.withnokey.action = 2<br />
mousewheel.horizscroll.withnokey.numlines = -1<br />
mousewheel.horizscroll.withnokey.sysnumlines = false<br />
<br />
== Binding keyboard to mouse buttons ==<br />
<br />
=== xvkbd and xbindkeys ===<br />
<br />
Let's say we want to bind some mouse buttons to keyboard ones. The problem we will encounter is that we do not know how to emulate a key press. Here comes in handy {{Pkg|xvkbd}}. We can use it along with {{Pkg|xbindkeys}}. <br />
<br />
$ xbindkeys --defaults >> ~/.xbindkeysrc<br />
$ xbindkeys<br />
<br />
To restart xbindkeys type:<br />
<br />
$ pkill -f xbindkeys<br />
$ xbindkeys <br />
<br />
Here's example {{Ic|~/.xbindkeysrc}} config:<br />
<br />
"xvkbd -text "\[F8]""<br />
m:0x0 + b:8<br />
"xvkbd -text "\[Shift]\[Left]""<br />
m:0x0 + b:9<br />
"xvkbd -text "\[Shift]\[Right]""<br />
m:0x0 + b:10<br />
"xvkbd -text 2"<br />
m:0x0 + b:11<br />
"xvkbd -text 3"<br />
m:0x0 + b:12<br />
<br />
If you want to check your mouse buttons number use xev. Don't forget to type capital letters in xvkbd -text usage and to escape opening bracket with \ or you get simply [Shift] written.<br />
<br />
Here is an example for xbindkeys to enable x selection paste(third click pasting), you need both xsel and xvkbd installed, What it does it executes that command whenever button 13 of the mouse is pressed (in ~/.xbindkeysrc) :<br />
<br />
"xvkbd -no-jump-pointer -text "\D1$(xsel)" 2>/dev/null"<br />
b:13<br />
<br />
=== Why standard methods are not enough? ===<br />
<br />
This will work great for X servers, but it seems not to work in some specific situations, like in Enemy Territory game. So I will describe a bit more advanced configuration, which work with my logitech G5 buttons - I can use all my 5 additional buttons along with 3 standard and a scroll, which gives overall 10 events to use in Enemy Territory. So here we go:<br />
<br />
{{Note | '''Update:''' evrouter can now simulate X11 key events so it is now possible to skip [[Get_All_Mouse_Buttons_Working#kbde|kbde]] and only use [[Get_All_Mouse_Buttons_Working#evrouter|evrouter]] to bind keyboard buttons to your mouse. }}<br />
<br />
=== kbde ===<br />
<br />
To emulate keystroke which will be later detected in Enemy Territory we need something more advanced than xvkbd. Here comes in handy kbde, but it doesn't exist in the AUR yet &ndash; we've got to compile it by ourselves. We need two programs: kbde and kbde-driver. Kbde website is located on sourceforge [http://kbde.sourceforge.net/], check it for download, you need only kbde-driver. Apparently, it doesn't work for me without some hacking. Use your editor and add <br />
<br />
#include <linux/version.h><br />
<br />
somewhere near other includes in the driver/kbde.c file. (OK, I'm not sure whether it is a proper way to compile it, but it works).<br />
Assuming that you've already done that try:<br />
<br />
tar -zxvf kbde-driver-1*<br />
cd kbde-driver-1*<br />
make<br />
# if you do not have sudo just use su and type this as root<br />
sudo make install mknod<br />
modprobe kbde<br />
<br />
and now you should have kbde working. If you want to use it as a non-root (yes, you want) change permissions, the quickest and dirtiest way is (note that I added my startup scripts at the end of this text):<br />
<br />
chgrp users /dev/kbde<br />
chmod 220 /dev/kbde<br />
<br />
If not try reading installation instructions on the site. Now we can use it to emulate keystrokes visible even in login shells:<br />
<br />
kbde --press 5 --release 5 -b<br />
<br />
this will press 5 for about three times. If you want to type a string using this, rather than this use --asci=STRING, as press sometimes generates 3 strokes before it is released.<br />
<br />
=== evrouter ===<br />
<br />
Now we need something which will work when Enemy Territory is loaded. Apparently, xbindkeys does not work here, so we need another program: evrouter [http://www.bedroomlan.org/~alexios/coding_evrouter.html], which can be found in the AUR: {{AUR|evrouter}}<br />
<br />
OK, so now we must have evdev and we can NOT use it in X, so here is how my example {{ic|/etc/X11/xorg.conf}} mouse section looks like:<br />
<br />
Section "InputDevice"<br />
<br />
Identifier "Logitech G5"<br />
<br />
Driver "mouse"<br />
Option "Protocol" "Auto"<br />
Option "Device" "/dev/input/mouse1" # probably you'll need here mouse0<br />
Option "Name" "Logitech USB Gaming Mouse"<br />
Option "Buttons" "8" # set this to your number of buttons<br />
Option "ZAxisMapping" "4 5"<br />
<br />
EndSection<br />
<br />
and now we have to restart the X server. <br />
You will run this as user, and event devices are owned by root, so you got to change the permissions at this point. Let us say we do it just like that, but I advise you to do this more carefully (note that I added my start-up scripts at the end of this text):<br />
<br />
chgrp users /dev/input/event*<br />
chmod 660 /dev/input/event*<br />
<br />
Now we can use the {{ic|--dump}} option to check what we will have to bind and to which device:<br />
<br />
evrouter --dump /dev/input/event*<br />
# here click buttons you would like to bind<br />
<br />
It will give you output similar to config. Here is my example config {{ic|~/.evrouterrc}} with kbde usage:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "SHELL/kbde --press 2 --release 2 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/279 "SHELL/kbde --press 3 --release 3 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/274 "SHELL/kbde --press 4 --release 4 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/277 "SHELL/kbde --press 5 --release 5 -b"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/276 "SHELL/kbde --press 6 --release 6 -b"<br />
<br />
Same config using evrouters built in X11 key event emulator instead of kbde:<br />
<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/2"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/3"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/4"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/5"<br />
"Logitech USB Gaming Mouse" "/dev/input/event.*" any key/278 "XKey/6"<br />
<br />
This works great, even in Enemy Territory. The "none" modifier means that I have to only press the button, other options are {{ic|Ctrl+Alt}} and so on. Here I use "any" because "none" means that after pressing {{ic|Shift}}, {{ic|Ctrl}}, or {{ic|Alt}}, our buttons would not work. Also note that it accepts regular expressions for mouse name and event path. Then, after setting up a config, run service with:<br />
<br />
evrouter /dev/input/event* >> /dev/null<br />
<br />
or change the {{Ic|event*}} to a device corresponding to your mouse -- but be aware that the numbers are changing sometimes. It will work in background, while outputting some annoying messages, so we stream it to {{ic|/dev/null}}. If something went wrong, run it without streaming and check what it outputs. If you want to end it, you have to delete {{ic|/tmp/evrouter.*}} manually. Here is a script to kill evrouter:<br />
<br />
#!/bin/bash<br />
evrouter -q<br />
rm -f /tmp/.evrouter*<br />
<br />
and here is one to start it:<br />
<br />
#!/bin/bash<br />
mydevicename="Logitech USB Gaming Mouse"<br />
<br />
device=$(evrouter -D /dev/input/event* | grep "$mydevicename") | cut -d ":" -f 2<br />
evrouter $device > /dev/null<br />
<br />
You have to edit the {{Ic|mydevicename}} variable to its proper value (the one which is shown by {{Ic|evrouter -D}}), or just change it to listen on all events by changing device var to {{Ic|/dev/input/event*}}. OK, I have saved them in {{ic|/usr/bin/}}. Now, everything should be ready for use!<br />
<br />
=== Binding + and - in Logitech G5 mouse ===<br />
<br />
If you want to bind the buttons {{ic|+}} and {{ic|-}} in G5/7 mouse, which normally changes DPI, you have to use {{Ic|g5hack}} [http://piie.net/temp/g5_hiddev.c] released by a lomoco author.<br />
<br />
<nowiki>wget http://piie.net/temp/g5_hiddev.c</nowiki><br />
gcc -o g5hack g5_hiddev.c<br />
./g5hack /dev/usb/hiddev0 3<br />
<br />
This will change your DPI to 2000, light the 1st LED and disables DPI on-the-fly changing, so you can use it with evrouter. If you would use it frequently I suggest you to copy it to the {{ic|/usr/bin}} directory:<br />
<br />
# cp g5hack /usr/bin/<br />
<br />
If you want to bind your {{ic|+}} and {{ic|-}} buttons you must copy the line at the bottom (one with the comment '"-" button does not function anymore' above) to the mode you will be using, like, for example, under the "case 3:" you can put it on the line with the comment 'turn on third led' above (deleting the old one before of course).<br />
<br />
For the newest G5 mouse which is reported as "product 0xc049" original hack does not work. You have to simply change the {{ic|#define MOUSE_G5 0xc041}} to {{ic|#define MOUSE_G5 0xc049}} and recompile.<br />
<br />
=== startup scripts ===<br />
<br />
Currently, I am using a startup script with a few dirty methods, so if somebody can propose better, please edit. I have created an input group and made my user a member of it.<br />
<br />
{{ic|/etc/rc.local}}:<br />
<br />
#!/bin/bash<br />
# creating /dev/kbde nod and changing permissions<br />
# also do not forget to add kbde in modules line in /etc/rc.conf<br />
# to be honest, I'm not sure why we have to create /dev/kbde after each startup, but it seems that only this way it works<br />
# maybe first check if it's needed for you, too<br />
mknod --mode=220 /dev/kbde c 11 0 <br />
chgrp input /dev/kbde<br />
# changing permissions for event* -- evrouter needs that<br />
chmod 660 /dev/input/event*<br />
chgrp input /dev/input/event*<br />
# g5hack ran for a few times to make sure that it'll work...<br />
# note that I've add it to /usr/bin, you should probably put your full path here<br />
# you probably should skip this lines, especially if you do not have a Logitech g5/g3/g7<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
g5hack /dev/usb/hiddev0 3<br />
<br />
{{ic|~/.kde/Autostart/init}}:<br />
<br />
#!/bin/bash<br />
# there I use my script to start evrouter, which I have presented above<br />
evrouter-start<br />
# here I map my buttons so I can use G5 thumb button as push to talk in TS<br />
# note that I have to use it as middle button also on KDE<br />
# you probably do not need it<br />
xmodmap -e "pointer = 1 9 3 4 5 6 7 2 8 10 11 12"<br />
<br />
And voila, we've got it working immediately after KDE login.<br />
<br />
== User tools ==<br />
<br />
{{AUR|imwheel}} provides configurable mouse wheel and button mapping. It can be configured globally or for individual processes.<br />
<br />
Sample {{ic|~/.imwheelrc}} to enable back/forward thumb buttons for all applications and increased scroll speed in Chromium:<br />
"^chromium$"<br />
None, Up, Button4, 3<br />
None, Down, Button5, 3<br/><br />
".*"<br />
None, Thumb1, Alt_L|Left<br />
None, Thumb2, Alt_L|Right<br />
<br />
{{Pkg|lomoco}} for Logitech MX mice will help you set the proper resolution, enable or disable smart scroll (with boot time support too!), etc. lomoco is available from the {{Ic|[community]}} repository and can be installed with the following command:<br />
<br />
Be sure to look at {{ic|/etc/udev/lomoco_mouse.conf}} and set up the the options you want to be automatically applied when the mouse gets loaded by [[udev]].<br />
{{Note|The lomoco package may be out of date. There is a hack for newer Logitech mice: [http://piie.net/temp/g5_hiddev.c]}}<br />
<br />
==Device Specific Configuration Files==<br />
<br />
=== Mad Catz M.M.O.7 Mouse===<br />
<br />
[Mad_Catz_Mouse]<br />
<br />
== See also ==<br />
<br />
* http://www.gentoo-wiki.info/HOWTO_Advanced_Mouse<br />
For similar setup, specially for Logitech MX, see:<br />
* http://lotphelp.com/lotp/lotp-guide-logitech-mx-mouse-ubuntu</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361814Mad Catz Mouse2015-02-19T10:43:55Z<p>Physicist1616: Made the introduction of the article more generic to Mad Catz brand mice.</p>
<hr />
<div>[[Category:Mice]]<br />
Mad Catz produces a series of gaming mice, for example the Saitek Cyborg R.A.T.3 Mouse (7 buttons USB wired) or the R.A.T9 (7 buttons USB wireless). The mice do not work properly in X without some reconfiguration. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
* Closing certain windows restores functionality until the mouse locks into a new window.<br />
<br />
<br />
==Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
<br />
<br />
<br />
<br />
'''Alternative Method (Manually ButtonMapping):'''<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616https://wiki.archlinux.org/index.php?title=Saitek_Cyborg_R.A.T.3_Mouse&diff=361809Saitek Cyborg R.A.T.3 Mouse2015-02-19T10:37:49Z<p>Physicist1616: Physicist1616 moved page Saitek Cyborg R.A.T.3 Mouse to Mad Catz Mouse: The main focus of this page is an issue that afflicts a wide variety of Mad Catz brand mice.</p>
<hr />
<div>#REDIRECT [[Mad Catz Mouse]]</div>Physicist1616https://wiki.archlinux.org/index.php?title=Mad_Catz_Mouse&diff=361808Mad Catz Mouse2015-02-19T10:37:48Z<p>Physicist1616: Physicist1616 moved page Saitek Cyborg R.A.T.3 Mouse to Mad Catz Mouse: The main focus of this page is an issue that afflicts a wide variety of Mad Catz brand mice.</p>
<hr />
<div>[[Category:Mice]]<br />
The Saitek Cyborg R.A.T.3 Mouse is a 7 buttons USB gaming mouse sold by Mad Catz. This article explains how to make it work with any desktop manager.<br />
<br />
==Installation==<br />
<br />
No driver installation is required.<br />
The mouse should be detected at boot or whenever it is hot-plugged.<br />
<br />
==Issues==<br />
<br />
After being plugged, the mouse will seems to work, but you may experience different issues :<br />
<br />
* You can't move windows around when grabbing the window's title bar. (happens with [[Openbox]] and other [[Window manager]])<br />
* You can't click on buttons.<br />
* You can't get the focus on windows.<br />
* You can't open menus, even with keyboard shortcuts.<br />
* Display doesn't refresh (using [[Xcompmgr]] or [[Cairo Compmgr]])<br />
<br />
<br />
<br />
==Solution==<br />
<br />
The issues are caused by an interaction between R.A.T Mode button and the X Server. To restore proper function, the 'Mode' button must be disabled, as follows:<br />
<br />
With root privileges, create and edit the file '''{{ic|/etc/X11/xorg.conf.d/50-vmmouse.conf}}''' (see [[xorg]]).<br />
<br />
Add the following content :<br />
<br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "evdev"<br />
Option "Name" "Saitek Cyborg R.A.T.3 Mouse"<br />
Option "Vendor" "06a3"<br />
Option "Product" "0ccc"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/event4"<br />
Option "Emulate3Buttons" "no"<br />
Option "Buttons" "7"<br />
Option "ZAxisMapping" "4 5"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 0 0 0 0 0 0 0"<br />
Option "Resolution" "3200"<br />
EndSection<br />
<br />
After restarting your X server, the mouse should be fully functional, including the two lateral buttons.<br />
If not, or if you need more informations about configuring gaming mice, see [[All Mouse Buttons Working]].<br />
<br />
<br />
<br />
<br />
<br />
'''Alternative Method (Manually ButtonMapping):'''<br />
<br />
Please note that there are two different versions of the R.A.T.3 mouse which are '''Saitek''' and '''Madcatz''', this must be input correctly into the "MatchProduct" or you will run into the same issues.<br />
<br />
First find out the ID and the Name of the mouse :<br />
<br />
xinput list | grep "id"<br />
<br />
In you should see your mouse labeled as "Madcatz Mad Catz R.A.T.3 Mouse" or "Saitek Cyborg R.A.T.3 Mouse". Note the device id number and then input the following command :<br />
<br />
xinput query-state ID<br />
<br />
(Where ID corresponds to the ID number of your mouse)<br />
<br />
Note which 'mode' color is currently active (red/blue/purple) and which button numbers correspond to the current 'mode' by being either '''"up"''' or '''"down"'''. Change the mouse 'mode' and and retype the above command, noting which buttons change state to match the 'mode'.<br />
<br />
<br />
Example:<br />
<br />
U = up<br />
D = down<br />
U U U U U D D U U D D D U U <br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
<br />
Where buttons 10, 11, and 12 have been identified as 'mode' buttons, so they can be disabled by with zeros.<br />
<br />
<br />
When you have identified which button numbers correspond to the mouse 'Modes', you should be able to edit your xorg.conf file and disable them by inserting a zero in the appropriate point in the button sequence. Open in your chosen editor:<br />
<br />
/etc/X11/xorg.conf or<br />
/etc/X11/xorg.conf.d/50-vmmouse.conf<br />
<br />
Create a block that overwrites the mode buttons as follows: <br />
<br />
MadCatz R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Madcatz Mad Catz R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 6 7 8 9 0 0 0 13 14 15 16 17 18"<br />
EndSection<br />
<br />
This configuration worked for me on my old Saitek Cyborg R.A.T.3:<br />
<br />
# RAT3 mouse<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Saitek Cyborg R.A.T.3 Mouse"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" "1 2 3 4 5 0 0 8 9 0 0 0 13 14"<br />
EndSection<br />
<br />
<br />
This works for a Mad Catz R.A.T.TE:<br />
<br />
Section "InputClass"<br />
Identifier "Mouse Remap"<br />
MatchProduct "Mad Catz Mad Catz R.A.T.TE"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "ButtonMapping" " 1 2 3 4 5 6 7 8 9 10 11 12 0 0 0"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
<br />
To work correctly, it's important to that you identify the correct "ButtonMapping" and "MatchProduct" for your specific mouse.<br />
<br />
For any any modifications to xorg.conf take effect, X must be restarted.<br />
<br />
==See also==<br />
<br />
*http://ubuntuforums.org/showthread.php?t=2126385<br />
*http://askubuntu.com/questions/92546/cyborg-r-a-t-3-gaming-mouse-stops-working-after-a-while-and-or-misbehaves</div>Physicist1616