https://wiki.archlinux.org/api.php?action=feedcontributions&user=Siddharthist&feedformat=atomArchWiki - User contributions [en]2024-03-29T00:37:55ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unclutter&diff=442148Unclutter2016-07-19T14:57:31Z<p>Siddharthist: /* Alternatives */ Added xbanish, another popular unclutter alternative</p>
<hr />
<div>[[Category:X server]]<br />
[[ja:Unclutter]]<br />
{{Style|{{AUR|unclutter-xfixes-git}} can't be described in both [[#Installation]] and [[#Alternatives]].}}<br />
<br />
Unclutter hides your X mouse cursor when you do not need it, to prevent it from getting in the way. You have only to move the mouse to restore the mouse cursor. Unclutter is very useful in tiling window managers where you do not need the mouse often.<br />
<br />
== Installation ==<br />
<br />
[[Install]] {{Pkg|unclutter}} from the [[official repositories]] or the modern rewrite {{AUR|unclutter-xfixes-git}} from the [[AUR]].<br />
<br />
== Usage ==<br />
<br />
Use your ''.xinitrc'' file or WM/DE to start unclutter. For example, add the following to your ''.xinitrc'':<br />
<br />
unclutter &<br />
<br />
== Known bugs ==<br />
<br />
=== Misbehaviour of the mouse cursor ===<br />
<br />
If you experience issues when using unclutter in conjunction with a tiling window manager (such as [[xmonad]] or [[i3]]), install {{AUR|unclutter-xfixes-git}} instead or use the {{ic|-grab}} option:<br />
<br />
unclutter -grab &<br />
<br />
{{Note|The {{ic|-grab}} option breaks some screen locking applications such as ''slock'' and ''i3lock''.}}<br />
<br />
Unclutter could cause unusual mouse behaviour in some SDL Games. The mouse cursor might be reset to some positions in the screen because of<br />
this problem. The details can be found [https://bugs.launchpad.net/ubuntu/+source/unclutter/+bug/61105 here].<br />
<br />
There are two known workarounds for this. You can either add {{ic|SDL_VIDEO_X11_DGAMOUSE&#61;0}} to your environment variables which does not work for all games or run unclutter with<br />
{{ic|-grab}} option. However, it is important to note that the grab option may cause some applications such as gksu to not work properly.<br />
<br />
== Alternatives ==<br />
<br />
=== unclutter-xfixes ===<br />
<br />
Unclutter is a tool from the early 90s and has not been updated since. It works by creating fake windows or active pointer grabs, both of which often cause problems. By now, the X11 extensions Xinput2 and Xfixes have been released and are commonly found on most user systems. Using those, {{AUR|unclutter-xfixes-git}} can provide the cursor hiding functionality without interfering with any application.<br />
<br />
=== xbanish ===<br />
<br />
xbanish is a popular rewrite of unclutter. You can grab it on the AUR as {{AUR|xbanish}} or {{AUR|xbanish-git}}.<br />
<br />
== See also ==<br />
<br />
http://linuxappfinder.com/package/unclutter - Unclutter on Linux App Finder</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Easy-RSA&diff=439355Easy-RSA2016-06-29T12:32:38Z<p>Siddharthist: remove unnecessary sourcing of vars</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
The first step when setting up [[OpenVPN]] is to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]]. The PKI consists of:<br />
<br />
* A public master [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate and a private key.<br />
* A separate public certificate and private key pair (hereafter referred to as a certificate) for each server and each client.<br />
<br />
To facilitate the certificate creation process, OpenVPN comes with a collection of [[Wikipedia:RSA (algorithm)|RSA]] key manangement scripts (based on the openssl command line tool) known as easy-rsa.<br />
<br />
{{Note| Only .key files need to be kept secret, .crt and .csr files can be sent over insecure channels such as plaintext email.}}<br />
<br />
In this article the needed certificates are created by root in root's home directory. This ensures that the generated files have the right ownership and permissions, and are safe from other users.<br />
<br />
{{Note|The certificates can be created on any machine. For the highest security, generate the certificates on a physically secure machine disconnected from any network, and make sure that the generated ca.key private key is backed up and never accessible to anyone.}}<br />
<br />
{{Warning|Make sure that the generated files are backed up, especially the ca.key and ca.crt files, since if lost you will not be able to create any new, nor revoke any compromised certificates, thus requiring the generation of a new [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate, invalidating the entire PKI infrastructure.}}<br />
<br />
===Installing the easy-rsa scripts===<br />
<br />
First, install {{pkg|easy-rsa}} package and copy files as shown:<br />
{{bc|# cp -r /usr/share/easy-rsa /root}}<br />
<br />
===Creating certificates on the server===<br />
<br />
Change to the directory where you installed the scripts.<br />
<br />
{{bc|# cd /root/easy-rsa}}<br />
<br />
To ensure the consistent use of values when generating the PKI, set default values to be used by the PKI generating scripts. Edit /root/easy-rsa/vars and at a minimum set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters (do not leave any of these parameters blank). Change the KEY_SIZE parameter to 2048 for the SSL/TLS to use 2048bit RSA keys for authentication. <br />
<br />
Delete any previously created certificates.<br />
<br />
{{bc|# ./clean-all}}<br />
<br />
{{Note| Entering a . (dot) when prompted for a value, blanks out the parameter.}}<br />
<br />
The build-ca script generates the [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate.<br />
<br />
{{hc|# ./build-ca|<nowiki><br />
Generating a 2048 bit RSA private key<br />
..............++++++<br />
...++++++<br />
writing new private key to 'ca.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [Acme-CA]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
</nowiki>}}<br />
<br />
The build-key-server script {{ic|# ./build-key-server <server name>}} generates a server certificate. Make sure that the server name (Common Name when running the script) is unique.<br />
<br />
{{Note|Do not enter a challenge password or company name when the script prompts you for one.}}<br />
<br />
{{hc|# ./build-key-server elmer|<nowiki><br />
Generating a 2048 bit RSA private key<br />
.....................++++++<br />
.......................................................++++++<br />
writing new private key to 'elmer.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [elmer]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
<br />
Please enter the following 'extra' attributes<br />
to be sent with your certificate request<br />
A challenge password []:<br />
An optional company name []:<br />
Using configuration from /root/easy-rsa/openssl-1.0.0.cnf<br />
Check that the request matches the signature<br />
Signature ok<br />
The Subject's Distinguished Name is as follows<br />
countryName :PRINTABLE:'US'<br />
stateOrProvinceName :PRINTABLE:'CA'<br />
localityName :PRINTABLE:'Acme Acres'<br />
organizationName :PRINTABLE:'Acme'<br />
commonName :PRINTABLE:'elmer'<br />
name :PRINTABLE:'Acme-CA'<br />
emailAddress :IA5STRING:'roadrunner@acmecorp.org'<br />
Certificate is to be certified until Dec 27 19:11:59 2021 GMT (3650 days)<br />
Sign the certificate? [y/n]:y<br />
<br />
1 out of 1 certificate requests certified, commit? [y/n]y<br />
Write out database with 1 new entries<br />
Data Base Updated<br />
</nowiki>}}<br />
<br />
The build-dh script generates the [https://web.archive.org/web/20130701090246/https://www.rsa.com/rsalabs/node.asp?id=2248 Diffie-Hellman parameters] .pem file needed by the server. This command will take some time, possibly around from 1 to 5 minutes.<br />
<br />
{{Note|It would be better to generate a new one for each server, but you can use the same one if you want to.}}<br />
<br />
{{hc|# ./build-dh|<br />
Generating DH parameters, 2048 bit long safe prime, generator 2<br />
This is going to take a long time<br />
..+.............................................................................<br />
.<br />
.<br />
.<br />
............+...............+...................................................<br />
..................................................................++*++*}}<br />
<br />
To generate the client(s) key(s), one can either do so on the server side directly using the {{ic|./build-key}} script, or generate the key entirely on the client side and then ask the CA authority to sign it. The first method is simpler and quicker, but the second method doesn't require the client private key to leave its machine and is therefore slightly more secure. (see [[#Creating certificates on the client]] for an outline of the second method)<br />
<br />
The build-key script {{ic|# ./build-key <client name>}} generates a client certificate. Make sure that the client name (Common Name when running the script) is unique.<br />
<br />
{{Note|Do not enter a challenge password or company name when the script prompts you for one.}}<br />
<br />
{{hc|# ./build-key bugs|<nowiki><br />
Generating a 2048 bit RSA private key<br />
....++++++<br />
.............................................................++++++<br />
writing new private key to 'bugs.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [bugs]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
<br />
Please enter the following 'extra' attributes<br />
to be sent with your certificate request<br />
A challenge password []:<br />
An optional company name []:<br />
Using configuration from /root/easy-rsa/openssl-1.0.0.cnf<br />
Check that the request matches the signature<br />
Signature ok<br />
The Subject's Distinguished Name is as follows<br />
countryName :PRINTABLE:'US'<br />
stateOrProvinceName :PRINTABLE:'CA'<br />
localityName :PRINTABLE:'Acme Acres'<br />
organizationName :PRINTABLE:'Acme'<br />
commonName :PRINTABLE:'bugs'<br />
name :PRINTABLE:'Acme-CA'<br />
emailAddress :IA5STRING:'roadrunner@acmecorp.org'<br />
Certificate is to be certified until Dec 27 19:18:27 2021 GMT (3650 days)<br />
Sign the certificate? [y/n]:y<br />
<br />
1 out of 1 certificate requests certified, commit? [y/n]y<br />
Write out database with 1 new entries<br />
Data Base Updated<br />
</nowiki>}}<br />
This generates a client certificate ({{ic|bugs.crt}}) and a client private key ({{ic|bugs.key}}) which need to be transferred to the client through a secure channel.<br />
<br />
Generate a secret [[Wikipedia:HMAC|Hash-based Message Authentication Code (HMAC)]] file by running:<br />
<br />
# openvpn --genkey --secret /root/easy-rsa/keys/ta.key<br />
<br />
This will be used to add an additional HMAC signature to all SSL/TLS handshake packets. In addition any UDP packet not having the correct HMAC signature will be immediately dropped, protecting against:<br />
<br />
* Portscanning.<br />
* DOS attacks on the OpenVPN UDP port.<br />
* SSL/TLS handshake initiations from unauthorized machines.<br />
* Any eventual buffer overflow vulnerabilities in the SSL/TLS implementation.<br />
<br />
All the created keys and certificates have been stored in /root/easy-rsa/keys. If you make a mistake, you can start over by running the clean-all script again.<br />
<br />
{{Warning|This will delete any previously generated certificates stored in /root/easy-rsa/keys, including the [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate.}}<br />
<br />
===Creating certificates on the client===<br />
<br />
It might be desirable for the clients to generate their private keys on their own machine, removing the need to trust that the CA operator not keep the client's private key stored remotely (or other nefarious intentions). To do so, the client needs to create the private key locally, and create a [[wikipedia:Certificate_signing_request|certificate signing request]] (which is a {{ic|.csr}} file) to the key-signing machine, run by the CA. The operator will then sign the request and return a signed certificate (a {{ic|.crt}} file) which is then transferred back to the client.<br />
<br />
====Creating a certificate signing request====<br />
<br />
An outline of the required steps follows, assuming "bugs" is the client name:<br />
# Transfer the {{ic|ca.crt}} file from the CA to the client. The {{ic|ca.crt}} file is public information, and thus this transfer can be done over an insecure channel. The file should be stored in {{ic|/root/easy-rsa/keys/ca.crt}}<br />
# Check that the {{ic|ca.crt}} file has not been tampered with by either:<br />
## Having the file be signed by the CA and verified by the client using the CA's public key. Note that this is referring to standard [[GnuPG#Signatures|GnuPG]]-style signature verification: {{ic|gpg --verify doc.sig}}<br />
## Checking the hash of the file (e.g. using {{ic|sha1sum ca.crt}}) and verifying that it matches the expected hash, provided you trust the "expected hash".<br />
## Simply transferring ca.crt over a trusted channel.<br />
## Some other mechanism that the reader sees fit.<br />
# Run {{ic|./build-req bugs}} which is analogous to running {{ic|./build-key bugs}} in the server section above. The same warning, that the Common Name should be unique, still stands.<br />
# Leave all password field blank. If you'd like to protect your private key with a password, use {{ic|./build-req-pass}} instead. Note that this will require you to input the password whenever the key needs to be unlocked.<br />
# You now have the {{ic|bugs.csr}} and {{ic|bugs.key}} files. Send your certificate signing request to the CA, e.g. by emailing your {{ic|bugs.csr}} file. Keep your {{ic|bugs.key}} file secret, this is your private key.<br />
# Wait until you receive your signed certificate from the CA, which will be a file named {{ic|bugs.crt}}.<br />
<br />
====Signing a certificate signing request====<br />
<br />
To sign a certificate signing request, the CA simply needs to run {{ic|./sign-req bugs}} after placing {{ic|bugs.csr}} into {{ic|/root/easy-rsa/keys/bugs.csr}}. The CA can then transfer the resulting {{ic|bugs.crt}} file back the client using an insecure channel (e.g. via email)<br />
{{Note| When running the command, the error {{ic|chmod: cannot access `bugs.key': No such file or directory}} will show up. This is expected, and is safe to ignore [https://forums.openvpn.net/topic13418.html]}}<br />
<br />
===Converting certificates to encrypted .p12 format===<br />
<br />
Some software (such as Android) will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
== See also ==<br />
<br />
* [https://openvpn.net/index.php/open-source/documentation/miscellaneous/rsa-key-management.html Official EasyRSA instructions]</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Easy-RSA&diff=439354Easy-RSA2016-06-29T12:32:12Z<p>Siddharthist: remove unnecessary and out-of-date vars file</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
The first step when setting up [[OpenVPN]] is to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]]. The PKI consists of:<br />
<br />
* A public master [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate and a private key.<br />
* A separate public certificate and private key pair (hereafter referred to as a certificate) for each server and each client.<br />
<br />
To facilitate the certificate creation process, OpenVPN comes with a collection of [[Wikipedia:RSA (algorithm)|RSA]] key manangement scripts (based on the openssl command line tool) known as easy-rsa.<br />
<br />
{{Note| Only .key files need to be kept secret, .crt and .csr files can be sent over insecure channels such as plaintext email.}}<br />
<br />
In this article the needed certificates are created by root in root's home directory. This ensures that the generated files have the right ownership and permissions, and are safe from other users.<br />
<br />
{{Note|The certificates can be created on any machine. For the highest security, generate the certificates on a physically secure machine disconnected from any network, and make sure that the generated ca.key private key is backed up and never accessible to anyone.}}<br />
<br />
{{Warning|Make sure that the generated files are backed up, especially the ca.key and ca.crt files, since if lost you will not be able to create any new, nor revoke any compromised certificates, thus requiring the generation of a new [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate, invalidating the entire PKI infrastructure.}}<br />
<br />
===Installing the easy-rsa scripts===<br />
<br />
First, install {{pkg|easy-rsa}} package and copy files as shown:<br />
{{bc|# cp -r /usr/share/easy-rsa /root}}<br />
<br />
===Creating certificates on the server===<br />
<br />
Change to the directory where you installed the scripts.<br />
<br />
{{bc|# cd /root/easy-rsa}}<br />
<br />
To ensure the consistent use of values when generating the PKI, set default values to be used by the PKI generating scripts. Edit /root/easy-rsa/vars and at a minimum set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters (do not leave any of these parameters blank). Change the KEY_SIZE parameter to 2048 for the SSL/TLS to use 2048bit RSA keys for authentication. <br />
<br />
Export the environment variables.<br />
<br />
{{bc|# source ./vars}}<br />
<br />
Delete any previously created certificates.<br />
<br />
{{bc|# ./clean-all}}<br />
<br />
{{Note| Entering a . (dot) when prompted for a value, blanks out the parameter.}}<br />
<br />
The build-ca script generates the [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate.<br />
<br />
{{hc|# ./build-ca|<nowiki><br />
Generating a 2048 bit RSA private key<br />
..............++++++<br />
...++++++<br />
writing new private key to 'ca.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [Acme-CA]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
</nowiki>}}<br />
<br />
The build-key-server script {{ic|# ./build-key-server <server name>}} generates a server certificate. Make sure that the server name (Common Name when running the script) is unique.<br />
<br />
{{Note|Do not enter a challenge password or company name when the script prompts you for one.}}<br />
<br />
{{hc|# ./build-key-server elmer|<nowiki><br />
Generating a 2048 bit RSA private key<br />
.....................++++++<br />
.......................................................++++++<br />
writing new private key to 'elmer.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [elmer]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
<br />
Please enter the following 'extra' attributes<br />
to be sent with your certificate request<br />
A challenge password []:<br />
An optional company name []:<br />
Using configuration from /root/easy-rsa/openssl-1.0.0.cnf<br />
Check that the request matches the signature<br />
Signature ok<br />
The Subject's Distinguished Name is as follows<br />
countryName :PRINTABLE:'US'<br />
stateOrProvinceName :PRINTABLE:'CA'<br />
localityName :PRINTABLE:'Acme Acres'<br />
organizationName :PRINTABLE:'Acme'<br />
commonName :PRINTABLE:'elmer'<br />
name :PRINTABLE:'Acme-CA'<br />
emailAddress :IA5STRING:'roadrunner@acmecorp.org'<br />
Certificate is to be certified until Dec 27 19:11:59 2021 GMT (3650 days)<br />
Sign the certificate? [y/n]:y<br />
<br />
1 out of 1 certificate requests certified, commit? [y/n]y<br />
Write out database with 1 new entries<br />
Data Base Updated<br />
</nowiki>}}<br />
<br />
The build-dh script generates the [https://web.archive.org/web/20130701090246/https://www.rsa.com/rsalabs/node.asp?id=2248 Diffie-Hellman parameters] .pem file needed by the server. This command will take some time, possibly around from 1 to 5 minutes.<br />
<br />
{{Note|It would be better to generate a new one for each server, but you can use the same one if you want to.}}<br />
<br />
{{hc|# ./build-dh|<br />
Generating DH parameters, 2048 bit long safe prime, generator 2<br />
This is going to take a long time<br />
..+.............................................................................<br />
.<br />
.<br />
.<br />
............+...............+...................................................<br />
..................................................................++*++*}}<br />
<br />
To generate the client(s) key(s), one can either do so on the server side directly using the {{ic|./build-key}} script, or generate the key entirely on the client side and then ask the CA authority to sign it. The first method is simpler and quicker, but the second method doesn't require the client private key to leave its machine and is therefore slightly more secure. (see [[#Creating certificates on the client]] for an outline of the second method)<br />
<br />
The build-key script {{ic|# ./build-key <client name>}} generates a client certificate. Make sure that the client name (Common Name when running the script) is unique.<br />
<br />
{{Note|Do not enter a challenge password or company name when the script prompts you for one.}}<br />
<br />
{{hc|# ./build-key bugs|<nowiki><br />
Generating a 2048 bit RSA private key<br />
....++++++<br />
.............................................................++++++<br />
writing new private key to 'bugs.key'<br />
-----<br />
You are about to be asked to enter information that will be incorporated<br />
into your certificate request.<br />
What you are about to enter is what is called a Distinguished Name or a DN.<br />
There are quite a few fields but you can leave some blank<br />
For some fields there will be a default value,<br />
If you enter '.', the field will be left blank.<br />
-----<br />
Country Name (2 letter code) [US]:<br />
State or Province Name (full name) [CA]:<br />
Locality Name (eg, city) [Acme Acres]:<br />
Organization Name (eg, company) [Acme]:<br />
Organizational Unit Name (eg, section) []:<br />
Common Name (eg, your name or your server's hostname) [bugs]:<br />
Name [Acme-CA]:<br />
Email Address [roadrunner@acmecorp.org]:<br />
<br />
Please enter the following 'extra' attributes<br />
to be sent with your certificate request<br />
A challenge password []:<br />
An optional company name []:<br />
Using configuration from /root/easy-rsa/openssl-1.0.0.cnf<br />
Check that the request matches the signature<br />
Signature ok<br />
The Subject's Distinguished Name is as follows<br />
countryName :PRINTABLE:'US'<br />
stateOrProvinceName :PRINTABLE:'CA'<br />
localityName :PRINTABLE:'Acme Acres'<br />
organizationName :PRINTABLE:'Acme'<br />
commonName :PRINTABLE:'bugs'<br />
name :PRINTABLE:'Acme-CA'<br />
emailAddress :IA5STRING:'roadrunner@acmecorp.org'<br />
Certificate is to be certified until Dec 27 19:18:27 2021 GMT (3650 days)<br />
Sign the certificate? [y/n]:y<br />
<br />
1 out of 1 certificate requests certified, commit? [y/n]y<br />
Write out database with 1 new entries<br />
Data Base Updated<br />
</nowiki>}}<br />
This generates a client certificate ({{ic|bugs.crt}}) and a client private key ({{ic|bugs.key}}) which need to be transferred to the client through a secure channel.<br />
<br />
Generate a secret [[Wikipedia:HMAC|Hash-based Message Authentication Code (HMAC)]] file by running:<br />
<br />
# openvpn --genkey --secret /root/easy-rsa/keys/ta.key<br />
<br />
This will be used to add an additional HMAC signature to all SSL/TLS handshake packets. In addition any UDP packet not having the correct HMAC signature will be immediately dropped, protecting against:<br />
<br />
* Portscanning.<br />
* DOS attacks on the OpenVPN UDP port.<br />
* SSL/TLS handshake initiations from unauthorized machines.<br />
* Any eventual buffer overflow vulnerabilities in the SSL/TLS implementation.<br />
<br />
All the created keys and certificates have been stored in /root/easy-rsa/keys. If you make a mistake, you can start over by running the clean-all script again.<br />
<br />
{{Warning|This will delete any previously generated certificates stored in /root/easy-rsa/keys, including the [[Wikipedia:Certificate Authority|Certificate Authority (CA)]] certificate.}}<br />
<br />
===Creating certificates on the client===<br />
<br />
It might be desirable for the clients to generate their private keys on their own machine, removing the need to trust that the CA operator not keep the client's private key stored remotely (or other nefarious intentions). To do so, the client needs to create the private key locally, and create a [[wikipedia:Certificate_signing_request|certificate signing request]] (which is a {{ic|.csr}} file) to the key-signing machine, run by the CA. The operator will then sign the request and return a signed certificate (a {{ic|.crt}} file) which is then transferred back to the client.<br />
<br />
====Creating a certificate signing request====<br />
<br />
An outline of the required steps follows, assuming "bugs" is the client name:<br />
# Transfer the {{ic|ca.crt}} file from the CA to the client. The {{ic|ca.crt}} file is public information, and thus this transfer can be done over an insecure channel. The file should be stored in {{ic|/root/easy-rsa/keys/ca.crt}}<br />
# Check that the {{ic|ca.crt}} file has not been tampered with by either:<br />
## Having the file be signed by the CA and verified by the client using the CA's public key. Note that this is referring to standard [[GnuPG#Signatures|GnuPG]]-style signature verification: {{ic|gpg --verify doc.sig}}<br />
## Checking the hash of the file (e.g. using {{ic|sha1sum ca.crt}}) and verifying that it matches the expected hash, provided you trust the "expected hash".<br />
## Simply transferring ca.crt over a trusted channel.<br />
## Some other mechanism that the reader sees fit.<br />
# Run {{ic|./build-req bugs}} which is analogous to running {{ic|./build-key bugs}} in the server section above. The same warning, that the Common Name should be unique, still stands.<br />
# Leave all password field blank. If you'd like to protect your private key with a password, use {{ic|./build-req-pass}} instead. Note that this will require you to input the password whenever the key needs to be unlocked.<br />
# You now have the {{ic|bugs.csr}} and {{ic|bugs.key}} files. Send your certificate signing request to the CA, e.g. by emailing your {{ic|bugs.csr}} file. Keep your {{ic|bugs.key}} file secret, this is your private key.<br />
# Wait until you receive your signed certificate from the CA, which will be a file named {{ic|bugs.crt}}.<br />
<br />
====Signing a certificate signing request====<br />
<br />
To sign a certificate signing request, the CA simply needs to run {{ic|./sign-req bugs}} after placing {{ic|bugs.csr}} into {{ic|/root/easy-rsa/keys/bugs.csr}}. The CA can then transfer the resulting {{ic|bugs.crt}} file back the client using an insecure channel (e.g. via email)<br />
{{Note| When running the command, the error {{ic|chmod: cannot access `bugs.key': No such file or directory}} will show up. This is expected, and is safe to ignore [https://forums.openvpn.net/topic13418.html]}}<br />
<br />
===Converting certificates to encrypted .p12 format===<br />
<br />
Some software (such as Android) will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
== See also ==<br />
<br />
* [https://openvpn.net/index.php/open-source/documentation/miscellaneous/rsa-key-management.html Official EasyRSA instructions]</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=User:Siddharthist&diff=434370User:Siddharthist2016-05-09T02:50:23Z<p>Siddharthist: quick bio</p>
<hr />
<div>New to the wiki, hope to be more useful than annoying.</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Talk:Systemd/User&diff=434369Talk:Systemd/User2016-05-09T02:49:49Z<p>Siddharthist: Asked a question about using startx in the xorg user service</p>
<hr />
<div>== Setting Environment variables without autologin/user-session@.service ==<br />
<br />
If you're not using auto-login, specifically the user-session@service, the environment variable DBUS_SESSION_BUS_ADDRESS needs to exported to something like {{ic|export DBUS_SESSION_BUS_ADDRESS&#61;/run/user/$(id -u)/dbus/user_bus_socket}} before {{ic|systemd --user}}. Otherwise, an error shows up in journalctl : "systemd[3975]: Failed to open private bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11." Are there any other environment variables that need to be added to that section?<br />
[[User:Feynman|Feynman]] ([[User talk:Feynman|talk]]) 23:57, 5 February 2013 (UTC)<br />
<br />
::Not really. I'm not using auto-login and I'm not using any DE or login manager. It was a bug I ''believe'' on older versions on systemd. Since 198 it's not longer necessary. I still get that error on the start but it actually works without hassle. --[[User:Pabloxcl|Pabloxcl]] ([[User talk:Pabloxcl|talk]]) 16:21, 7 April 2013 (UTC)<br />
<br />
== Increasing priority of user services ==<br />
<br />
How can I increase priority for user services? When I try to use {{ic|1=CPUShares=2048}}, I get {{ic|Failed to create cgroup cpu:/user/1000.user/2.session/systemd-536/xorg.service: Permission denied}}, when I try to use {{ic|1=Nice=-15}}, I get {{ic|Failed at step NICE spawning /usr/bin/xorg-launch-helper: Permission denied}}.<br />
<br />
== Starting services using a display manager ==<br />
<br />
I had a hard time trying to use {{ic|systemd --user}} with a display manager. I use Slim, so I just put {{ic|systemd --user &}} in my {{ic|~/.xinitrc}} just before starting my WM (Awesome). Systemd started but nothing else happened. In fact I had to create a {{ic|default.target}} file in {{ic|~/.config/systemd/user/}} containing only<br />
[Unit]<br />
AllowIsolate=yes<br />
and then enable services provided that each file contains<br />
[Install]<br />
WantedBy=default.target<br />
Then all went well, {{ic|systemd --user}} launch a dbus user session and all enabled service.<br />
<br />
I think the important part is the {{ic|default.target}} file, which is documented in [[Systemd/User#Using /usr/lib/systemd/systemd --user To Manage Your Session]] but not at all talked about in the previous sections. I'm not sure how to add this to the wiki, or even if my method is the right way to do it using a DM, So I prefer discuss this on this page. [[User:Ianux|Ianux]] ([[User talk:Ianux|talk]]) 17:57, 14 September 2013 (UTC)<br />
<br />
== Passing DBUS_SESSION_BUS_ADDRESS to session ==<br />
<br />
After setting variable in <tt>/etc/systemd/system/user@.service.d/dbus.conf</tt> it is present in systemd --user (and its services) environment, as can be verified by <tt>systemctl --user show-environment</tt>, but how is it exactly passed to session processes? [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 14:20, 4 July 2015 (UTC)<br />
<br />
:It isn't, because {{ic|systemd --user}} runs outside the user session. The default {{ic|/etc/X11/xinit/xinitrc.d/30-dbus.sh}} starts another bus exclusively for the X session. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:43, 4 July 2015 (UTC)<br />
<br />
::I thought the intent of this guide was to setup a single "user" bus shared by all user sessions (X, text, remote SSH logins) and by {{ic|systemd --user}}, wasn't it? [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 18:16, 4 July 2015 (UTC)<br />
<br />
:::The first paragraph of [[Systemd/User#D-Bus]] explains the purpose. There are multiple different ways which will all "work" in certain cases. The current recommended way seems to be having multiple user buses, but in the future, as grawity indicated below, there will be only a single bus. If you want to see if the single bus aproach works for you, just {{ic|1=export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus}} from your shell startup file and make sure that {{ic|/etc/X11/xinit/xinitrc.d/30-dbus.sh}} is not run. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:48, 4 July 2015 (UTC)<br />
<br />
::::Somehow it wasn't clear to me. Anyway, I think the best place for setting this variable would be somewhere in PAM. [[User:Pmartycz|Pmartycz]] ([[User talk:Pmartycz|talk]]) 21:02, 4 July 2015 (UTC)<br />
<br />
:On a kdbus system, {{ic|pam_systemd}} would set it for you. --[[User:Grawity|grawity]] ([[User talk:Grawity|talk]]) 16:06, 4 July 2015 (UTC)<br />
<br />
== Simplifying the Xorg and Systemd section ==<br />
<br />
Why doesn't the [[Systemd/User#Xorg_and_systemd]] just use the startx wrapper program? I set up a service file like this and it seems to work just fine:<br />
<br />
{{hc|~/.config/systemd/user/xorg.service|<nowiki><br />
[Unit]<br />
Description=Xorg server<br />
<br />
[Service]<br />
Type=simple<br />
SuccessExitStatus=0 1<br />
<br />
ExecStart=/usr/bin/startx<br />
</nowiki>}}<br />
<br />
This seems a lot simpler than the configuration described. Sorry if this is a dumb question! <br />
[[User:Siddharthist|Siddharthist]] ([[User talk:Siddharthist|talk]]) 02:49, 9 May 2016 (UTC)</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Systemd/User&diff=434368Systemd/User2016-05-09T02:26:27Z<p>Siddharthist: Fix "above" link from "#DISPLAY" to "#DISPLAY_and_XAUTHORITY"</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Daemons and system services]]<br />
[[Category:Boot process]]<br />
[[es:Systemd/User]]<br />
[[fr:Systemd/utilisateur]]<br />
[[it:Systemd/User]]<br />
[[ja:Systemd/ユーザー]]<br />
[[ru:Systemd/User]]<br />
[[zh-CN:Systemd/User]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Automatic login to virtual console}}<br />
{{Related|Start X at login}}<br />
{{Related articles end}}<br />
<br />
[[systemd]] offers users the ability to manage services under the user's control with a per-user systemd instance, enabling users to start, stop, enable, and disable their own units. This is convenient for daemons and other services that are commonly run for a single user, such as [[mpd]], or to perform automated tasks like fetching mail. With some caveats it is even possible to run xorg and the entire window manager from user services.<br />
<br />
== How it works ==<br />
<br />
As per default configuration in {{ic|/etc/pam.d/system-login}}, the {{ic|pam_systemd}} module automatically launches a {{ic|systemd --user}} instance when the user logs in for the first time. This process will survive as long as there is some session for that user, and will be killed as soon as the last session for the user is closed. When [[#Automatic start-up of systemd user instances]] is enabled, the instance is started on boot and will not be killed. The systemd user instance is responsible for managing user services, which can be used to run daemons or automated tasks, with all the benefits of systemd, such as socket activation, timers, dependency system or strict process control via cgroups.<br />
<br />
Similarly to system units, user units are located in the following directories (ordered by ascending precedence):<br />
<br />
* {{ic|/usr/lib/systemd/user/}} where units provided by installed packages belong.<br />
* {{ic|~/.local/share/systemd/user/}} where units of packages that have been installed in the home directory belong.<br />
* {{ic|/etc/systemd/user/}} where system-wide user units are placed by the system administrator.<br />
* {{ic|~/.config/systemd/user/}} where the user puts its own units.<br />
<br />
When systemd user instance starts, it brings up the target {{ic|default.target}}. Other units can be controlled manually with {{ic|systemctl --user}}.<br />
<br />
{{Note|<br />
* Be aware that since version 206, the {{ic|systemd --user}} instance is a per-user process, and not per-session. The rationale is that most resources handled by user services, like sockets or state files will be per-user (live on the user's home dir) and not per session. This means that all user services run outside of a session. As a consequence, programs that need to be run inside a session will probably break in user services. The way systemd handles user sessions is pretty much in flux. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [http://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html] for some hints on where things are going.<br />
* {{ic|systemd --user}} runs as a separate process from the {{ic|systemd --system}} process. User units can not reference or depend on system units.<br />
}}<br />
<br />
== Basic setup ==<br />
<br />
All the user services will be placed in {{ic|~/.config/systemd/user/}}. If you want to run services on first login, execute {{ic|systemctl --user enable ''service''}} for any service you want to be autostarted.<br />
<br />
=== D-Bus ===<br />
<br />
Some programs will need a [[D-Bus]] user message bus. Traditionally it had been started when launching a desktop environment via {{ic|dbus-launch}}, but since version 226, systemd has become the manager of the user message bus.[https://www.archlinux.org/news/d-bus-now-launches-user-buses/] The ''dbus-daemon'' is started once per user for all sessions with the provided {{ic|dbus.socket}} and {{ic|dbus.service}} user units.<br />
<br />
{{Note|If you had previously created these units manually under {{ic|/etc/systemd/user/}} or {{ic|~/.config/systemd/user/}}, they can be removed.}}<br />
<br />
=== Environment variables ===<br />
<br />
The user instance of systemd does not inherit any of the [[environment variables]] set in places like {{ic|.bashrc}} etc. There are several ways to set environment variables for the systemd user instance:<br />
<br />
# For users with a {{ic|$HOME}} directory, use the {{ic|DefaultEnvironment}} option in {{ic|~/.config/systemd/user.conf}}. Affects only that user's user unit.<br />
# Use the {{ic|DefaultEnvironment}} option in {{ic|/etc/systemd/user.conf}} file. Affects all user units.<br />
# Add a drop-in config file in {{ic|/etc/systemd/system/user@.service.d/}}. Affects all user units; see [[#Service example]]<br />
# At any time, use {{ic|systemctl --user set-environment}} or {{ic|systemctl --user import-environment}}. Affects all user units started after setting the environment variables, but not the units that were already running.<br />
# Using the {{ic|dbus-update-activation-environment --systemd --all}} command provided by [[dbus]]. Has the same effect as {{ic|systemctl --user import-environment}}, but also affects the D-Bus session. You can add this to the end of your shell initialization file.<br />
<br />
One variable you may want to set is {{ic|PATH}}.<br />
<br />
==== Service example ====<br />
Create the [[Systemd#Drop-in_snippets|drop-in]] directory {{ic|/etc/systemd/system/user@.service.d/}} and inside create a file that has the extension {{ic|.conf}} (e.g. {{ic|local.conf}}):<br />
{{hc|/etc/systemd/system/user@.service.d/local.conf|2=<br />
[Service]<br />
Environment="PATH=/usr/lib/ccache/bin/:$PATH"<br />
Environment="EDITOR=nano -c"<br />
Environment="BROWSER=firefox"<br />
Environment="NO_AT_BRIDGE=1"<br />
}}<br />
<br />
==== DISPLAY and XAUTHORITY ====<br />
<br />
{{ic|DISPLAY}} is used by any X application to know which display to use and {{ic|XAUTHORITY}} to provide a path to the user's {{ic|.Xauthority}} file and thus the cookie needed to access the X server. If you plan on launching X applications from systemd units, these variables need to be set. Since [https://github.com/systemd/systemd/blob/v219/NEWS#L194 version 219], systemd provides a script in {{ic|/etc/X11/xinit/xinitrc.d/50-systemd-user.sh}} to import those variables into the systemd user session on X launch. So unless you start X in a nonstandard way, user services should be aware of the {{ic|DISPLAY}} and {{ic|XAUTHORITY}}.<br />
<br />
==== PATH ====<br />
<br />
As any other environment variable you set in {{ic|.bashrc}} or {{ic|.bash_profile}}, the {{ic|PATH}} variable is not available to systemd. If you customize your {{ic|PATH}} and plan on launching applications that make use of it from systemd units, you should make sure the modified {{ic|PATH}} is set on the systemd environment. Assuming you set your {{ic|PATH}} in {{ic|.bash_profile}}, the best way to make systemd aware of your modified {{ic|PATH}} is by adding the following to {{ic|.bash_profile}} after the {{ic|PATH}} variable is set:<br />
<br />
{{hc|~/.bash_profile|<nowiki><br />
systemctl --user import-environment PATH<br />
</nowiki>}}<br />
<br />
=== Automatic start-up of systemd user instances ===<br />
<br />
The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for specific user:<br />
<br />
# loginctl enable-linger ''username''<br />
<br />
{{Warning|systemd services are '''not''' sessions, they run outside of ''logind''. Do not use lingering to enable automatic login as it will [[General troubleshooting#Session permissions|break the session]].}}<br />
<br />
== Xorg and systemd ==<br />
<br />
There are several ways to run xorg within systemd units. Below there are two options, either by starting a new user session with an xorg process, or by launching xorg from a systemd user service.<br />
<br />
=== Automatic login into Xorg without display manager ===<br />
<br />
{{Accuracy|This setup ends up with two user D-Bus buses, one for the desktop, and an other for systemd. Why can't we use the systemd one alone? }}<br />
<br />
This option will launch a system unit that will start a user session with an xorg server and then run the usual {{ic|~/.xinitrc}} to launch the window manager, etc.<br />
<br />
You need to have [[#D-Bus]] correctly set up and {{AUR|xlogin-git}} installed.<br />
<br />
Set up your [[xinitrc]] from the skeleton, so that it will source the files in {{ic|/etc/X11/xinit/xinitrc.d/}}. Running your {{ic|~/.xinitrc}} should not return, so either have {{ic|wait}} as the last command, or add {{ic|exec}} to the last command that will be called and which should not return (your window manager, for instance).<br />
<br />
The session will use its own dbus daemon, but various systemd utilities will automatically connect to the {{ic|dbus.service}} instance.<br />
<br />
Finally, enable ('''as root''') the ''xlogin'' service for automatic login at boot:<br />
<br />
# systemctl enable xlogin@''username''<br />
<br />
The user session lives entirely inside a systemd scope and everything in the user session should work just fine.<br />
<br />
=== Xorg as a systemd user service ===<br />
<br />
Alternatively, [[xorg]] can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.<br />
<br />
Since version 1.16 {{Pkg|xorg-server}} provides better integration with systemd in two ways:<br />
* Can be run unprivileged, delegating device management to logind (see Hans de Goede commits around [http://cgit.freedesktop.org/xorg/xserver/commit/?id=82863656ec449644cd34a86388ba40f36cea11e9 this commit]).<br />
* Can be made into a socket activated service (see [http://cgit.freedesktop.org/xorg/xserver/commit/?id=b3d3ffd19937827bcbdb833a628f9b1814a6e189 this commit]). This removes the need for {{AUR|systemd-xorg-launch-helper-git}}.<br />
<br />
Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and can't take advantage of the unprivileged mode introduced in 1.16.<br />
<br />
{{Note|This is not a fundamental restriction imposed by logind, but the reason seems to be that xorg needs to know which session to take over, and right now it gets this information calling [http://www.freedesktop.org/wiki/Software/systemd/logind logind]'s {{ic|GetSessionByPID}} using its own pid as argument. See [http://lists.x.org/archives/xorg-devel/2014-February/040476.html this thread] and [http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/systemd-logind.c xorg sources]. It seems likely that xorg could be modified to get the session from the tty it is attaching to, and then it could run unprivileged from a user service outside a session.}}<br />
<br />
{{Warning|1=On xorg 1.18 socket activation seems to be broken. The client triggering the activation deadlocks. See the upstream bug report [https://bugs.freedesktop.org/show_bug.cgi?id=93072]. As a temporary workaround you can start the xorg server without socket activation, making sure the clients connect after a delay, so the server is fully started. There seems to be no nice mechanism te get startup notification for the X server.}}<br />
<br />
This is how to launch xorg from a user service:<br />
<br />
1. Make xorg run with root privileges and for any user, by editing {{ic|/etc/X11/Xwrapper.config}} <br />
<br />
{{hc|/etc/X11/Xwrapper.config|<nowiki><br />
allowed_users=anybody<br />
needs_root_rights=yes<br />
</nowiki>}}<br />
<br />
2. Add the following units to {{ic|~/.config/systemd/user}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.socket|<nowiki><br />
[Unit]<br />
Description=Socket for xorg at display %i<br />
<br />
[Socket]<br />
ListenStream=/tmp/.X11-unix/X%i<br />
</nowiki>}}<br />
<br />
{{hc|~/.config/systemd/user/xorg@.service|<nowiki><br />
[Unit]<br />
Description=Xorg server at display %i<br />
<br />
Requires=xorg@%i.socket<br />
After=xorg@%i.socket<br />
<br />
[Service]<br />
Type=simple<br />
SuccessExitStatus=0 1<br />
<br />
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"<br />
</nowiki>}}<br />
<br />
where {{ic|${XDG_VTNR} }} is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with<br />
<br />
$ systemctl --user set-environment XDG_VTNR=1<br />
<br />
{{Note|xorg should be launched at the same virtual terminal where the user logged in. Otherwise logind will consider the session inactive.}}<br />
<br />
3. Make sure to configure the {{ic|DISPLAY}} environment variable as explained [[#DISPLAY_and_XAUTHORITY|above]].<br />
<br />
4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:<br />
<br />
$ systemctl --user set-environment XDG_VTNR=2 # So that xorg@.service knows which vt use<br />
$ systemctl --user start xorg@0.socket # Start listening on the socket for display 0<br />
<br />
Now running any X application will launch xorg on virtual terminal 2 automatically.<br />
<br />
The environment variable {{ic|XDG_VTNR}} can be set in the systemd environment from {{ic|.bash_profile}}, and then one could start any X application, including a window manager, as a systemd unit that depends on {{ic|xorg@0.socket}}.<br />
<br />
{{Warning|Currently running a window manager as a user service means it runs outside of a session with the problems this may bring: [[General troubleshooting#Session permissions|break the session]]. However, it seems that systemd developers intend to make something like this possible. See [https://mail.gnome.org/archives/desktop-devel-list/2014-January/msg00079.html] and [http://lists.freedesktop.org/archives/systemd-devel/2014-March/017552.html]}}<br />
<br />
== Writing user units ==<br />
<br />
=== Example ===<br />
<br />
The following is an example of a user version of the mpd service.<br />
{{hc|~/.config/systemd/user/mpd.service|<nowiki><br />
[Unit]<br />
Description=Music Player Daemon<br />
<br />
[Service]<br />
ExecStart=/usr/bin/mpd --no-daemon<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
=== Example with variables ===<br />
<br />
The following is an example of a user version of {{ic|sickbeard.service}}, which takes into account variable home directories where SickBeard can find certain files:<br />
<br />
{{hc|~/.config/systemd/user/sickbeard.service|<nowiki><br />
[Unit]<br />
Description=SickBeard Daemon<br />
<br />
[Service]<br />
ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
As detailed in {{ic|man systemd.unit}}, the {{ic|%h}} variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the [[systemd]] manpages.<br />
<br />
=== Note about X applications ===<br />
<br />
Most X apps need a {{ic|DISPLAY}} variable to run. See [[#DISPLAY and XAUTHORITY]] for how to this variable is set for the entire systemd user instance.<br />
<br />
== Some use cases ==<br />
<br />
=== Persistent terminal multiplexer ===<br />
<br />
{{Out of date|References {{ic|user-session@.service}} instead of {{ic|user@.service}}; the latter does not contain {{ic|1=Conflicts=getty@tty1.service}}.}}<br />
<br />
You may wish your user session to default to running a terminal multiplexer, such as [[GNU Screen]] or [[Tmux]], in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with myStuff.target). <br />
<br />
To create this type of user session, procede as above, but instead of creating wm.target, create multiplexer.target:<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=Terminal multiplexer<br />
Documentation=info:screen man:screen(1) man:tmux(1)<br />
After=cruft.target<br />
Wants=cruft.target<br />
<br />
[Install]<br />
Alias=default.target<br />
}}<br />
<br />
{{ic|cruft.target}}, like {{ic|mystuff.target}} above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.<br />
<br />
You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to {{ic|/tmp/gpg-agent-info}}. This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.<br />
<br />
{{bc|1=<br />
[Unit]<br />
Description=tmux: A terminal multiplixer <br />
Documentation=man:tmux(1)<br />
After=gpg-agent.service<br />
Wants=gpg-agent.service<br />
<br />
[Service]<br />
Type=forking<br />
ExecStart=/usr/bin/tmux start<br />
ExecStop=/usr/bin/tmux kill-server<br />
Environment=DISPLAY=:0<br />
EnvironmentFile=/tmp/gpg-agent-info<br />
<br />
[Install]<br />
WantedBy=multiplexer.target<br />
}}<br />
<br />
Once this is done, {{ic|systemctl --user enable}} {{ic|tmux.service}}, {{ic|multiplexer.target}} and any services you created to be run by {{ic|cruft.target}} and you should be set to go! Activated {{ic|user-session@.service}} as described above, but be sure to remove the {{ic|1=Conflicts=getty@tty1.service}} from {{ic|user-session@.service}}, since your user session will not be taking over a TTY. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!<br />
<br />
=== Window manager ===<br />
<br />
To run a window manager as a systemd service, you first need to run [[#Xorg as a systemd user service]]. In the following we will use awesome as an example:<br />
<br />
{{hc|~/.config/systemd/user/awesome.service|<nowiki><br />
[Unit]<br />
Description=Awesome window manager<br />
After=xorg.target<br />
Requires=xorg.target<br />
<br />
[Service]<br />
ExecStart=/usr/bin/awesome<br />
Restart=always<br />
RestartSec=10<br />
<br />
[Install]<br />
WantedBy=wm.target<br />
</nowiki>}}<br />
<br />
{{Note|The {{ic|[Install]}} section includes a {{ic|WantedBy}} part. When using {{ic|systemctl --user enable}} it will link this as {{ic|~/.config/systemd/user/wm.target.wants/''window_manager''.service}}, allowing it to be started at login. Is recommended to enable this service, not to link it manually.}}<br />
<br />
== See also ==<br />
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home KaiSforza's Bitbucket wiki]<br />
* [https://github.com/zoqaeski/systemd-user-units Zoqaeski's units on GitHub]<br />
* [https://bbs.archlinux.org/viewtopic.php?id=167115 Arch forum thread about changes in systemd 206 user instances]</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Lenovo_IdeaPad_Yoga_2_Pro&diff=409530Lenovo IdeaPad Yoga 2 Pro2015-11-18T19:15:21Z<p>Siddharthist: fix typo, add permissions note</p>
<hr />
<div>[[Category:Lenovo]]<br />
{{Poor writing|Missing templates, poorly organized}}<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Graphics || style="color:green" | '''Working''' || xf86-video-intel<br />
|-<br />
| Wireless || style="color:green" | '''Working*''' || iwlwifi<br />
|-<br />
| Audio || style="color:green" | '''Working''' || snd_hda_intel<br />
|-<br />
| Touchscreen || style="color:green" | '''Working''' || usbtouchscreen<br />
|-<br />
| Accelerometer || style="color:red" | '''Not Working''' ||<br />
|-<br />
| Touchpad || style="color:green" | '''Working''' || xf86-input-synaptics<br />
|-<br />
| Camera || style="color:green" | '''Working''' ||<br />
|-<br />
| Card Reader || style="color:blue" | '''Unknown''' ||<br />
|-<br />
| Bluetooth || style="color:green" | '''Working''' ||<br />
|}<br />
<br />
<br />
==Installation==<br />
Installing Arch on the HiDPI screen may be difficult as the text will be hard to read. To make the font more readable, before you hit install, [[Kernel_mode_setting#Disabling_modesetting|disable mode settings]]. Hit Tab in the arch linux boot menu and append the option {{ic|nomodeset}} along with {{ic|nomodeset}} kernel parameter. For Intel graphics card you need to add {{ic|1=i915.modeset=0}} and for Nvidia graphics card you need to add {{ic|1=nouveau.modeset=0}}. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. {{ic|1="nomodeset i915.modeset=0 nouveau.modeset=0"}}).<br />
<br />
==The ideapad_laptop module==<br />
<br />
Several problems come up if the ideapad_laptop module is in use. Namely, it blocks the network card and generates a massive stream of warning from the USB subsystem such as:<br />
<br />
Dec 5 08:40:44 localhost kernel: [ 290.632613] xhci_hcd 0000:00:14.0: ep 0x81 - asked for 15360 bytes, 15117 bytes untransferred<br />
Dec 5 08:40:44 localhost kernel: [ 290.735110] xhci_hcd 0000:00:14.0: ep 0x81 - asked for 15360 bytes, 15117 bytes untransferred<br />
Dec 5 08:40:44 localhost kernel: [ 290.837534] xhci_hcd 0000:00:14.0: ep 0x81 - asked for 15360 bytes, 15117 bytes untransferred<br />
Dec 5 08:40:44 localhost kernel: [ 290.940070] xhci_hcd 0000:00:14.0: ep 0x81 - asked for 15360 bytes, 15117 bytes untransferred<br />
Dec 5 08:40:44 localhost kernel: [ 291.042570] xhci_hcd 0000:00:14.0: ep 0x81 - asked for 15360 bytes, 15117 bytes untransferred<br />
<br />
You can silence these in the short run by running:<br />
<br />
# dmesg -D<br />
<br />
And you can unblock the wireless card by running:<br />
<br />
# rfkill unblock wlan<br />
<br />
However, in the long term, you will probably want to blacklist the {{ic|ideapad_laptop}} driver so that neither of these occur in the first place. I am yet to find a disadvantage to doing so.<br />
<br />
==Keyboard and other hardware keys==<br />
To access boot menu or BIOS settings, you must use the alternate power button, next to the standard one.<br />
<br />
No keypad available at all.<br />
<br />
===Keyboard special keys===<br />
{{note | A working keymap means that there is some output in {{ic|xev}} when the key combination is pressed OR that the functionality is built in and "just works". It does not means that the keymap is linked to the functionality. For that it is often necessary to add a keyboard shortcut [[Extra keyboard keys in Xorg|by the method of your choice]] or to use a desktop shell with built-in shortcut support for the keycode in question. For some of the keys the function operates on a BIOS level and no shortcut is needed.}}<br />
<br />
{{note| BIOS has a setting to flip the behavior of the FN key.}}<br />
<br />
{| class="wikitable"<br />
! Keys!! Function !! X sees<br />
|-<br />
| {{ic|Fn+F1}} || Audio mute/unmute || XF86AudioMute<br />
|-<br />
| {{ic|Fn+F2}} || Audio volume down || XF86AudioLowerVolume<br />
|-<br />
| {{ic|Fn+F3}} || Audio volume up || XF86AudioRaiseVolume<br />
|-<br />
| {{ic|Fn+F4}} || Close application || {{ic|Alt_L+F4}}<br />
|-<br />
| {{ic|Fn+F5}} || Refresh page || {{ic|F5}}<br />
|-<br />
| {{ic|Fn+F6}} || Disable Touchpad || ?<br />
|-<br />
| {{ic|Fn+F7}} || Airplane mode || ?<br />
|-<br />
| {{ic|Fn+F8}} || Unknown || {{ic|Alt_L+Tab}}<br />
|-<br />
| {{ic|Fn+F9}} || Turn off LCD || ?<br />
|-<br />
| {{ic|Fn+F10}} || Toggle display || {{ic|Super+p}}<br />
|-<br />
| {{ic|Fn+F11}} || Dim LCD backlight || XF86MonBrightnessDown<br />
|-<br />
| {{ic|Fn+F12}} || Brighten LCD backlight || XF86MonBrightnessUp<br />
|}<br />
<br />
===Hardware keys on right side===<br />
From hinge to front:<br />
XF86AudioRaiseVolume<br />
XF86AudioLowerVolume<br />
Super_L+o<br />
<br />
==Touchscreen==<br />
Touchscreen USB device seems to come and go if the {{ic|usbtouchscreen}} module is not loaded.<br />
<br />
===Multitouch gestures===<br />
You need to install {{aur|Touchegg}} from the [[AUR]] in order to enable multitouch gestures. Optionally, you can install {{aur|touchegg-gce-git}} as a graphical front-end. See more details in the [[Touchegg|dedicated wiki page]].<br />
{{Tip| If you use [[Gnome Shell]] you should start {{ic|touchegg}} before it, in order to avoid conflicts.}}<br />
<br />
===Touchscreen button===<br />
The touchscreen button with a Windows logo is mapped as {{ic|Super}}. However, {{ic|key_down}} and {{ic|key_up}} are generated simultaneously on touch release. The haptic feedback (vibration) when touching this button is currently not controllable via software.<br />
<br />
===Touchscreen stops working after suspension===<br />
Sometimes touchscreen stops working after resuming from suspension mode. You should be able to fix the problem reloading the {{ic|usbhid}} and {{ic|usbtouchscreen}} kernel modules:<br />
<br />
# modprobe -r usbhid usbtouchscreen<br />
<br />
==ACPI==<br />
I modified {{ic|/etc/acpi/default.sh}} to allow for some debugging and additional features (see below):<br />
#!/bin/sh<br />
set $*<br />
group=${1%%/*}<br />
device=$2<br />
id=$3<br />
value=$4<br />
log_unhandled() {<br />
logger "ACPI event unhandled: $*"<br />
}<br />
case "$group" in<br />
button)<br />
case "$action" in<br />
power)<br />
/etc/acpi/actions/powerbtn.sh<br />
;;<br />
lid)<br />
/etc/acpi/actions/lid.sh<br />
;;<br />
*) log_unhandled $* ;;<br />
esac<br />
;;<br />
ac_adapter)<br />
case "$value" in<br />
*) log_unhandled $* ;;<br />
esac<br />
;;<br />
*) echo $* > /dev/tty5<br />
log_unhandled $* ;;<br />
esac<br />
<br />
<br />
===Touchpad===<br />
The touchpad sends random input from time to time, especially when lid is closed. If you like your computer to keep running when the lid is closed, you may want to disable the touchpad with ACPI events:<br />
;/etc/acpi/actions/lid.sh<br />
#!/bin/bash<br />
export DISPLAY=:0<br />
if grep closed /proc/acpi/button/lid/LID0/state<br />
then<br />
synclient TouchpadOff=1 2>/dev/tty5 && echo "lid closed, disabling touchpad" >/dev/tty5<br />
else<br />
synclient TouchpadOff=0 2>/dev/tty5 && echo "lid open, eênabling touchpad" >/dev/tty5<br />
fi<br />
Of course, the echo statement is optional and for debug purposes.<br />
<br />
===Backlight===<br />
With newer kernels (I am currently using {{ic|3.17.6-1-ARCH}}) backlight works out-of-the-box.<br />
<br />
"old" (ref needed) kernels require boot argument<br />
acpi_backlight=vendor<br />
<br />
Screen backlight brightness can be manually set with<br />
# echo $VAL > /sys/class/backlight/intel_backlight/brightness<br />
with $VAL between 0 and 937<br />
<br />
It's possible that you will get a permission denied error, in which case you can run <br />
# chmod a+rw /sys/class/backlight/intel_backlight/brightness<br />
which makes the brightness editable by any user.<br />
<br />
===Battery===<br />
Battery info can be accessed with<br />
ls /sys/class/power_supply/BAT1/*<br />
Unfortunately, the values obtained there have no units (older Lenovo products had rates in mA, battery voltage, etc.)<br />
<br />
==Graphics==<br />
<br />
Steam crashes trying to run games complaining about missing i965 module. It seems some applications treat it as accelerated, and some do not.<br />
<br />
Resolution seems to be not so well supported by some desktop environments/window managers. Gnome-based DEs like Cinnamon and Mate, as well as XFCE and fvwm seem to work fine.<br />
<br />
Users may wish to boost font-sizes, as the HiDPI screen can be hard to read in some settings.<br />
<br />
<br />
<br />
If you have trouble detecting a display with the micro hdmi port, consider filing the plastic on the male hdmi plug back a bit (not on the laptop). See [https://forums.lenovo.com/t5/Lenovo-Edge-Yoga-Flex-Laptops/Yoga-2-Pro-micro-HDMi-issue-SOLVED/td-p/1297269 here]. The ruber case can prevent the plug from inserting fully.<br />
<br />
==Rotation/Conversion==<br />
<br />
You can easily rotate screen with xrandr, however it does not rotate touchscreen/touchpad input which makes it fairly awkward to use. There is a [https://github.com/wolneykien/xrandr-align project] attempting to address this. Keyboard hardware-disables in tablet mode, but touchpad is still active which needs to be addressed. No ACPI or keycode signals appear to be emitted for the various screen rotation states.<br />
<br />
==See also==<br />
* The LinLap site has some good information - see [http://www.linlap.com/lenovo_ideapad_yoga_2_pro];<br />
* a good Review of Arch Linux on a HiDPI Lenovo Yoga 2 Pro by KeithCU with useful comments [http://keithcu.com/wordpress/?p=3270 ];<br />
* an installation guide written by Ubuntu users: [http://askubuntu.com/questions/367963/ubuntu-on-lenovo-yoga-2-pro ].</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=Gamepad&diff=390720Gamepad2015-08-10T00:12:17Z<p>Siddharthist: /* Specific devices */</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Gaming]]<br />
[[ja:ゲームパッド]]<br />
Joysticks can be a bit of a hassle to get working in Linux. Not because they are poorly supported, but simply because you need to determine which modules to load to get your joystick working, and it's not always very obvious!<br />
<br />
== Joystick Input Systems ==<br />
Linux actually has 2 different input systems for Joysticks. The original 'Joystick' interface and the newer 'evdev' based one.<br />
<br />
{{ic|1=/dev/input/jsX}} maps to the 'Joystick' API interface and {{ic|/dev/input/event*}} maps to the 'evdev' ones (this also includes other input devices such as mice and keyboards). Symbolic links to those devices are also available in {{ic|/dev/input/by-id/}} and {{ic|/dev/input/by-path/}} where the legacy 'Joystick' API has names ending with {{ic|-joystick}} while the 'evdev' have names ending with {{ic|-event-joystick}}.<br />
<br />
Most new games will default to the 'evdev' interface as it gives more detailed information about the buttons and axes available and also adds support for force feedback.<br />
<br />
While SDL1.x defaults to 'evdev' interface you can force it to use the old 'Joystick' API by setting the environment variable {{ic|1=SDL_JOYSTICK_DEVICE=/dev/input/js0}}. This can help many games such as X3. SDL2.x supports only the new 'evdev' interface.<br />
<br />
It's also worth mentioning that there is also a xorg driver {{ic|xf86-input-joystick}}. It just allows you to control the mouse/keyboard in xorg using a joystick, for most people this will be undesirable. Disabling this behaviour is described below in [[#Disable Joystick From Controlling Mouse|Disable Joystick From Controlling Mouse]], in most cases you can just remove this package though.<br />
<br />
== Determining which modules you need ==<br />
<br />
Unless you're using very old joystick that uses gameport or proprietary USB protocol, you will need just the generic USB human interface device (HID) modules.<br />
<br />
For an extensive overview of all joystick related modules in Linux, you will need access to the Linux kernel sources -- specifically the Documentation section. Unfortunately, pacman kernel packages do not include what we need. If you have the kernel sources downloaded, have a look at {{ic|Documentation/input/joystick.txt}}. You can browse the kernel source tree at [https://kernel.org/ kernel.org] by clicking the "cgit" (git frontend) link for the kernel that you're using, then clicking the "tree" link near the top. Here's a link to the [https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/input/joystick.txt?id=refs/tags/v3.12.6 Documentation from kernel 3.12.6].<br />
<br />
Some joysticks need specific modules, such as the Microsoft Sidewinder controllers ({{ic|sidewinder}}), or the Logitech digital controllers ({{ic|adi}}). Many older joysticks will work with the simple {{ic|analog}} module. If your joystick is plugging in to a gameport provided by your soundcard, you will need your soundcard drivers loaded - however, some cards, like the Soundblaster Live, have a specific gameport driver ({{ic|emu10k1-gp}}). Older ISA soundcards may need the {{ic|ns558}} module, which is a standard gameport module.<br />
<br />
As you can see, there are many different modules related to getting your joystick working in Linux, so I couldn't possibly cover everything here. Please have a look at the documentation mentioned above for details.<br />
<br />
=== Loading the modules for analogue devices ===<br />
<br />
You need to load a module for your gameport ({{ic|ns558}}, {{ic|emu10k1-gp}}, {{ic|cs461x}}, etc...), a module for your joystick ({{ic|analog}}, {{ic|sidewinder}}, {{ic|adi}}, etc...), and finally the kernel joystick device driver ({{ic|joydev}}). Add these to a new file in {{ic|/etc/modules-load.d/}}, or simply modprobe them. The {{ic|gameport}} module should load automatically, as this is a dependency of the other modules.<br />
<br />
=== USB joysticks ===<br />
<br />
You need to get USB working, and then modprobe your joystick driver, which is {{ic|usbhid}}, as well as {{ic|joydev}}. <br />
If you use a usb mouse or keyboard, {{ic|usbhid}} will be loaded already and you just have to load the {{ic|joydev}} module.<br />
<br />
== Testing Your Configuration ==<br />
<br />
Once the modules are loaded, you should be able to find a new device: {{ic|/dev/input/js0}} and a file ending with {{ic|-event-joystick}} in {{ic|/dev/input/by-id}} directory. You can simply {{ic|cat}} those devices to see if the joystick works - move the stick around, press all the buttons - you should see mojibake printed when you move the sticks or press buttons.<br />
<br />
Both interfaces are also supported in wine and reported as separate devices. You can test them with {{ic|1=wine control joy.cpl}}.<br />
<br />
=== Joystick API ===<br />
There are a lot of applications that can test this old API, {{ic|jstest}} from the AUR {{AUR|joyutils}} package is the simplest one. If the output is unreadable because the line printed is too long you can also use graphical tools. KDE4 has a built in one in Input Devices panel in System Settings or the alternative AUR {{AUR|jstest-gtk-git}} application.<br />
<br />
Use of {{ic|jstest}} fairly simple, you just run {{ic|jstest /dev/input/js0}} and it will print a line with state of all the axes (normalised to {-32767,32767}) and buttons.<br />
<br />
After you start {{ic|jstest-gtk}}, it will just show you a list of joysticks available, you just need to select one and press Properties.<br />
<br />
=== evdev API ===<br />
<br />
The new 'evdev' API can be tested using the SDL2 joystick test application or using {{ic|evtest}} from community repository. Install {{AUR|sdl2-jstest-git}} and then run {{ic|sdl2-jstest --test 0}}. Use {{ic|sdl2-jstest --list}} to get IDs of other controllers if you have multiple ones connected.<br />
<br />
To test force feedback on the device, use {{ic|fftest}} from {{ic|linuxconsole}} package:<br />
fftest /dev/input/by-id/usb-*event-joystick<br />
<br />
==Setting up deadzones and calibration==<br />
If you want to set up the deadzones (or remove them completely) of your analog input you have to do it separately for the xorg (for mouse and keyboard emulation), Joystick API and evdev API.<br />
<br />
===Xorg deadzones===<br />
Add a similar line into your {{ic|/etc/X11/xorg.conf.d/50-joystick.conf}} before the {{ic|EndSection}}:<br />
Option "MapAxis1" "deadzone=1000"<br />
1000 is the default value, but you can set anything between 0 and 30 000. To get the axis number see the "Testing Your Configuration" section of this article.<br />
If you already have an option with a specific axis just type in the {{ic|1=deadzone=value}} at the end of the parameter separated by a space.<br />
<br />
===Joystick API deadzones===<br />
The easiest way is using {{ic|jstest-gtk}} from {{AUR|jstest-gtk-git}}. Select the controller you want to edit, then click the Calibration button at the bottom of the dialog ('''don't''' click Start Calibration there). You can then set the CenterMin and CenterMax values (which control the center deadzone), RangeMin and RangeMax which control the end of throw deadzones. Note that the calibration settings are applied when the application opens the device, so you need to restart your game or test application to see updated calibration settings.<br />
<br />
After you set the deadzones use {{ic|jscal}} to dump the new values into a shell script:<br />
jscal -p /dev/input/jsX > jscal.sh # replace X with your joystick's number <br />
chmod +x jscal.sh<br />
<br />
Now you need to make a [[udev]] rule (for example {{ic|/etc/udev/rules.d and name it 85-jscal.rules}}) so the script will automatically run when you connect the controller:<br />
SUBSYSTEM=="input", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="c268", ACTION=="add", RUN+="/usr/bin/jscal.sh"<br />
To get the idVendor and idProduct use {{ic|udevadm info --attribute-walk --name /dev/input/jsX}}<br />
<br />
Use the `/dev/input/by-id/*-joystick` device names in case you use multiple controllers.<br />
<br />
===evdev API deadzones===<br />
Currently there is no standalone application that allows changing calibration for {{ic|evdev}} API, but there is {{ic|G25manage}} distributed together with VDrift game that can change the center deadzone.<br />
<br />
The easiest way to get it is to go to VDrift [https://github.com/VDrift/vdrift/tree/master/tools/G25manage github], download all files in the folder and build them using {{ic|make}}.<br />
<br />
After that, you should be able to see your device configuration by using:<br />
./G25manage --showcalibration /dev/input/by-id/usb-*-event-joystick<br />
<br />
To change deadzones of any of the axes, you use the following command:<br />
./G25manage --evdev /dev/input/by-id/usb-*-event-joystick --axis 0 --deadzone 0<br />
<br />
Use udev rules file to set them automatically when the controller is connected.<br />
<br />
Note that inside the kernel, the value is called {{ic|flatness}} and is set using the {{ic|EVIOCSABS}} {{ic|ioctl}}.<br />
<br />
Default configuration will look like similar to this:<br />
./G25manage --showcalibration /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick <br />
Supported Absolute axes:<br />
Absolute axis 0x00 (0) (X Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x01 (1) (Y Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x05 (5) (Z Rate Axis) (min: 0, max: 4095, flatness: 255 (=6.23%), fuzz: 15)<br />
Absolute axis 0x10 (16) (Hat zero, x axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)<br />
Absolute axis 0x11 (17) (Hat zero, y axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)<br />
<br />
While a more reasonable setting would be achieved with something like this (repeat for other axes):<br />
./G25manage --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick --axis 0 --deadzone 512<br />
Event device file: /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick<br />
Axis index to deal with: 0<br />
New dead zone value: 512<br />
Trying to set axis 0 deadzone to: 512<br />
Absolute axis 0x00 (0) (X Axis) Setting deadzone value to : 512<br />
(min: 0, max: 65535, flatness: 512 (=0.78%), fuzz: 255)<br />
<br />
===Configuring curves and responsivness===<br />
In case your game requires just limited amount of buttons or has good support for multiple controllers, you may have good results with using {{ic|xboxdrv}} to change response curves of the joystick.<br />
<br />
Below are the setups I use for Saitek X-55 HOTAS:<br />
xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Throttle_G0000021-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_#40=x1,ABS_#41=y1,ABS_X=x2,ABS_Y=y2' --device-name 'Hat and throttle' \<br />
--ui-axismap 'x2^cal:-32000:0:32000=,y2^cal:-32000:0:32000=' --silent<br />
<br />
this maps the EV_ABS event with id of 40 and 41 (use xboxdrv with --evdev-debug to see the events registered), which is the normally inaccessible "mouse pointer" on the throttle, to first gamepad joystick and throttles to second joystick, it also clamps the top and lower ranges as they not always register fully.<br />
<br />
A bit more interesting is the setup for the stick:<br />
xboxdrv --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick \<br />
--evdev-no-grab --evdev-absmap 'ABS_X=x1' --evdev-absmap 'ABS_Y=y1' --device-name 'Joystick' \<br />
--ui-axismap 'x1^cal:-32537:-455:32561=,x1^dead:-900:700:1=,x1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--ui-axismap 'y1^cal:-32539:-177:32532=,y1^dead:-700:2500:1=,y1^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--evdev-absmap 'ABS_RZ=x2' --ui-axismap 'x2^cal:-32000:-100:32000,x2^dead:-1500:1000:1=,x2^resp:-32768:-21845:-2000:0:2000:21485:32767=' \<br />
--silent<br />
<br />
this maps the 3 joystick axes to gamepad axes and changes the calibration (min value, centre value, max value), dead zones (negative side, positive side, flag to turn smoothing) and finally change of response curve to a more flat one in the middle.<br />
<br />
You can also modify the responsiveness by setting the 'sen' (sensitivity). Setting it to value of 0 will give you a linear sensitivity, value of -1 will give very insensitive axis while value of 1 will give very sensitive axis. You can use intermediate values to make it less or more sensitive. Internally xboxdrv uses a quadratic formula to calculate the resulting value, so this setting gives a more smooth result than 'resp' shown above.<br />
<br />
Nice thing about xboxdrv is that it exports resulting device as both old Joystick API and new style evdev API so it should be compatible with basically any application.<br />
<br />
== Disable Joystick From Controlling Mouse ==<br />
If you want to play games with your controller, you might want to disable joystick control over mouse cursor. To do this, edit /etc/X11/xorg.conf.d/50-joystick.conf so that it looks like this:<br />
{{hc|/etc/X11/xorg.conf.d/50-joystick.conf |<br />
Section "InputClass"<br />
Identifier "joystick catchall"<br />
MatchIsJoystick "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "joystick"<br />
Option "StartKeysEnabled" "False" #Disable mouse<br />
Option "StartMouseEnabled" "False" #support<br />
EndSection}}<br />
<br />
== Using Joystick to send keystrokes ==<br />
<br />
A couple joystick to keystroke programs exist like {{AUR|rejoystick}}, {{AUR|qjoypad}} or {{AUR|antimicro-qt4}}, all work well without the need for X.org configuration.<br />
<br />
=== via X.org ===<br />
<br />
This is a good solution for systems where restarting Xorg is a rare event because it's a static configuration loaded only on X startup. I use it on my media PC running XBMC controlled with Logitech Cordless RumblePad 2. Due to a problem with the d-pad (a.k.a. "hat") being recognized as another axis, I used to run [[Joy2key]] as a workaround. Since I upgraded to XBMC 11.0 and joy2key 1.6.3-1, this setup no longer worked for me. I ended up taking a more direct approach and let Xorg handle joystick events.<br />
<br />
First, make sure you have {{Pkg|xf86-input-joystick}} installed. Then, create {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} like so:<br />
{{bc|<nowiki><br />
Section "InputClass"<br />
Identifier "Joystick hat mapping"<br />
Option "StartKeysEnabled" "True"<br />
#MatchIsJoystick "on"<br />
Option "MapAxis5" "keylow=113 keyhigh=114"<br />
Option "MapAxis6" "keylow=111 keyhigh=116"<br />
EndSection<br />
</nowiki>}}<br />
{{Note|The ''MatchIsJoystick "on"'' line doesn't seem to be required for this to work but you may want to uncomment it.}}<br />
<br />
<br />
== Specific devices ==<br />
<br />
While most joysticks, especially USB based ones should just work, some may require (or give better results) if you use alternative drivers. If it doesn't work the first time, do not give up, and read those docs thoroughly!<br />
<br />
=== Logitech Thunderpad Digital ===<br />
Logitech Thunderpad Digital won't show all the buttons if you use the {{ic|analog}} module. Use the device specific {{ic|adi}} module for this controller.<br />
<br />
=== PS3 controller ===<br />
<br />
The Sixaxis gamepad works out of the box when plugged in via USB (the PS button will need to be pushed to begin), force feedback is backed since kernel 3.14.<br />
<br />
Steam properly recognizes it as a PS3 pad and Big Picture can be launched with the PS button. Big Picture and some games may act as if it was a 360 controller. Gamepad control over mouse is on by default. You may want to turn it off before playing games, see below.<br />
<br />
=== Xbox 360 controllers ===<br />
<br />
The controllers should work without additional packages, but the wireless controller needs a wireless receiver (the charge-and-play cable can not be used for communicating with the controller). Both the wired controllers and the wireless receiver is supported by the {{ic|xpad}} kernel module.<br />
<br />
By default, the device associated with a controller (e.g., {{ic|/dev/input/event14}}) will be owned {{ic|root}}, part of the {{ic|root}} group and will only allow its owner to read or write to it (i.e., {{ic|600}}). As a result, applications will not be able to use the controller unless they are run with superuser privileges. To amend this, create the following {{ic|udev}} rule.<br />
<br />
{{hc|/etc/udev/rules.d/50-event.rules|<nowiki><br />
KERNEL=="event*", GROUP="games", MODE="660"<br />
</nowiki>}}<br />
<br />
This {{ic|udev}} rule allows users that are a member the {{ic|games}} group to use controllers.<br />
<br />
Unfortunately, the default xpad driver has several issues with newer wired and wireless controllers:<br />
* incorrect button mapping. ([https://github.com/ValveSoftware/steam-for-linux/issues/95#issuecomment-14009081 discussion in Steam bugtracker])<br />
* not-working sync. All four leds keep blinking, but controller works. ([https://bbs.archlinux.org/viewtopic.php?id=156028 discussion in Arch Forum])<br />
The working solutions are using {{AUR|xboxdrv}}, that is an alternative driver which works in userspace and could be launched as system service or using the [[Wikipedia:SteamOS]] patched version of xpad ({{AUR|steamos-xpad-dkms}}), that fixes those issues.<br />
<br />
If you wish to use the controller for controlling the mouse, or mapping buttons to keys, etc. you should use the {{ic|xf86-input-joystick}} package (configuration help can be found using {{ic|man joystick}}). If the mouse locks itself in a corner, it might help changing the {{ic|MatchDevicePath}} in {{ic|/etc/X11/xorg.conf.d/50-joystick.conf}} from {{ic|/dev/input/event*}} to {{ic|/dev/input/js*}}.<br />
<br />
{{Tip|If you use the [[TLP]] power management daemon, you may experience connection issues with your Microsoft wireless adapter (e.g. the indicator LED will go out after the adapter has been connected for a few seconds, and controller connection attempts fail). This is due to TLP's USB autosuspend functionality, and the solution is to either disable the functionality entirely, or to add the Microsoft wireless adapter's device ID to this feature's blacklist (check [http://linrunner.de/en/tlp/docs/tlp-configuration.html#usb TLP configuration] for more details).}}<br />
<br />
==== SteamOS xpad ====<br />
<br />
If you have issues with the default {{ic|xpad}} kernel module, you can install the SteamOS version, available in [[AUR]] {{AUR|steamos-xpad-dkms}}.<br />
<br />
Before installing it, make sure you have [[DKMS]] installed and running.<br />
<br />
Then, install the modified kernel module {{AUR|steamos-xpad-dkms}} from the [[AUR]], during the installation you'll see that new xpad kernel module is strapped to your current kernel:<br />
<br />
Creating symlink /var/lib/dkms/steamos-xpad-dkms/0.1/source -&gt;<br />
/usr/src/steamos-xpad-dkms-0.1<br />
<br />
DKMS: add completed.<br />
<br />
Kernel preparation unnecessary for this kernel. Skipping...<br />
<br />
Building module:<br />
cleaning build area....<br />
make KERNELRELEASE=3.12.8-1-ARCH KVERSION=3.12.8-1-ARCH....<br />
cleaning build area....<br />
<br />
Now, only a reboot is needed to make this work.<br />
<br />
An alternative to rebooting is unloading the old xpad module, then loading new one:<br />
<br />
rmmod xpad<br />
modprobe steamos-xpad<br />
<br />
==== xboxdrv with two controllers ====<br />
<br />
xboxdrv supports a multitude of controllers, but it works only in [http://pingus.seul.org/~grumbel/xboxdrv/xboxdrv.html#idp147464 daemon mode].<br />
The simplest way is launch xboxdrv as service in daemon mode:<br />
ExecStart = /usr/bin/xboxdrv -D -c /etc/conf.d/xboxdrv<br />
And add support of the second controller in config file:<br />
<br />
{{bc|<nowiki><br />
[xboxdrv]<br />
silent = true<br />
next-controller = true<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
</nowiki>}}<br />
<br />
==== xboxdrv with systemd and 4 controllers ====<br />
<br />
Newer versions of xboxdrv have actually made things extremely simple. After installing the package from AUR, you can simply [[enable]] {{ic|xboxdrv.service}}.<br />
<br />
Then you must edit the configuration file /etc/default/xboxdrv:<br />
<br />
{{bc|<nowiki><br />
[xboxdrv]<br />
silent = true<br />
next-controller = true<br />
next-controller = true<br />
next-controller = true<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
</nowiki>}}<br />
<br />
==== Mimic Xbox 360 controller with other controllers ====<br />
<br />
xboxdrv can be used to make any controller register as an Xbox 360 controller with the {{ic|--mimic-xpad}} switch. This may be desirable for games that support Xbox 360 controllers out of the box, but have trouble detecting or working with other gamepads.<br />
<br />
First, you need to find out what each button and axis on the controller is called. You can use {{Pkg|evtest}} for this. Run {{ic|evtest}} and select the device event ID number ({{ic|/dev/input/event*}}) that corresponds to your controller. Press the buttons on the controller and move the axes to read the names of each button and axis.<br />
<br />
Here is an example of the output:<br />
{{bc|<nowiki><br />
<br />
Event: time 1380985017.964843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985017.964843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 1<br />
Event: time 1380985017.964843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.076843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985018.076843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 0<br />
Event: time 1380985018.076843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.460841, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.460841, type 1 (EV_KEY), code 289 (BTN_THUMB), value 1<br />
Event: time 1380985018.460841, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.572835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.572835, type 1 (EV_KEY), code 289 (BTN_THUMB), value 0<br />
Event: time 1380985018.572835, -------------- SYN_REPORT ------------<br />
Event: time 1380985019.980824, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985019.980824, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 1<br />
Event: time 1380985019.980824, -------------- SYN_REPORT ------------<br />
Event: time 1380985020.092835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985020.092835, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 0<br />
Event: time 1380985020.092835, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.596806, type 3 (EV_ABS), code 3 (ABS_RX), value 18<br />
Event: time 1380985023.596806, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.612811, type 3 (EV_ABS), code 3 (ABS_RX), value 0<br />
Event: time 1380985023.612811, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.708768, type 3 (EV_ABS), code 3 (ABS_RX), value 14<br />
Event: time 1380985023.708768, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.724772, type 3 (EV_ABS), code 3 (ABS_RX), value 128<br />
Event: time 1380985023.724772, -------------- SYN_REPORT ------------<br />
</nowiki>}}<br />
<br />
In this case, {{ic|BTN_THUMB}}, {{ic|BTN_THUMB2}} and {{ic|BTN_PINKIE}} are buttons and {{ic|ABS_RX}} is the X axis of the right analogue stick.<br />
You can now mimic an Xbox 360 controller with the following command:<br />
<br />
$ xboxdrv --evdev /dev/input/event* --evdev-absmap ABS_RX=X2 --evdev-keymap BTN_THUMB2=a,BTN_THUMB=b,BTN_PINKIE=rt --mimic-xpad<br />
<br />
The above example is incomplete. It only maps one axis and 3 buttons for demonstration purposes. Use {{ic|xboxdrv --help-button}} to see the names of the Xbox controller buttons and axes and bind them accordingly by expanding the command above. Axes mappings should go after {{ic|--evdev--absmap}} and button mappings follow {{ic|--evdev-keymap}} (comma separated list; no spaces).<br />
<br />
By default, xboxdrv outputs all events to the terminal. You can use this to test that the mappings are correct. Append the {{ic|--silent}} option to keep it quiet.<br />
<br />
=====Playstation 3 Controllers via USB=====<br />
<br />
If you own a PS3 controller and can connect with USB, xboxdrv has the mappings built in. Just run the program (and detach the running driver) and it works! <br />
<br />
# xboxdrv --silent --detach-kernel-driver<br />
<br />
=====Playstation 3 Controllers via Bluetooth=====<br />
<br />
{{Note|{{Pkg|bluez-plugins}} includes a sixaxis plugin that should replace the need for {{AUR|sixpair}}. Simply [[start]] {{ic|bluetooth.service}}, plug the controller in via USB, and the plugin should program your PC's bluetooth address into the controller automatically.}}<br />
<br />
To make the Playstation 3 controller work over bluetooth you will need to install the {{AUR|sixpair}} utility.<br />
<br />
After installing sixpair connect your controller with an USB cable and run sixpair<br />
<br />
# sixpair<br />
<br />
Disconnect your controller from USB and wait about 5 minutes (not sure if really needed)<br />
<br />
Now you will need to pair it with bluez. You will need {{Pkg|bluez-utils}} and {{Pkg|bluez-plugins}} packages.<br />
<br />
Disable all bluetooth utilities (like bluedevil or bluemon)<br />
<br />
Run the bluetoothctl utility<br />
<br />
# bluetoothctl<br />
<br />
A bluetooth prompt will appear.<br />
<br />
Press the playstation button and watch for connection and disconnection messages and copy the device address (something like 38:C0:96:56:4D:AA)<br />
<br />
Wait for the lights stop blinking.<br />
<br />
Now, type the following:<br />
<br />
agent on<br />
default-agent<br />
discoverable on<br />
pairable on<br />
<br />
Hit the playstation button again and while it blinks type the following<br />
<br />
connect <device_addr><br />
<br />
Keep trying this command if you see device not available (it will loop between connected and disconnected) until you see something like the following<br />
<br />
I usually keep pressing up + enter (repeating the last command)<br />
<br />
[CHG] Device <device_addr> Modalias: usb:v054Cp0268d0100<br />
[CHG] Device <device_addr> UUIDs:<br />
00001124-0000-1000-8000-00805f9b34fb<br />
00001200-0000-1000-8000-00805f9b34fb<br />
<br />
Now trust the device<br />
<br />
trust <device_addr><br />
<br />
You're done<br />
<br />
Next time you hit the Playstation button it will connect without asking anything else.<br />
<br />
You can also re-enable your bluetooth applets/monitors.<br />
<br />
Just remind to disconnect the device once you are done, once it will stay connected, on and consuming battery.<br />
<br />
If you intend to use the xboxdrv to emulate the xbox360 controller its best to create a udev rule for it<br />
<br />
=====Creating the udev rule=====<br />
<br />
Create a new udev rule with the following content:<br />
<br />
{{hc<br />
|head=/etc/udev/rules.d/99-dualshock.rules<br />
|output=KERNEL=="event*", SUBSYSTEM=="input", ATTRS{uniq}=="<device_addr_you_got_on_pairing>", SYMLINK+="input/dualshock3"<br />
}}<br />
<br />
The address must be in lowercase, like {{ic|06:9a:b4:c8:ef:8b}}.<br />
<br />
Now run xboxdrv over the new device:<br />
<br />
xboxdrv --evdev /dev/input/dualshock3 --mimic-xpad<br />
<br />
If the mimic-xpad does not work, use the [https://github.com/Grumbel/xboxdrv/blob/master/examples/playstation3.xboxdrv configuration file provided by xboxdrv], adding the following in the {{ic|xboxdrv}} section:<br />
<br />
mimic-xpad = true<br />
<br />
…and replacing the evdev line by:<br />
<br />
evdev = /dev/input/dualshock3 ''(or whatever other name you gave in the udev_rule)''<br />
<br />
Now, just run xboxdrv:<br />
<br />
# xboxdrv -c config_file<br />
<br />
Have tons of fun.<br />
<br />
=====Playstation 2 Adapter=====<br />
<br />
To fix the button mapping of PS2 dual adapters and mimic the Xbox controller you can run the following command:<br />
<br />
sudo xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TOP=x,BTN_TRIGGER=y,BTN_THUMB2=a,BTN_THUMB=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lb,BTN_BASE2=rb,BTN_TOP2=lt,BTN_PINKIE=rt,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
=====Logitech Dual Action=====<br />
<br />
The Logitech Dual Action gamepad has a very similar mapping to the PS2 pad, but some buttons and triggers need to be swapped to mimic the Xbox controller.<br />
<br />
sudo xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TRIGGER=x,BTN_TOP=y,BTN_THUMB=a,BTN_THUMB2=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lt,BTN_BASE2=rt,BTN_TOP2=lb,BTN_PINKIE=rb,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
=====Playstation 4 controller=====<br />
<br />
To fix the button mapping of PS4 controller you can use the following script with xboxdrv or try with the [https://github.com/chrippa/ds4drv ds4drv] program:<br />
<br />
#!/bin/bash <br />
sudo xboxdrv \ <br />
--evdev /dev/input/by-id/usb-Sony_Computer_Entertainment_Wireless_Controller-event-joys><br />
--evdev-absmap ABS_X=x1,ABS_Y=y1 \ <br />
--evdev-absmap ABS_Z=x2,ABS_RZ=y2 \ <br />
--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \ <br />
--evdev-keymap BTN_A=x,BTN_B=a \ <br />
--evdev-keymap BTN_C=b,BTN_X=y \ <br />
--evdev-keymap BTN_Y=lb,BTN_Z=rb \ <br />
--evdev-keymap BTN_TL=lt,BTN_TR=rt \<br />
--evdev-keymap BTN_SELECT=tl,BTN_START=tr \ <br />
--evdev-keymap BTN_TL2=back,BTN_TR2=start \ <br />
--evdev-keymap BTN_MODE=guide \ <br />
--axismap -y1=y1,-y2=y2 \ <br />
--mimic-xpad \ <br />
--silent \ <br />
"$@"<br />
<br />
=== Nintendo Gamecube Controller ===<br />
<br />
Dolphin Emulator has a [https://wiki.dolphin-emu.org/index.php?title=How_to_use_the_Official_GameCube_Controller_Adapter_for_Wii_U_in_Dolphin page on their wiki] that explains how to use the official Nitendo USB adapter with a Gamecube controller. This configuration also works with the Mayflash Controller Adapter if the switch is set to "Wii U".<br />
<br />
By default, the controller will register with [[udev]], but will only be readable by the root user. You can fix this by adding a udev device rule, like the below. <br />
<br />
{{hc<br />
|head=/etc/udev/rules.d/51-gcadapter.rules<br />
|output=<nowiki>SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="0337", MODE="0666"</nowiki><br />
}}<br />
<br />
This only matches the USB device with the specified vendor and product IDs, which match those of the official USB adapter. It sets the permissions of the device file to 0666 so that programs that aren't running as root can read the device's input. <br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
== Troubleshooting ==<br />
<br />
=== Joystick moving mouse ===<br />
<br />
Sometimes USB joystick can be recognized as HID mouse (only in X, it is still being installed as {{ic|/dev/input/js0}} as well). Known issue is cursor being moved by the joystick, or escaping to en edge of a screen right after plugin. If your application can detect joystick by it self, you can remove xf86-input-joystick package.<br />
<br />
More gentle solution is to [[#Disable Joystick From Controlling Mouse|Disable Joystick From Controlling Mouse]].<br />
<br />
=== Joystick not recognized by all programs ===<br />
<br />
Some software, Steam for example, will only recognize the first joystick it encounters. Due to a bug in the driver for Microsoft wireless periphery devices this can in fact be the bluetooth dongle. If you find you have a {{ic|/dev/input/js*}} and {{ic|/dev/input/event*}} belonging to you keyboard's bluetooth transceiver you can get automatically get rid of it by creating according udev rules.<br />
Create a {{ic|/}}:<br />
{{hc|/etc/udev/rules.d/99-btcleanup.rules|<nowiki><br />
ACTION=="add", KERNEL=="js[0-9]*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/js%n"<br />
ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/event%n"<br />
</nowiki>}}<br />
Correct the {{ic|<nowiki>KERNELS=="..."</nowiki>}} to match your device. The correct value can be found by running<br />
<br />
# udevadm info -an /dev/input/js0<br />
<br />
Assuming the device in question is {{ic|/dev/input/js0}}. After you placed the rule reload the rules with<br />
<br />
# udevadm control --reload<br />
<br />
Then replug the device making you trouble. The joystick and event devices should be gone, although their number will still be reserved. But the files are out of the way.</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=GPGPU&diff=361360GPGPU2015-02-16T04:45:38Z<p>Siddharthist: /* Language bindings */ Added Racket language binding information</p>
<hr />
<div>[[Category:Development]]<br />
[[Category:Graphics]]<br />
[[ja:GPGPU]]<br />
{{Out of date|With new versions of OpenCL, the things have changed a little bit.}}<br />
{{Related articles start}}<br />
{{Related|Catalyst}}<br />
{{Related|Nvidia}}<br />
{{Related articles end}}<br />
<br />
GPGPU stands for [http://en.wikipedia.org/wiki/Gpgpu General-purpose computing on graphics processing units].<br />
In Linux, there are currently two major GPGPU frameworks: [http://en.wikipedia.org/wiki/OpenCL OpenCL] and [http://en.wikipedia.org/wiki/CUDA CUDA]<br><br><br />
<br />
==OpenCL==<br />
===Overview===<br />
OpenCL (Open Computing Language) is an open, royalty-free parallel programming framework developed by the Khronos Group, a non-profit consortium.<br />
<br />
Distribution of the OpenCL framework generally consists of:<br />
* Library providing OpenCL API, known as libCL or libOpenCL ({{ic|libOpenCL.so}} in linux)<br />
* OpenCL implementation(s), which contain:<br />
** Device drivers<br />
** OpenCL/C code compiler<br />
** SDK *<br />
* Header files *<br />
''* only needed for development''<br />
<br />
===OpenCL library===<br />
There are several choices for the libCL. In general case, installing {{Pkg|libcl}} from the [[official repositories]] should do.<br />
<br />
However, there are situations when another libCL distribution is more suitable. The following paragraph covers this more advanced topic.<br />
<br />
===The OpenCL ICD model===<br />
OpenCL offers the option to install multiple vendor-specific implementations on the same machine at the same time.<br />
In practice, this is implemented using the Installable Client Driver (ICD) model.<br />
The center point of this model is the libCL library which in fact imeplements ICD Loader.<br />
Through the ICD Loader, an OpenCL application is able to access all platforms and all devices present in the system.<br />
<br />
Although itself vendor-agnostic, the ICD Loader still has to be provided by someone. In Arch Linux, there are currently two options:<br />
* {{Pkg|libcl}} by Nvidia. Provides OpenCL version 1.0 (even in the current version) and is thus slightly outdated. Its behaviour with OpenCL 1.1 code has not been tested as of yet.<br />
* {{AUR|libopencl}} by AMD. Provides up to date version 1.1 of OpenCL. It is currently distributed by AMD under a restrictive license and therefore could not have been pushed into official repo.<br />
<br />
(There is also Intel's libCL, this one is currently not provided in a separate package though.)<br />
<br />
{{Note|ICD Loader's vendor is mentioned only to identify each loader, it is otherwise completely irrelevant. ICD Loaders are vendor-agnostic and may be used interchangeably. (as long as they are implemented correctly)}}<br />
<br />
For basic usage, ''libcl'' is recommended as its installation and updating is convenient. For advanced usage, ''libopencl'' is recommended. Both ''libcl'' and ''libopencl'' should still work with all the implementations.<br />
<br />
===Implementations===<br />
To see which OpenCL implementations are currently active on your system, use the following command:<br />
$ ls /etc/OpenCL/vendors<br />
<br />
====AMD====<br />
OpenCL implementation from AMD is known as [http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx AMD APP SDK], formerly also known as AMD Stream SDK or ATi Stream.<br />
<br />
For Arch Linux, AMD APP SDK is currently available in AUR as {{AUR|amdapp-sdk}}.<br />
This package is installed as {{ic|/opt/AMDAPP}} and apart from SDK files it also contains a number of code samples ({{ic|/opt/AMDAPP/SDK/samples/}}). It also provides the {{ic|clinfo}} utility which lists OpenCL platforms and devices present in the system and displays detailed information about them.<br />
<br />
As AMD APP SDK itself contains CPU OpenCL driver, no extra driver is needed to use execute OpenCL on CPU devices (regardless of its vendor). GPU OpenCL drivers are provided by the {{AUR|catalyst}} package (an optional dependency), the open-source driver ({{Pkg|xf86-video-ati}}) does ''not'' support OpenCL.<br />
<br />
Code is compiled using {{Pkg|llvm}} (dependency).<br />
<br />
====Mesa (Gallium)====<br />
OpenCL support from Mesa is in development (see http://www.x.org/wiki/GalliumStatus/). AMD Radeon cards are supported by the r600g driver.<br />
<br />
Arch Linux does currently (April 2014; Mesa 10.1.0; LLVM 3.4) not build Mesa with OpenCL support. See http://dri.freedesktop.org/wiki/GalliumCompute/ for installation instructions (use the development branches of LLVM and Mesa for optimal results).<br />
<br />
You could also use [http://pkgbuild.com/~lcarlier/mesa-git/ lordheavy's repo]. Install these packages:<br />
* ati-dri-git<br />
* opencl-mesa-git<br />
* libclc-git<br />
<br />
Surprisingly, pyrit performs 20% better with radeon+r600g compared to Catalyst 13.11 Beta1 (tested with 7 other CPU cores):<br />
{{bc|<nowiki>catalyst #1: 'OpenCL-Device 'Barts'': 21840.7 PMKs/s (RTT 2.8)<br />
radeon+r600g #1: 'OpenCL-Device 'AMD BARTS'': 26608.1 PMKs/s (RTT 3.0)</nowiki>}}<br />
At the time of this writing (30 October 2013), one must apply patches [http://people.freedesktop.org/~tstellar/pyrit-perf/0001-XXX-clover-Calculate-the-optimal-work-group-size.patch] and [http://people.freedesktop.org/~tstellar/pyrit-perf/0001-radeon-llvm-Specify-the-DataLayout-when-running-opti.patch] on top of Mesa commit ac81b6f2be8779022e8641984b09118b57263128 to get this performance improvement. The latest unpatched LLVM trunk was used (SVN rev 193660).<br />
<br />
====Nvidia====<br />
The Nvidia implementation is available as {{Pkg|opencl-nvidia}} from the [[official repositories]]. It only supports Nvidia GPUs running the {{Pkg|nvidia}} kernel module (nouveau does not support OpenCL yet).<br />
<br />
====Intel====<br />
The Intel implementation, named simply [http://software.intel.com/en-us/articles/opencl-sdk/ Intel OpenCL SDK], <br />
provides optimized OpenCL performance on Intel CPUs (mainly Core and Xeon) and CPUs only. Package is available in the [[AUR]]: {{AUR|intel-opencl-sdk}}. The runtime [[AUR]]: {{AUR|intel-opencl-runtime}} is a separated package. OpenCL for integrated graphics hardware is available in the AUR through {{AUR|beignet}} for Ivy Bridge and newer hardware.<br />
<br />
===Development===<br />
For development of OpenCL-capable applications, full installation of the OpenCL framework including implementation, drivers and compiler plus the {{Pkg|opencl-headers}} package is needed. Link your code against {{ic|libOpenCL}}.<br />
<br />
====Language bindings====<br />
* '''C++''': A binding by Khronos is part of the official specs. It is included in {{Pkg|opencl-headers}}<br />
* '''C++/Qt''': An experimental binding named [http://qt.gitorious.org/qt-labs/opencl QtOpenCL] is in Qt Labs - see [http://labs.qt.nokia.com/2010/04/07/using-opencl-with-qt/ Blog entry] for more information<br />
* '''JavaScript/HTML5''': [http://www.khronos.org/webcl/ WebCL]<br />
* '''[[Python]]''': There are two bindings with the same name: PyOpenCL. One is in [extra]: {{Pkg|python2-pyopencl}}, for the other one see [http://sourceforge.net/projects/pyopencl/ sourceforge]<br />
* '''[[D]]''': [https://bitbucket.org/trass3r/cl4d/wiki/Home cl4d]<br />
* '''Haskell''': The OpenCLRaw package is available in AUR: {{AUR|haskell-openclraw-git}}<br />
* '''[[Java]]''': [http://jogamp.org/jocl/www/ JOCL] (a part of [http://jogamp.org/ JogAmp])<br />
* '''[[Mono|Mono/.NET]]''': [http://sourceforge.net/projects/opentk/ Open Toolkit]<br />
* '''[[Go]]''': [https://github.com/samuel/go-opencl OpenCL bindings for Go]<br />
* '''Racket''': Racket has a native interface [http://planet.racket-lang.org/display.ss?owner=jaymccarthy&package=opencl.plt on PLaneT] that can be installed via raco.<br />
<br />
==CUDA==<br />
<br />
CUDA (Compute Unified Device Architecture) is [[Nvidia]]'s proprietary, closed-source parallel computing architecture and framework. It requires a Nvidia GPU. It consists of several components:<br />
* required:<br />
** proprietary Nvidia kernel module<br />
** CUDA "driver" and "runtime" libraries<br />
* optional:<br />
** additional libraries: CUBLAS, CUFFT, CUSPARSE, etc.<br />
** CUDA toolkit, including the {{ic|nvcc}} compiler<br />
** CUDA SDK, which contains many code samples and examples of CUDA and OpenCL programs<br />
<br />
The kernel module and CUDA "driver" library are shipped in {{Pkg|nvidia}} and {{Pkg|opencl-nvidia}}. The "runtime" library and the rest of the CUDA toolkit are available in {{Pkg|cuda}}. The library is available [https://projects.archlinux.org/svntogit/community.git/commit/trunk?h=packages/cuda&id=1b62c8bcb9194b2de1b750bd62a8dce1e7e549f5 only in 64-bit version].<br />
<br />
===Development===<br />
<br />
The {{Pkg|cuda}} package installs all components in the directory {{ic|/opt/cuda}}. For compiling CUDA code, add {{ic|/opt/cuda/include}} to your include path in the compiler instructions. For example this can be accomplished by adding {{ic|-I/opt/cuda/include}} to the compiler flags/options.<br />
<br />
===Language bindings===<br />
* '''Fortran''': [http://www.hoopoe-cloud.com/Solutions/Fortran/Default.aspx FORTRAN CUDA], [http://www.pgroup.com/resources/cudafortran.htm PGI CUDA Fortran Compiler]<br />
* '''[[Haskell]]''': [http://hackage.haskell.org/package/accelerate The accelerate package] lists available CUDA backends <br />
* '''[[Java]]''': [http://www.hoopoe-cloud.com/Solutions/jCUDA/Default.aspx jCUDA], [http://www.jcuda.org/jcuda/JCuda.html JCuda]<br />
* '''[[Mathematica]]''': [http://reference.wolfram.com/mathematica/CUDALink/tutorial/Overview.html CUDAlink]<br />
* '''[[Mono|Mono/.NET]]''': [http://www.hoopoe-cloud.com/Solutions/CUDA.NET/Default.aspx CUDA.NET], [http://www.hybriddsp.com/ CUDAfy.NET]<br />
* '''Perl''': [http://psilambda.com/download/kappa-for-perl Kappa], [https://github.com/run4flat/perl-CUDA-Minimal CUDA-Minimal]<br />
* '''[[Python]]''': In AUR: {{AUR|pycuda-git}}, also [http://psilambda.com/download/kappa-for-python Kappa]<br />
* '''[[Ruby]]''', '''Lua''': [http://psilambda.com/products/kappa/ Kappa]<br />
<br />
===Driver issues===<br />
<br />
It might be necessary to use the legacy driver {{Pkg|nvidia-304xx}} or {{Pkg|nvidia-304xx-lts}} to resolve permissions issues when running CUDA programs on systems with multiple GPUs.<br />
<br />
==List of OpenCL and CUDA accelerated software==<br />
{{Expansion}}<br />
* [[Bitcoin]]<br />
* [[GIMP]] (experimental - see [http://www.h-online.com/open/news/item/GIMP-2-8-RC-1-arrives-with-GPU-acceleration-1518417.html])<br />
* {{AUR|pyrit}}<br />
* {{Pkg|aircrack-ng}}<br />
* {{AUR|john-opencl}}<br />
* {{AUR|cuda_memtest}} - a GPU memtest. Despite its name, is supports both CUDA and OpenCL<br />
<br />
==Links and references==<br />
* [http://www.khronos.org/opencl/ OpenCL official homepage]<br />
* [http://www.nvidia.com/object/cuda_home_new.html CUDA official homepage]<br />
* [http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt The ICD extension specification]<br />
* [http://developer.amd.com/sdks/AMDAPPSDK/Pages/default.aspx AMD APP SDK homepage]<br />
* [http://developer.nvidia.com/cuda-toolkit-40 CUDA Toolkit homepage]<br />
* [http://software.intel.com/en-us/articles/opencl-sdk/ Intel OpenCL SDK homepage]</div>Siddharthisthttps://wiki.archlinux.org/index.php?title=WeeChat&diff=355966WeeChat2015-01-09T06:22:09Z<p>Siddharthist: /* Running WeeChat */ Fixed grammar: "has a Ncurses interface the command" -> "has an Ncurses interface. The command"</p>
<hr />
<div>[[Category:Internet Relay Chat]]<br />
{{Related articles start}}<br />
{{Related|irssi}}<br />
{{Related|HexChat}}<br />
{{Related articles end}}<br />
'''WeeChat''' is a highly extendable and feature rich IRC Client currently under heavy development.<br />
<br />
== Installing ==<br />
<br />
[[pacman|Install]] {{Pkg|weechat}} from the [[official repositories]]. The development version {{AUR|weechat-git}} is available in the [[AUR]].<br />
<br />
== Running WeeChat==<br />
<br />
WeeChat is going to have multiple interfaces at some point, run '''weechat-[interface]''' to start WeeChat. <br />
<br />
As WeeChat currently only has an Ncurses interface. The command to start WeeChat is:<br />
<br />
$ weechat-curses<br />
<br />
== Configuration ==<br />
<br />
You can configure WeeChat in 3 ways: using WeeChat's internal commands; using '''iset'''; or by editing the .conf files directly. WeeChat will automatically save settings on exit or when you run {{ic|/save}}, so if you are editing a .conf file in an editor, be sure to run {{ic|/reload}} from the console before exiting, otherwise your changes will be lost.<br />
<br />
=== Internal commands ===<br />
<br />
You can get a list of all configurable options by typing {{ic|/set}} in the '''weechat''' buffer window. Since there are nearly 600 default configurable options, you can search through them with a wildcard syntax: {{ic|/set irc.server.*}} or {{ic|/set *server*}} as an example. You can get help on each option with the {{ic|/help}} command: <br />
<br />
/help irc.server.freenode.autoconnect<br />
<br />
=== Internal menu-based ===<br />
<br />
For a more convenient method, install the '''iset''' script. If you have weechat 0.3.9, run:<br />
<br />
/script install iset.pl<br />
<br />
In older versions, use {{ic|/weeget install iset}}, or download [http://www.weechat.org/scripts/source/stable/iset.pl.html/ iset.pl] into your {{ic|~/.weechat/perl/autoload}} directory manually.<br />
<br />
Afterwards, run<br />
<br />
/iset<br />
<br />
to get a buffer with all configuration options.<br />
<br />
=== Configuration Files ===<br />
<br />
The .conf files for WeeChat are saved to {{ic|~/.weechat}}. These files are not commented. Detailed information can be found within the program itself (see '''Internally''' above), or WeeChat's [http://www.weechat.org/files/doc/stable/weechat_user.en.html user guide].<br />
<br />
== Connecting to a server ==<br />
<br />
You can connect to a IRC server by using '''/connect'''.<br />
<br />
/connect chat.freenode.net<br />
<br />
Or if there is already a '''Server''' setup you can use:<br />
<br />
/connect freenode<br />
<br />
== Creating a Server profile ==<br />
<br />
If you plan on connecting to a server more than once it may be beneficial to create a '''Server'''.<br />
<br />
/server add example irc.example.net/6667<br />
<br />
Would create the server '''example''' which would connect to '''irc.example.net''' on port '''6667'''<br />
<br />
See the WeeChat documentation and '''/help server''' for more information.<br />
<br />
== Configuring SSL ==<br />
<br />
Many IRC servers, including [https://freenode.net/ freenode] where [[IRC Channel|#archlinux]] is, support SSL.<br />
<br />
If you're making a server with '''/server''', add the SSL port (usually 6697) and '''-ssl''' to the end of the line. For example:<br />
<br />
/server add freenode chat.freenode.net/6697 -ssl<br />
<br />
You can do the same thing if using '''/connect'''.<br />
<br />
/connect chat.freenode.net/6697 -ssl<br />
<br />
{{Warning|Some servers need the '''ssl_dhkey_size''' value changed to something lower. For example, if you're using freenode you'll need to set '''/set irc.server.freenode.ssl_dhkey_size 1024''' or '''/set irc.server.chat.freenode.net.ssl_dhkey_size 1024''' (see the server log)}}<br />
<br />
{{Note|Different servers may have a different port than 6697 - this is server specific.}}<br />
<br />
You may also want to change the location where WeeChat looks for trusted authorities (the default value is {{ic|%h/ssl/CAs.pem}} which translates to {{ic|~/.weechat/ssl/CAs.pem)}}:<br />
<br />
/set weechat.network.gnutls_ca_file "/etc/ssl/certs/ca-certificates.crt"<br />
<br />
== Tips and Tricks ==<br />
<br />
=== Upgrading ===<br />
<br />
WeeChat can be upgraded without disconnecting from the IRC servers (non-SSL connections only):<br />
<br />
/upgrade<br />
<br />
This will load the new WeeChat binary and reload the current configuration.<br />
<br />
=== Aliases ===<br />
<br />
Aliases can be created to simplify commonly executed commands. A nice example is Wraithan's '''smart filter''' alias:<br />
<br />
'''Smart Filter'''<br />
<br />
First, we need to enable smart filters:<br />
<br />
/set irc.look.smart_filter "on"<br />
<br />
Next, we will create the '''sfilter''' alias:<br />
<br />
/alias sfilter filter add irc_smart_$server_$channel irc.$server.$channel irc_smart_filter *<br />
<br />
We can now type<br />
<br />
/sfilter<br />
<br />
in any buffer, and the smart filter will only be enabled for that buffer.<br />
<br />
The following alias will remove a previously enabled smart filter in the current buffer. Add the alias:<br />
<br />
/alias rmsfilter filter del irc_smart_$server_$channel<br />
<br />
and execute it by<br />
<br />
/rmsfilter<br />
<br />
=== Key Bindings ===<br />
<br />
Some helpful bindings:<br />
<br />
To use ctrl-left/right arrow keys to jump to next/previous words on the input line:<br />
<br />
/key bind meta2-1;5D /input move_previous_word<br />
/key bind meta2-1;5C /input move_next_word<br />
<br />
=== SSH connection lost when idle ===<br />
<br />
If you're connecting to your WeeChat through a remote shell using SSH, for example running it in [[screen]] or [[tmux]] you might experience getting disconnected after a while when idle. There are multiple factors in play why this might happen, but the easiest way to change this is to force the connection to be kept alive by appending this to your SSH-configuration on the remote shell.<br />
<br />
This has nothing to do with WeeChat itself, but losing connection when idle won't happen with it's alternative [[irssi]] by default, and thus is a common situation for those converting to WeeChat. <br />
<br />
{{hc|# /etc/ssh/sshd_config|2=<br />
ClientAliveInterval 300}}<br />
<br />
Or have a look at [http://mosh.mit.edu/ Mosh].<br />
<br />
== Troubleshooting ==<br />
<br />
=== Errors loading plugins ===<br />
<br />
You may see output like the following in the main window after starting '''weechat''':<br />
<br />
12:29:37 =!= | Error: unable to load plugin "/usr/lib/weechat/plugins/'''tcl.so'''": libtcl8.6.so: cannot open shared object file: No such file or directory<br />
12:29:37 =!= | If you're trying to load a script and not a C plugin, try command to load scripts (/perl, /python, ...)<br />
12:29:37 =!= | Error: unable to load plugin "/usr/lib/weechat/plugins/'''ruby.so'''": libruby.so.2.0: cannot open shared object file: No such file or directory<br />
12:29:37 =!= | If you're trying to load a script and not a C plugin, try command to load scripts (/perl, /python, ...)<br />
12:29:37 | Plugins loaded: alias, aspell, charset, fifo, guile, irc, logger, lua, perl, python, relay, rmodifier, script, xfer<br />
<br />
The default configuration for weechat attempts to load all plugins found in /usr/lib/weechat/plugins which in this case includes both tcl and ruby. These packages are not required by the weechat package and may not be installed on your machine. There are two options if these errors bother you:<br />
<br />
# [[Packages|Install]] [https://www.archlinux.org/packages/?name=tcl tcl], [https://www.archlinux.org/packages/?name=ruby ruby] from the [[official repositories]].<br />
# Or, run {{ic|/set weechat.plugin.autoload "*,!tcl,!ruby"}} which will prevent loading those plugins with a bang (!) prefix.<br />
<br />
== Getting Help ==<br />
<br />
To access WeeChat's built-in help, simply type<br />
<br />
/help<br />
<br />
and the help will be displayed in the main buffer (usually buffer 1).<br />
<br />
== See also ==<br />
<br />
* [http://www.weechat.org Home Page]<br />
* [http://www.weechat.org/doc/ WeeChat Documentation]<br />
* [http://www.weechat.org/scripts/ WeeChat Scripts]<br />
* [http://dev.weechat.org/ WeeChat Development Blog]<br />
<br />
=== Guides ===<br />
<br />
* [http://fixato.org/guides/setting_up_weechat.html FiXato's guide to WeeChat]<br />
* [http://pascalpoitras.com/2013/06/29/weechat-my-favorites-scripts/ Pascalpoitras: Favorite scripts]<br />
* [http://pascalpoitras.com/ Pascalpoitras Weechat Tips]</div>Siddharthist