https://wiki.archlinux.org/api.php?action=feedcontributions&user=Faith&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:35:20ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Gamepad&diff=674415Gamepad2021-05-30T05:00:24Z<p>Faith: Update to current Dualshock 4 product name</p>
<hr />
<div>[[Category:Input devices]]<br />
[[Category:Gaming]]<br />
[[ja:ゲームパッド]]<br />
[[ru:Gamepad]]<br />
Many gamepads are working out-of-the-box nowadays, but there are still many potential problems and sources for errors since gamepad support in applications varies by a lot.<br />
<br />
== Gamepad input systems ==<br />
<br />
{{Expansion|Need info about differences between API, how to switch between them.|section=Joystick API vibration support}}<br />
Linux has two different input systems for Gamepads – the original Joystick interface and the newer evdev-based interface.<br />
<br />
{{ic|1=/dev/input/jsX}} maps to the Joystick API interface and {{ic|/dev/input/event*}} maps to the evdev ones (this also includes other input devices such as mice and keyboards). Symbolic links to those devices are also available in {{ic|/dev/input/by-id/}} and {{ic|/dev/input/by-path/}} where the legacy Joystick API has names ending with {{ic|-joystick}} while the evdev have names ending with {{ic|-event-joystick}}.<br />
<br />
Most new games will default to the evdev interface as it gives more detailed information about the buttons and axes available and also adds support for force feedback.<br />
<br />
While SDL1 defaults to evdev interface you can force it to use the old Joystick API by setting the environment variable {{ic|1=SDL_JOYSTICK_DEVICE=/dev/input/js0}}. This can help many games such as X3. SDL2 supports only the new evdev interface.<br />
<br />
== Determining which modules you need ==<br />
<br />
Unless you are using very old joystick that uses gameport or proprietary USB protocol, you will need just the generic USB human interface device (HID) modules.<br />
<br />
For an extensive overview of all joystick related modules in Linux, you will need access to the Linux kernel sources -- specifically the Documentation section. Unfortunately, pacman kernel packages do not include what we need. If you have the kernel sources downloaded, have a look at {{ic|Documentation/input/joydev/}}. You can browse the kernel source tree at [https://kernel.org/ kernel.org] by clicking the "browse" (cgit - the git frontend) link for the kernel that you are using, then clicking the "tree" link near the top. Here is a link to the [https://www.kernel.org/doc/html/latest/input/joydev/joystick.html documentation from the latest kernel].<br />
<br />
Some joysticks need specific modules, such as the Microsoft Sidewinder controllers ({{ic|sidewinder}}), or the Logitech digital controllers ({{ic|adi}}). Many older joysticks will work with the simple {{ic|analog}} module. If your joystick is plugging in to a gameport provided by your soundcard, you will need your soundcard drivers loaded - however, some cards, like the Soundblaster Live, have a specific gameport driver ({{ic|emu10k1-gp}}). Older ISA soundcards may need the {{ic|ns558}} module, which is a standard gameport module.<br />
<br />
As you can see, there are many different modules related to getting your joystick working in Linux, so I could not 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 gamepads ===<br />
<br />
You need to get USB working, and then modprobe your gamepad 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 />
==== Troubleshooting ====<br />
<br />
If your Xbox 360 gamepad is connected with the Play&Charge USB cable it will show up in {{ic|lsusb}} but it will not show up as an input device in {{ic|/dev/input/js*}}, see note below.<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 (including vibration feedback) with {{ic|1=wine control joy.cpl}}.<br />
<br />
{{Tip| Input devices by default have '''input''' group; for example, {{pkg|pcsx2}} have no access to gamepad without rights. Make sure your user is in the '''input''' group.}}<br />
<br />
=== Joystick API ===<br />
<br />
There are a lot of applications that can test this old API, {{ic|jstest}} from the {{pkg|joyutils}} package is the simplest one. If the output is unreadable because the line printed is too long you can also use graphical tools. KDE Plasma has a built in one in System Settings -&gt; Input Devices -&gt; Game Controller. There is {{AUR|jstest-gtk-git}} as an alternative.<br />
<br />
Use of {{ic|jstest}} is fairly simple, you just run {{ic|jstest /dev/input/js0}} and it will print a line with state of all the axes (normalised to {-32767,32767}) and buttons.<br />
<br />
After you start {{ic|jstest-gtk}}, it will just show you a list of joysticks available, you just need to select one and press Properties.<br />
<br />
=== evdev API ===<br />
<br />
The new 'evdev' API can be tested using the SDL2 joystick test application or using {{ic|evtest}} from community repository. Install {{AUR|sdl2-jstest-git}} and then run {{ic|sdl2-jstest --test 0}}. Use {{ic|sdl2-jstest --list}} to get IDs of other controllers if you have multiple ones connected.<br />
<br />
To test force feedback on the device, use {{ic|fftest}} from {{ic|linuxconsole}} package:<br />
$ fftest /dev/input/by-id/usb-*event-joystick<br />
<br />
=== HTML5 Gamepad API ===<br />
<br />
Go to https://gamepad-tester.com/. To test vibration, click on the word Vibration. Note, that vibration is currently supported in Chromium browser, but not in Firefox. Also, in Firefox you cannot see a gamepad image, but in Chromium you can.<br />
<br />
== Setting up deadzones and calibration ==<br />
<br />
If you want to set up the deadzones (or remove them completely) of your analog input you have to do it separately for the xorg (for mouse and keyboard emulation), Joystick API and evdev API.<br />
<br />
=== Wine deadzones ===<br />
<br />
Add the following registry entry and set it to a string from 0 to 10000 (affects all axes):<br />
HKEY_CURRENT_USER\Software\Wine\DirectInput\DefaultDeadZone<br />
Source: [https://wiki.winehq.org/UsefulRegistryKeys UsefulRegistryKeys]<br />
<br />
=== Xorg deadzones ===<br />
<br />
Add a similar line to {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it does not exist):<br />
{{hc|1=/etc/X11/xorg.conf.d/51-joystick.conf|2=<nowiki><br />
Section "InputClass"<br />
Option "MapAxis1" "deadzone=1000"<br />
EndSection<br />
</nowiki>}}<br />
1000 is the default value, but you can set anything between 0 and 30 000. To get the axis number see the "Testing Your Configuration" section of this article.<br />
If you already have an option with a specific axis just type in the {{ic|1=deadzone=value}} at the end of the parameter separated by a space.<br />
<br />
=== Joystick API deadzones ===<br />
<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 ('''do not''' 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/bash /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 />
<br />
The {{ic|evdev-joystick}} tool from the {{pkg|linuxconsole}} package can be used to view and change deadzones and calibration for {{ic|evdev}} API devices.<br />
<br />
To view your device configuration:<br />
$ evdev-joystick --showcal /dev/input/by-id/usb-*-event-joystick<br />
<br />
To change the deadzone for a particular axis, use a command like:<br />
$ evdev-joystick --evdev /dev/input/by-id/usb-*-event-joystick --axis 0 --deadzone 0<br />
<br />
To set the same deadzone for all axes at once, omit the "--axis 0" option.<br />
<br />
Use udev rules file to set them automatically when the controller is connected.<br />
<br />
Note that inside the kernel, the value is called {{ic|flatness}} and is set using the {{ic|EVIOCSABS}} {{ic|ioctl}}.<br />
<br />
Default configuration will look like similar to this:<br />
{{hc|$ evdev-joystick --showcal /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick|2= Supported Absolute axes:<br />
Absolute axis 0x00 (0) (X Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x01 (1) (Y Axis) (min: 0, max: 65535, flatness: 4095 (=6.25%), fuzz: 255)<br />
Absolute axis 0x05 (5) (Z Rate Axis) (min: 0, max: 4095, flatness: 255 (=6.23%), fuzz: 15)<br />
Absolute axis 0x10 (16) (Hat zero, x axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)<br />
Absolute axis 0x11 (17) (Hat zero, y axis) (min: -1, max: 1, flatness: 0 (=0.00%), fuzz: 0)}}<br />
<br />
While a more reasonable setting would be achieved with something like this (repeat for other axes):<br />
{{hc|$ evdev-joystick --evdev /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick --axis 0 --deadzone 512|2= Event device file: /dev/input/by-id/usb-Madcatz_Saitek_Pro_Flight_X-55_Rhino_Stick_G0000090-event-joystick<br />
Axis index to deal with: 0<br />
New dead zone value: 512<br />
Trying to set axis 0 deadzone to: 512<br />
Absolute axis 0x00 (0) (X Axis) Setting deadzone value to : 512<br />
(min: 0, max: 65535, flatness: 512 (=0.78%), fuzz: 255)}}<br />
<br />
=== Configuring curves and responsiveness ===<br />
<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 />
<br />
If you want to play games with your gamepad, you might want to disable its joystick control over mouse cursor. To do this, edit {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} (create if it does not exists) so that it looks like this:<br />
{{hc|/etc/X11/xorg.conf.d/51-joystick.conf |<br />
Section "InputClass"<br />
Identifier "joystick catchall"<br />
MatchIsJoystick "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "joystick"<br />
Option "StartKeysEnabled" "False" #Disable mouse<br />
Option "StartMouseEnabled" "False" #support<br />
EndSection}}<br />
<br />
== Using gamepad to send keystrokes ==<br />
<br />
A couple gamepad buttons to keystroke programs exist like {{AUR|qjoypad}} or {{AUR|antimicrox-git}}, all work well without the need for X.org configuration.<br />
<br />
=== Xorg configuration example ===<br />
<br />
This is a good solution for systems where restarting Xorg is a rare event because it is a static configuration loaded only on X startup. The example runs on a [[Kodi]] media PC, controlled with a Logitech Cordless RumblePad 2. Due to a problem with the d-pad (a.k.a. "hat") being recognized as another axis, [[Joy2key]] was used as a workaround. Since upgrade to Kodi version 11.0 and joy2key 1.6.3-1, this setup no longer worked and the following was created for letting Xorg handle joystick events.<br />
<br />
First, [[install]] the {{AUR|xf86-input-joystick}} package. Then, create {{ic|/etc/X11/xorg.conf.d/51-joystick.conf}} like so:<br />
{{bc|<nowiki><br />
Section "InputClass"<br />
Identifier "Joystick hat mapping"<br />
Option "StartKeysEnabled" "True"<br />
#MatchIsJoystick "on"<br />
Option "MapAxis5" "keylow=113 keyhigh=114"<br />
Option "MapAxis6" "keylow=111 keyhigh=116"<br />
EndSection<br />
</nowiki>}}<br />
{{Note|The {{ic|MatchIsJoystick "on"}} line does not seem to be required for the setup to work, but you may want to uncomment it.}}<br />
<br />
== Specific devices ==<br />
<br />
While most gamepads, especially USB based ones should just work, some may require (or give better results) if you use alternative drivers. If it does not work the first time, do not give up, and read those docs thoroughly!<br />
<br />
=== Dance pads ===<br />
<br />
Most dance pads should work. However some pads, especially those used from a video game console via an adapter, have a tendency to map the directional buttons as axis buttons. This prevents hitting left-right or up-down simultaneously. This behavior can be fixed for devices recognized by xpad via a module option:<br />
<br />
# modprobe -r xpad<br />
# modprobe xpad dpad_to_buttons=1<br />
<br />
If that did not work, you can try {{AUR|axisfix-git}} or patching the {{ic|joydev}} kernel module (https://github.com/adiel-mittmann/dancepad).<br />
<br />
=== Logitech Thunderpad Digital ===<br />
<br />
Logitech Thunderpad Digital will not show all the buttons if you use the {{ic|analog}} module. Use the device specific {{ic|adi}} module for this controller.<br />
<br />
=== Nintendo Gamecube Controller ===<br />
<br />
Dolphin Emulator has a [https://wiki.dolphin-emu.org/index.php?title=How_to_use_the_Official_GameCube_Controller_Adapter_for_Wii_U_in_Dolphin page on their wiki] that explains how to use the official Nintendo USB adapter with a Gamecube controller. This configuration also works with the Mayflash Controller Adapter if the switch is set to "Wii U".<br />
<br />
=== Nintendo Switch Pro Controller and Joy-Cons ===<br />
<br />
==== Kernel Nintendo HID Driver ====<br />
<br />
The hid-nintendo kernel HID driver is currently in review on the linux-input mailing list. The most recent version of the changeset is currently being maintained in this[https://github.com/DanielOgorchock/linux] git repository, or its staging branch[https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-5.10/nintendo] for kernel 5.10. It's also available as a dkms module named {{AUR|hid-nintendo-dkms}}. The driver provides support for rumble, battery level, and control of the player and home LEDs. It supports the Nintendo Switch Pro Controller over both USB and bluetooth in addition to the joy-cons.<br />
<br />
An alternate dkms module named {{AUR|hid-nintendo-nso-dkms}} patches in support for the Switch Online NES and SNES controllers.<br />
<br />
===== joycond Userspace Daemon =====<br />
<br />
The hid-nintendo kernel driver does not handle the combination of two joy-cons into one virtual input device. That functionality has been left up to userspace. {{AUR|joycond-git}} is a userspace daemon that combines two kernel joy-con evdev devices into one virtual input device using uinput. An application can use two joy-cons as if they are a single controller. When the daemon is active, switch controllers will be placed in a pseudo pairing mode, and the LEDs will start flashing. Holding the triggers can be used to pair controllers and make them usable. To pair two joy-cons together, press one trigger on each joy-con.<br />
<br />
===== Using hid-nintendo with Steam Games =====<br />
<br />
The hid-nintendo driver currently conflicts with steam using hidraw to implement its own pro controller driver. If you wish to use the Steam implementation, the hid-nintendo driver can be blacklisted. Alternatively if you want to use hid-nintendo with a Steam game directly, Steam can be started without access to hidraw using firejail:<br />
<br />
$ firejail --noprofile --blacklist=/sys/class/hidraw/ steam<br />
<br />
An [https://github.com/ValveSoftware/steam-for-linux/issues/6651 issue] has been opened on the steam-for-linux github repo.<br />
<br />
===== Using hid-nintendo with SDL2 Games =====<br />
<br />
To add a mapping for the joy-cons or the pro controller to an SDL2 game, {{AUR|controllermap}} can be run in the game's directory of games which have their own gamecontrollerdb.txt file.<br />
<br />
Alternatively, the mappings can be added to an environment variable:<br />
<br />
{{hc|1=~/.bashrc |2=# hid-nintendo SDL2 mappings<br />
export SDL_GAMECONTROLLERCONFIG="050000007e0500000920000001800000,Nintendo Switch Pro Controller,platform:Linux,a:b0,b:b1,x:b3,y:b2,back:b9,guide:b11,start:b10,leftstick:b12,rightstick:b13,leftshoulder:b5,rightshoulder:b6,dpup:b14,dpdown:b15,dpleft:b16,dpright:b17,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b7,righttrigger:b8,<br />
030000007e0500000920000011810000,Nintendo Switch Pro Controller,platform:Linux,a:b0,b:b1,x:b3,y:b2,back:b9,guide:b11,start:b10,leftstick:b12,rightstick:b13,leftshoulder:b5,rightshoulder:b6,dpup:h0.1,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b7,righttrigger:b8,<br />
060000007e0500000620000000000000,Nintendo Switch Combined Joy-Cons,platform:Linux,a:b0,b:b1,x:b3,y:b2,back:b9,guide:b11,start:b10,leftstick:b12,rightstick:b13,leftshoulder:b5,rightshoulder:b6,dpup:b14,dpdown:b15,dpleft:b16,dpright:b17,leftx:a0,lefty:a1,rightx:a2,righty:a3,lefttrigger:b7,righttrigger:b8,<br />
"}}<br />
<br />
==== Dolphin (Gamecube Controller Emulation) ====<br />
<br />
Shinyquagsire23 made a git repo called "HID Joy-Con Whispering"[https://github.com/shinyquagsire23/HID-Joy-Con-Whispering], which contains a userspace driver for the Joy Cons and the Switch Pro Controller over USB. Currently, it does not support rumble or gyroscope. For rumble support, see the hid-nintendo kernel driver section above.<br />
<br />
After running make, load the uinput module:<br />
<br />
# modprobe uinput<br />
<br />
Then to activate the driver:<br />
<br />
# ./uinputdriver > /dev/null<br />
<br />
Over on Dolphin's controller configuration menu, there should be an entry for evdev/0/joycon (not Nintendo Switch Pro Controller). Select it, and you should now be able to configure the controls.<br />
<br />
==== Steam ====<br />
<br />
While the controller works for native Linux games, this controller is not detected by Steam. To fix this, we will need to add a line to 70-steam-controller.rules.<br />
<br />
{{hc<br />
|head=/lib/udev/rules.d/70-steam-controller.rules<br />
|output=<nowiki># NS PRO Controller USB<br />
KERNEL=="hidraw*", ATTRS{idVendor}=="20d6", ATTRS{idProduct}=="a711", MODE="0660", TAG+="uaccess"</nowiki><br />
}}<br />
<br />
udev can be reloaded with the new configuration by executing<br />
<br />
# udevadm control --reload-rules<br />
<br />
=== iPEGA-9017s and other Bluetooth gamepads ===<br />
<br />
If you want to use one of the widely available bluetooth gamepads, such as iPEGA-9017s designed mostly for Android and iOS devices you would need {{AUR|xboxdrv}}, {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}}. You should connect it in gamepad mode (if there are different modes, choose the gamepad one). Technically it's ready to be used, but in most cases games would not recognize it, and you would have to map it individually for all application. The best way to simplify it and make it work with all applications is to mimic Microsoft X360 controller with {{AUR|xboxdrv}}.<br />
Once connected you can create a udev rule to give it a persistent name, that would come in handy when setting it up.<br />
<br />
{{hc<br />
|/etc/udev/rules.d/99-btjoy.rules|2=<br />
#Create a symlink to appropriate /dev/input/eventX at /dev/btjoy<br />
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="Bluetooth Gamepad", ATTRS{uniq}=="00:17:02:01:ae:2a", SYMLINK+="btjoy"<br />
}}<br />
<br />
Replace "Bluetooth Gampad" with your device name and "00:17:02:01:ae:2a" with your device's address.<br />
<br />
Next, create a configuration for {{AUR|xboxdrv}} somewhere, for example:<br />
<br />
{{hc<br />
|~/.config/xboxdrv/ipega.conf|2=<br />
#iPEGA PG-9017S Config <br />
<br />
[xboxdrv]<br />
evdev-debug = true<br />
evdev-grab = true<br />
rumble = false<br />
mimic-xpad = true<br />
<br />
[evdev-absmap]<br />
ABS_HAT0X = dpad_x<br />
ABS_HAT0Y = dpad_y<br />
<br />
ABS_X = X1<br />
ABS_Y = Y1<br />
<br />
ABS_Z = X2<br />
ABS_RZ = Y2<br />
<br />
[axismap]<br />
-Y1 = Y1<br />
-Y2 = Y2<br />
<br />
[evdev-keymap]<br />
BTN_EAST=a<br />
BTN_C=b<br />
BTN_NORTH=y<br />
BTN_SOUTH=x<br />
BTN_TR2=start<br />
BTN_TL2=back<br />
BTN_Z=rt<br />
BTN_WEST=lt<br />
<br />
BTN_MODE = guide<br />
}}<br />
<br />
Refer to the xboxdrv man to see all the options.<br />
<br />
Now when you have the config and your device is connected you can start the {{AUR|xboxdrv}} like so:<br />
<br />
# xboxdrv --evdev /dev/btjoy --config .config/xboxdrv/ipega.conf<br />
<br />
Your games will now work with bluetooth gamepad as long as xboxdrv is running.<br />
<br />
==== iPEGA-9068 and 9087 ====<br />
<br />
For this model, use the same procedures as above, but with the configs:<br />
<br />
{{hc<br />
|~/.config/xboxdrv/ipega.conf|2=<br />
#iPEGA PG-9068 and PG-9087 Config <br />
<br />
[xboxdrv]<br />
evdev-debug = true<br />
evdev-grab = true<br />
rumble = false<br />
mimic-xpad = true<br />
<br />
[evdev-absmap]<br />
ABS_HAT0X = dpad_x<br />
ABS_HAT0Y = dpad_y<br />
<br />
ABS_X = X1<br />
ABS_Y = Y1<br />
<br />
ABS_Z = X2<br />
ABS_RZ = Y2<br />
<br />
[axismap]<br />
-Y1 = Y1<br />
-Y2 = Y2<br />
<br />
[evdev-keymap]<br />
BTN_A=a<br />
BTN_B=b<br />
BTN_Y=y<br />
BTN_X=x<br />
BTN_TR=rb<br />
BTN_TL=lb<br />
BTN_TR2=rt<br />
BTN_TL2=lt<br />
BTN_THUMBL=tl<br />
BTN_THUMBR=tr<br />
BTN_START=start<br />
BTN_SELECT=back<br />
<br />
BTN_MODE = guide<br />
}}<br />
<br />
=== Steam Controller ===<br />
<br />
{{Note|Kernel 4.18 [https://lkml.org/lkml/2018/4/16/380 provides a kernel driver] for wired/wireless use of the steam controller as a controller input device without [[Steam]].}}<br />
<br />
The [[Steam]] client will recognize the controller and provide keyboard/mouse/gamepad emulation while Steam is running. The in-game Steam overlay needs to be enabled and working in order for gamepad emulation to work. You may need to run {{ic|udevadm trigger}} with root privileges or plug the dongle out and in again, if the controller does not work immediately after installing and running Steam. If all else fails, try restarting the computer while the dongle is plugged in.<br />
<br />
For Steam client to be able to emulate other gamepads in games, you will need to follow this [https://steamcommunity.com/app/353370/discussions/2/1735465524711324558/ post] from Valve. Note that name of the file with udev rules may be different, for example {{ic|/usr/lib/udev/rules.d/70-steam-input.rules}}. A reboot may be required after making changes.<br />
<br />
If you are using the controller connected via Bluetooth LE, make sure the user is part of the {{ic|input}} group.<br />
<br />
If you cannot get the Steam Controller to work, see [[#Steam Controller not pairing]].<br />
<br />
Alternatively you can install {{AUR|python-steamcontroller-git}} to have controller and mouse emulation without Steam or {{AUR|sc-controller}} for a versatile graphical configuration tool simillar to what is provided by the Steam client.<br />
<br />
{{Note|If you do not use the [[Steam runtime]], you might actually need to disable the overlay for the controller to work in certain games (Rocket Wars, Rocket League, Binding of Isaac, etc.). Right click on a game in your library, select "Properties", and uncheck "Enable Steam Overlay".}}<br />
<br />
==== Wine ====<br />
<br />
{{AUR|python-steamcontroller-git}} can also be used to make the Steam Controller work for games running under Wine. You need to find and download the application {{ic|xbox360cemu.v.3.0}} (e.g. from [https://github.com/jacobmischka/ds4-in-wine/tree/master/xbox360cemu.v.3.0 here]). Then copy the files {{ic|dinput8.dll}}, {{ic|xbox360cemu.ini}}, {{ic|xinput1_3.dll}} and {{ic|xinput_9_1_0.dll}} to the directory that contains your game executable. Edit {{ic|xbox360cemu.ini}} and only change the following values under {{ic|[PAD1]}} to remap the Steam Controller correctly to a XBox controller.<br />
<br />
{{hc|xbox360cemu.ini|2= Right Analog X=4<br />
Right Analog Y=-5<br />
A=1<br />
B=2<br />
X=3<br />
Y=4<br />
Back=7<br />
Start=8<br />
Left Thumb=10<br />
Right Thumb=11<br />
Left Trigger=a3<br />
Right Trigger=a6}}<br />
<br />
Now start python-steamcontroller in Xbox360 mode ({{ic|sc-xbox.py start}}). You might also want to copy {{ic|XInputTest.exe}} from {{ic|xbox360cemu.v.3.0}} to the same directory and run it with Wine in order to test if the mappings work correctly. However neither mouse nor keyboard emulation work with this method.<br />
<br />
Alternatively you can use {{AUR|sc-controller}} for a similar graphical setup as Steam's own configurator. As of writing, it's a bit buggy here and there but offers an easy click and go way of configuring the controller.<br />
<br />
=== Xbox 360 controller ===<br />
<br />
Both the wired and wireless (with the ''Xbox 360 Wireless Receiver for Windows'') controllers are supported by the {{ic|xpad}} kernel module and should work without additional packages. Note that using a wireless Xbox360 controller with the Play&Charge USB cable will not work. The cable is for recharging only and does not transmit any input data over the wire.<br />
<br />
It has been reported that the default xpad driver has some issues with a few newer wired and wireless controllers, such as:<br />
* incorrect button mapping. ([https://github.com/ValveSoftware/steam-for-linux/issues/95#issuecomment-14009081 discussion in Steam bugtracker])<br />
* not-working sync. All four LEDs keep blinking, but controller works. ([https://bbs.archlinux.org/viewtopic.php?id=156028 discussion in Arch Forum])<br />
<br />
If you experience such issues, you can use either [[#SteamOS xpad]] or [[#xboxdrv]] instead of the default {{ic|xpad}} driver.<br />
<br />
If you wish to use the controller for controlling the mouse, or mapping buttons to keys, etc. you should use the {{AUR|xf86-input-joystick}} package (configuration help can be found using {{man|4|joystick|url=}}). If the mouse locks itself in a corner, it might help changing the {{ic|MatchDevicePath}} in {{ic|/etc/X11/xorg.conf.d/50-joystick.conf}} from {{ic|/dev/input/event*}} to {{ic|/dev/input/js*}}.<br />
<br />
{{Tip|If you use the [[TLP]] power management tool, you may experience connection issues with your Microsoft wireless adapter (e.g. the indicator LED will go out after the adapter has been connected for a few seconds, and controller connection attempts fail). This is due to TLP's USB autosuspend functionality, and the solution is to add the Microsoft wireless adapter's device ID to this feature's blacklist (USB_BLACKLIST, check [https://linrunner.de/en/tlp/docs/tlp-configuration.html#usb TLP configuration] for more details).}}<br />
<br />
In order to connect via Bluetooth using KDE, add the following [[kernel parameter]] {{ic|1=bluetooth.disable_ertm=1}}.<br />
<br />
==== SteamOS xpad ====<br />
<br />
If you have issues with the default {{ic|xpad}} kernel module, you can install the SteamOS version. There is still a known issue with compatibility between wireless Xbox360 controllers and games made in GameMaker Studio. If you encounter this problem, the only known workaround is to use xboxdrv. YoYo Games has refused to acknowledge this as a bug with their product and it is unlikely to ever be fixed.<br />
<br />
First make sure you have [[DKMS]] installed and running, then install the modified kernel module {{AUR|steamos-xpad-dkms}}{{Broken package link|package not found}}. During the installation you will see that new xpad kernel module is strapped to your current kernel:<br />
<br />
Creating symlink /var/lib/dkms/steamos-xpad-dkms/0.1/source -&gt;<br />
/usr/src/steamos-xpad-dkms-0.1<br />
<br />
DKMS: add completed.<br />
<br />
Kernel preparation unnecessary for this kernel. Skipping...<br />
<br />
Building module:<br />
cleaning build area....<br />
make KERNELRELEASE=3.12.8-1-ARCH KVERSION=3.12.8-1-ARCH....<br />
cleaning build area....<br />
<br />
Then unload the old xpad module and load new one:<br />
<br />
# rmmod xpad<br />
# modprobe steamos-xpad<br />
<br />
Or just restart your computer.<br />
<br />
==== xboxdrv ====<br />
<br />
[https://gitlab.com/xboxdrv/xboxdrv xboxdrv] is an alternative to {{ic|xpad}} which provides more functionality and might work better with certain controllers. It works in userspace and can be launched as system service. <br />
<br />
Install it with the {{AUR|xboxdrv}} package. Then [[start]]/[[enable]] {{ic|xboxdrv.service}}.<br />
<br />
If you have issues with the controller being recognized but not working in steam games or working but with incorrect mappings, it may be required to modify you config as such:<br />
{{hc<br />
|/etc/default/xboxdrv|2=<br />
[xboxdrv]<br />
silent = true<br />
device-name = "Xbox 360 Wireless Receiver"<br />
mimic-xpad = true<br />
deadzone = 4000<br />
<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Multiple controllers =====<br />
<br />
xboxdrv supports a multitude of controllers, but they need to be set up in {{ic|/etc/default/xboxdrv}}. For each extra controller, add an {{ic|1=next-controller = true}} line. For example, when using 4 controllers, add it 3 times:<br />
<br />
{{bc|<nowiki><br />
[xboxdrv]<br />
silent = true<br />
next-controller = true<br />
next-controller = true<br />
next-controller = true<br />
[xboxdrv-daemon]<br />
dbus = disabled<br />
</nowiki>}}<br />
<br />
Then [[restart]] {{ic|xboxdrv.service}}.<br />
<br />
===== Mimic Xbox 360 controller with other controllers =====<br />
<br />
xboxdrv can be used to make any controller register as an Xbox 360 controller with the {{ic|--mimic-xpad}} switch. This may be desirable for games that support Xbox 360 controllers out of the box, but have trouble detecting or working with other gamepads.<br />
<br />
First, you need to find out what each button and axis on the controller is called. You can use {{Pkg|evtest}} for this. Run {{ic|evtest}} and select the device event ID number ({{ic|/dev/input/event*}}) that corresponds to your controller. Press the buttons on the controller and move the axes to read the names of each button and axis.<br />
<br />
Here is an example of the output:<br />
{{bc|<nowiki><br />
<br />
Event: time 1380985017.964843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985017.964843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 1<br />
Event: time 1380985017.964843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.076843, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90003<br />
Event: time 1380985018.076843, type 1 (EV_KEY), code 290 (BTN_THUMB2), value 0<br />
Event: time 1380985018.076843, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.460841, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.460841, type 1 (EV_KEY), code 289 (BTN_THUMB), value 1<br />
Event: time 1380985018.460841, -------------- SYN_REPORT ------------<br />
Event: time 1380985018.572835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90002<br />
Event: time 1380985018.572835, type 1 (EV_KEY), code 289 (BTN_THUMB), value 0<br />
Event: time 1380985018.572835, -------------- SYN_REPORT ------------<br />
Event: time 1380985019.980824, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985019.980824, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 1<br />
Event: time 1380985019.980824, -------------- SYN_REPORT ------------<br />
Event: time 1380985020.092835, type 4 (EV_MSC), code 4 (MSC_SCAN), value 90006<br />
Event: time 1380985020.092835, type 1 (EV_KEY), code 293 (BTN_PINKIE), value 0<br />
Event: time 1380985020.092835, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.596806, type 3 (EV_ABS), code 3 (ABS_RX), value 18<br />
Event: time 1380985023.596806, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.612811, type 3 (EV_ABS), code 3 (ABS_RX), value 0<br />
Event: time 1380985023.612811, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.708768, type 3 (EV_ABS), code 3 (ABS_RX), value 14<br />
Event: time 1380985023.708768, -------------- SYN_REPORT ------------<br />
Event: time 1380985023.724772, type 3 (EV_ABS), code 3 (ABS_RX), value 128<br />
Event: time 1380985023.724772, -------------- SYN_REPORT ------------<br />
</nowiki>}}<br />
<br />
In this case, {{ic|BTN_THUMB}}, {{ic|BTN_THUMB2}} and {{ic|BTN_PINKIE}} are buttons and {{ic|ABS_RX}} is the X axis of the right analogue stick.<br />
You can now mimic an Xbox 360 controller with the following command:<br />
<br />
$ xboxdrv --evdev /dev/input/event* --evdev-absmap ABS_RX=X2 --evdev-keymap BTN_THUMB2=a,BTN_THUMB=b,BTN_PINKIE=rt --mimic-xpad<br />
<br />
The above example is incomplete. It only maps one axis and 3 buttons for demonstration purposes. Use {{ic|xboxdrv --help-button}} to see the names of the Xbox controller buttons and axes and bind them accordingly by expanding the command above. Axes mappings should go after {{ic|--evdev-absmap}} and button mappings follow {{ic|--evdev-keymap}} (comma separated list; no spaces).<br />
<br />
By default, xboxdrv outputs all events to the terminal. You can use this to test that the mappings are correct. Append the {{ic|--silent}} option to keep it quiet.<br />
<br />
==== Using generic/clone controllers ====<br />
<br />
Some clone gamepads might require a specific initialization sequence in order to work ([https://superuser.com/a/1380235 Super User answer]). For that you should run the following python script as the root user:<br />
<br />
{{bc|<nowiki><br />
#!/usr/bin/env python3<br />
<br />
import usb.core<br />
<br />
dev = usb.core.find(idVendor=0x045e, idProduct=0x028e)<br />
<br />
if dev is None:<br />
raise ValueError('Device not found')<br />
else:<br />
dev.ctrl_transfer(0xc1, 0x01, 0x0100, 0x00, 0x14) <br />
</nowiki>}}<br />
<br />
=== Xbox Wireless Controller / Xbox One Wireless Controller ===<br />
<br />
==== Connect Xbox Wireless Controller with usb cable ====<br />
<br />
This is supported by the kernel and should work without additional packages.<br />
<br />
==== Connect Xbox Wireless Controller with Bluetooth ====<br />
<br />
You will probably have to disable Enhanced Retransmission Mode (ERTM) to make it work.<br />
<br />
Use either:<br />
<br />
# echo 1 > /sys/module/bluetooth/parameters/disable_ertm<br />
<br />
Or add this file to your module configuration:<br />
<br />
{{hc<br />
|/etc/modprobe.d/xbox_bt.conf|2=<br />
options bluetooth disable_ertm=1<br />
}}<br />
<br />
===== xpadneo =====<br />
<br />
A relatively new driver which does support the Xbox One S and Xbox Series X|S controller via Bluetooth is called [https://github.com/atar-axis/xpadneo/ xpadneo]. At the moment it only has basic support for the Xbox Elite Series 2 Wireless controller.<br />
In exchange for fully supporting just two controllers so far, it enables one to read out the correct battery level, supports rumble (even the one on the trigger buttons - L2/R2), corrects the (sometimes wrong) button mapping and more.<br />
<br />
Installation is done using DKMS: {{AUR|xpadneo-dkms-git}}<br />
<br />
==== Connect Xbox Wireless Controller with Microsoft Xbox Wireless Adapter ====<br />
<br />
===== xow =====<br />
<br />
[https://github.com/medusalix/xow xow] is a project that allows connection with a wireless dongle. It is currently in very early stages of development. It can be installed via {{AUR|xow-git}}<br />
<br />
=== Logitech Dual Action ===<br />
<br />
The Logitech Dual Action gamepad has a very similar mapping to the PS2 pad, but some buttons and triggers need to be swapped to mimic the Xbox controller.<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TRIGGER=x,BTN_TOP=y,BTN_THUMB=a,BTN_THUMB2=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lt,BTN_BASE2=rt,BTN_TOP2=lb,BTN_PINKIE=rb,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
=== PlayStation 2 controller via USB adapter ===<br />
<br />
To fix the button mapping of PS2 dual adapters and mimic the Xbox controller you can run the following command:<br />
<br />
# xboxdrv --evdev /dev/input/event* \<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RZ=x2,ABS_Z=y2,ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--axismap -Y1=Y1,-Y2=Y2 \<br />
--evdev-keymap BTN_TOP=x,BTN_TRIGGER=y,BTN_THUMB2=a,BTN_THUMB=b,BTN_BASE3=back,BTN_BASE4=start,BTN_BASE=lb,BTN_BASE2=rb,BTN_TOP2=lt,BTN_PINKIE=rt,BTN_BASE5=tl,BTN_BASE6=tr \<br />
--mimic-xpad --silent<br />
<br />
=== PlayStation 3 controller ===<br />
<br />
==== Pairing via USB ====<br />
<br />
If you own a PS3 controller and can connect with USB, plug it to your computer and press the PS button. The controller will power up and one of the four LEDs should light up indicating the controller's number.<br />
<br />
==== Pairing via Bluetooth ====<br />
<br />
Install {{Pkg|bluez}} {{Pkg|bluez-utils}} {{Pkg|bluez-plugins}}. Make sure bluetooth is working by following the first five steps of [[Bluetooth#Pairing]] and leave the bluetoothctl command running, then turn on the controller by pressing the middle 'PS' button(all 4 leds should be blinking quickly ~4 hz) and connect to your computer using usb. Lastly, type yes in the bluetoothctl prompt when asked '{{ic|Authorize service 00001124-0000-1000-8000-00805f9b34fb (yes/no)}}'.<br />
<br />
Alternative instructions:<br />
To connect your PS3 controller to your computer using Bluetooth, you first need to install {{Pkg|bluez}} and {{Pkg|bluez-plugins}} then connect your controller via USB. A pop-up should appear asking for pairing. Click on Trust & Authorize. You can now unplug your controller and press the PS button. The controller will connect and a LED will remain solid. You can now use it to play games. Connecting using the USB cable is only needed after the controller has been connected to another system.<br />
<br />
=== PlayStation 4 controller ===<br />
<br />
==== Pairing via USB ====<br />
<br />
Connect your controller via USB and press the {{ic|PS}} button.<br />
<br />
==== Pairing via Bluetooth ====<br />
<br />
If you want to use bluetooth mode, press {{ic|PS}} button and {{ic|Share}} button together, white led of gamepad should blink very quickly, then add wireless controller with your bluetooth manager (bluez, gnome-bluetooth.<br />
<br />
==== Button mapping ====<br />
<br />
To fix the button mapping of PS4 controller you can use the following command with xboxdrv (or try with the [https://github.com/chrippa/ds4drv ds4drv] program, {{AUR|ds4drv}}):<br />
<br />
# xboxdrv \<br />
--evdev /dev/input/by-id/usb-Sony_Computer_Entertainment_Wireless_Controller-event-joystick\<br />
--evdev-absmap ABS_X=x1,ABS_Y=y1 \<br />
--evdev-absmap ABS_Z=x2,ABS_RZ=y2 \<br />
--evdev-absmap ABS_HAT0X=dpad_x,ABS_HAT0Y=dpad_y \<br />
--evdev-keymap BTN_A=x,BTN_B=a \<br />
--evdev-keymap BTN_C=b,BTN_X=y \<br />
--evdev-keymap BTN_Y=lb,BTN_Z=rb \<br />
--evdev-keymap BTN_TL=lt,BTN_TR=rt \<br />
--evdev-keymap BTN_SELECT=tl,BTN_START=tr \<br />
--evdev-keymap BTN_TL2=back,BTN_TR2=start \<br />
--evdev-keymap BTN_MODE=guide \<br />
--axismap -y1=y1,-y2=y2 \<br />
--mimic-xpad \<br />
--silent<br />
<br />
==== Fix Motion control conflict (gamepad will not work on some applications) ====<br />
<br />
Dualshock 4 V1 and V2 are both like 3 devices, touchpad, motion control, and joypad.<br />
<br />
With somes softwares like Parsec and Shadow cloud gaming streaming apps, motion control is in conflict with joypad, you can disable touchpad and motion control by adding the following udev rule:<br />
<br />
{{hc|1=/etc/udev/rules.d/51-disable-DS3-and-DS4-motion-controls.rules|2=<br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Motion Sensors", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
SUBSYSTEM=="input", ATTRS{name}=="*Controller Touchpad", RUN+="/bin/rm %E{DEVNAME}", ENV{ID_INPUT_JOYSTICK}=""<br />
}}<br />
<br />
This should work in USB and Bluetooth mode.<br />
<br />
==== Disable touchpad acting as mouse ====<br />
<br />
This fixes conflicts with games that actually use touchpad as part of the gamepad, such as Rise of the Tomb Raider.<br />
<br />
Edit {{ic|/etc/X11/xorg.conf.d/30ds4.conf}}.<br />
<br />
And then paste the following and restart X11:<br />
Section "InputClass"<br />
Identifier "ds4-touchpad"<br />
Driver "libinput"<br />
MatchProduct "Wireless Controller Touchpad"<br />
Option "Ignore" "True"<br />
EndSection<br />
<br />
=== PlayStation 3/4 controller ===<br />
<br />
The DualShock 3, DualShock 4 and Sixaxis controllers work out of the box when plugged in via USB (the PS button will need to be pushed to begin). They can also be used wirelessly via Bluetooth.<br />
<br />
Steam properly recognizes it as a PS3 pad and Big Picture can be launched with the PS button. Big Picture and some games may act as if it was a 360 controller. Gamepad control over mouse is on by default. You may want to turn it off before playing games, see [[#Joystick moving mouse]].<br />
<br />
==== Connecting via Bluetooth ====<br />
<br />
Install the {{Pkg|bluez}}, {{Pkg|bluez-plugins}}, and {{Pkg|bluez-utils}} packages, which includes the ''sixaxis'' plugin. Then [[start]] the [[bluetooth]] service and ensure bluetooth is powered on. If using ''bluetoothctl'' start it in a terminal and then plug the controller in via USB. You should be prompted to trust the controller in bluetoothctl. A graphical bluetooth front-end may program your PC's bluetooth address into the controller automatically. Hit the PlayStation button and check that the controller works while plugged in.<br />
<br />
You can now disconnect your controller. The next time you hit the PlayStation button it will connect without asking anything else.<br />
<br />
Alternatively, on a PS4 controller you can hold the share button and the PlayStation button simultaneously (for a few seconds) to put the gamepad in pairing mode, and pair as you would normally.<br />
<br />
GNOME's Settings also provides a graphical interface to pair sixaxis controllers when connected by wire.<br />
<br />
Remember to disconnect the controller when you are done as the controller will stay on when connected and drain the battery.<br />
<br />
{{Note|If the controller does not connect, make sure the bluetooth interface is turned on and the controllers have been trusted. (See [[Bluetooth]])}}<br />
<br />
==== Using Playstation 3 controllers with Steam ====<br />
<br />
{{out of date|Tested connecting PS3 controller via bluetooth and it worked in Steam version 1575605714 and some Steam games without performing the following steps.}}<br />
<br />
For Steam to recognize your controllers, it needs to be able to read their device file. The {{Pkg|steam}} package sets up udev rules for lots of controllers, but not the PlayStation 3 controller (aka. DualShock 3 controller). You can add the rules yourself:<br />
<br />
{{hc<br />
|/etc/udev/rules.d/99-dualshock-3.rules|2=<br />
# DualShock 3 controller, Bluetooth<br />
KERNEL=="hidraw*", KERNELS=="*054C:0268*", MODE="0660", TAG+="uaccess"<br />
<br />
# DualShock 3 controller, USB<br />
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0268", MODE="0660", TAG+="uaccess"<br />
}}<br />
<br />
Make sure your user is in the "input" group:<br />
<br />
{{ic | usermod -aG input yourusername}}<br />
<br />
Reboot your system. Steam should now detect your PlayStation 3 controller.<br />
<br />
==== Using generic/clone controllers ====<br />
<br />
Using generic/clone Dualshock controllers is possible, however there is an issue that may require to install a patched package. The default Bluetooth protocol stack does not detect some of the clone controllers. The {{AUR|bluez-ps3}} package is a version patched to be able to detect them.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Gamepad over network ===<br />
<br />
If you want to use your gamepad with another computer over a network, you can use [https://github.com/moslevin/netstick netstick] to easily do this.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Joystick moving mouse ===<br />
<br />
Sometimes USB gamepad 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 gamepad by itself, you can remove the {{AUR|xf86-input-joystick}} package.<br />
<br />
A more gentle solution is described in [[#Disable joystick from controlling mouse]].<br />
<br />
=== Gamepad is not working in FNA/SDL based games ===<br />
<br />
If you are using a generic non-widely used gamepad you may encounter issues getting the gamepad recognized in games based on SDL. Since [https://github.com/flibitijibibo/FNA/commit/e55742cfe7e38b778a21ed8a12cb2f2081490d8d 14 May 2015], FNA supports dropping a {{ic|gamecontrollerdb.txt}} into the executable folder of the game, for example the [https://github.com/gabomdq/SDL_GameControllerDB SDL_GameControllerDB].<br />
<br />
As an alternative and for older versions of FNA or for SDL you can generate a mapping yourself by downloading the SDL source code via https://libsdl.org/, navigating to {{ic|/test/}}, compile the {{ic|controllermap.c}} program (alternatively install {{AUR|controllermap}}) and run the test. After completing the controllermap test, a guid will be generated that you can put in the {{ic|SDL_GAMECONTROLLERCONFIG}} environment variable which will then be picked up by SDL/FNA games. For example:<br />
<br />
$ export SDL_GAMECONTROLLERCONFIG="030000008f0e00000300000010010000,GreenAsia Inc. USB Joystick ,platform:Linux,x:b3,a:b2,b:b1,y:b0,back:b8,start:b9,dpleft:h0.8,dpdown:h0.0,dpdown:h0.4,dpright:h0.0,dpright:h0.2,dpup:h0.0,dpup:h0.1,leftshoulder:h0.0,leftshoulder:b6,lefttrigger:b4,rightshoulder:b7,righttrigger:b5,leftstick:b10,rightstick:b11,leftx:a0,lefty:a1,rightx:a3,righty:a2,"<br />
<br />
=== Gamepad is not recognized by all programs ===<br />
<br />
Some software, Steam for example, will only recognize the first gamepad it encounters. Due to a bug in the driver for Microsoft wireless periphery devices this can in fact be the bluetooth dongle. If you find you have a {{ic|/dev/input/js*}} and {{ic|/dev/input/event*}} belonging to you keyboard's bluetooth transceiver you can get automatically get rid of it by creating according udev rules.<br />
Create a {{ic|/}}:<br />
{{hc|/etc/udev/rules.d/99-btcleanup.rules|<nowiki><br />
ACTION=="add", KERNEL=="js[0-9]*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/js%n"<br />
ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", KERNELS=="...", ATTRS{bInterfaceSubClass}=="00", ATTRS{bInterfaceProtocol}=="00", ATTRS{bInterfaceNumber}=="02", RUN+="/usr/bin/rm /dev/input/event%n"<br />
</nowiki>}}<br />
Correct the {{ic|<nowiki>KERNELS=="..."</nowiki>}} to match your device. The correct value can be found by running<br />
<br />
# udevadm info -an /dev/input/js0<br />
<br />
Assuming the device in question is {{ic|/dev/input/js0}}. After you placed the rule reload the rules with<br />
<br />
# udevadm control --reload<br />
<br />
Then replug the device making you trouble. The joystick and event devices should be gone, although their number will still be reserved. But the files are out of the way.<br />
<br />
=== Steam Controller not pairing ===<br />
<br />
There are some unknown cases where the packaged udev rule for the Steam controller does not work ({{bug|47330}}). The most reliable workaround is to make the controller world readable. Copy the rule {{ic|/usr/lib/udev/rules.d/70-steam-controller.rules}} to {{ic|/etc/udev/rules.d}} with a later prioritiy and change anything that says {{ic|1=MODE="0660"}} to {{ic|1=MODE="066'''6'''"}} e.g.<br />
<br />
{{hc|/etc/udev/rules.d/99-steam-controller-perms.rules|<nowiki><br />
...<br />
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"<br />
...<br />
</nowiki>}}<br />
<br />
You may have to reboot in order for the change to take effect.<br />
<br />
=== Steam Controller makes a game crash or not recognized ===<br />
<br />
If your Steam Controller is working well in Steam Big Picture mode, but not recognized by a game or the game starts crashing when you plug in the controller, this may be because of the native driver that has been added to the Linux kernel 4.18. Try to unload it, restart Steam and replug the controller.<br />
<br />
The module name of the driver is ''hid_steam'', so to unload it you may perform:<br />
# rmmod hid_steam</div>Faithhttps://wiki.archlinux.org/index.php?title=Gaming&diff=565539Gaming2019-02-02T12:33:14Z<p>Faith: Remove double negative</p>
<hr />
<div>[[Category:Gaming]]<br />
[[da:List of games]]<br />
[[es:List of games]]<br />
[[it:List of games]]<br />
[[ja:ゲーム]]<br />
[[lt:Games]]<br />
[[ru:Gaming]]<br />
[[zh-hans:List of games]]<br />
{{Related articles start}}<br />
{{Related|List of games}}<br />
{{Related|Video game platform emulators}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
This page contains information about running games and related system configuration tips.<br />
<br />
== Game environments ==<br />
<br />
Different environments exist to play games in Linux:<br />
<br />
* Native – games written for Linux.<br />
* Web – games running in a web browser<br />
** HTML5 games use canvas and WebGL technologies and work in all modern browsers<br />
** [[Flash]]-based – you need to install the plugin to play.<br />
* Specialized environments (software emulators) – Required for running software designed for other architectures or systems. See [[Video game platform emulators]] for more details.<br />
** [[Wine]] &ndash; allows running of some Windows games, as well as a large amount of Windows software. Performance in Wine varies, the additional CPU overhead will cause slowdown in some games while in some cases games may run faster. Consult [http://appdb.winehq.org/ Wine AppDB] for game-specific compatibility information.<br />
** [http://www.codeweavers.com/ Crossover Games] &ndash; members of the Codeweavers team are prime supporters of Wine. Using Crossover Games makes the installation & setting up of some games easier, more reliable & even possible, when compared to using other methods. Crossover is a paid commercial product, which also provides a [http://www.codeweavers.com/support/forums/ forum] where the developers are very much involved in the community. <br />
** [[DOSBox]] is a minimal virtual machine which runs a full DOS-compatible environment. It can be used to run classic DOS titles.<br />
** {{Pkg|scummvm}} is an all-in-one engine reimplementation of many classic point-and-click adventure games. A full list of compatible titles can be found on the [http://scummvm.org ScummVM website].<br />
** Similar to ScummVM, engine reimplementations and ports exist for specific titles, such as Doom.<br />
* Virtual machines can be used to install compatible operating systems (such as Windows). [[VirtualBox]] has good 3D support. As an extension of this, if you have compatible hardware you can consider VGA passthrough to a Windows KVM guest, keyword is [https://www.kernel.org/doc/Documentation/vfio.txt "virtual function I/O" (VFIO)], or [[PCI passthrough via OVMF]].<br />
<br />
== Getting games ==<br />
<br />
A good number are available in the [[official repositories]] / the [[AUR]], see [[List of games]].<br />
<br />
=== Digital distribution ===<br />
<br />
Just because games are available for Linux doesn't mean that they are native, they might be pre-packaged with Wine or DOSBox.<br />
<br />
* {{App|[[Steam]]|Digital distribution and communications platform developed by Valve.|https://store.steampowered.com|{{Pkg|steam}}}}<br />
* {{App|[[Wikipedia:itch.io|itch.io]]|Indie game store.|https://itch.io/|{{AUR|itch}}}}<br />
* [https://www.gog.com/games/linux GOG.com]<br />
** GOG.com officially only supports Ubuntu and Linux Mint.<br />
** The {{AUR|lgogdownloader}} package can be used to download GOG titles from the command line.<br />
<br />
== Running games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired.<br />
<br />
=== Multi-screen setups ===<br />
<br />
Running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting games in a separate X server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming using TwinView|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
=== Keyboard grabbing ===<br />
<br />
Many games grab the keyboard, noticeably preventing you from switching windows (also known as alt-tabbing).<br />
<br />
Some SDL games (e.g. Guacamelee) let you disable grabbing by pressing {{ic|Ctrl-g}}.<br />
<br />
To disable keyboard grabbing at X11 level, install the {{AUR|libx11-nokeyboardgrab}}{{Broken package link|package not found}} package.<br />
<br />
{{Note|SDL is known to sometimes not be able to grab the input system. In such a case, it may succeed in grabbing it after a few seconds of waiting.}}<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" out of your game by using {{ic|Ctrl+Alt+F7}}/{{ic|Ctrl+Alt+F8}}, no crashing your primary X session (which may have open work on) in case a game conflicts with the graphics driver. The new X server will be akin a remote access login for the ALSA, so your user need to be part of the {{ic|audio}} group to be able to hear any sound.<br />
<br />
To start a second X server (using the free first person shooter game [http://www.xonotic.org/ Xonotic] as an example) you can simply do: <br />
$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR<br />
This can further be spiced up by using a separate X configuration file:<br />
$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR<br />
A good reason to provide an alternative ''xorg.conf'' here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Xonotic in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised.<br />
<br />
A game starting script making use of Openbox for your home directory or {{ic|/usr/local/bin}} may look like this:<br />
<br />
{{hc|~/game.sh|<nowiki><br />
if [ $# -ge 1 ]; then<br />
game="$(which $1)"<br />
openbox="$(which openbox)"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
</nowiki>}}<br />
<br />
So after a {{ic|chmod +x}} you would be able to use this script like:<br />
<br />
$ ~/game.sh xonotic-glx<br />
<br />
=== Adjusting mouse detections ===<br />
<br />
For games that require exceptional amount of mouse skill, adjusting the [[mouse polling rate]] can help improve accuracy.<br />
<br />
=== Mouse focus in GNOME ===<br />
<br />
{{Merge|GNOME}}<br />
<br />
The 'sloppy' and 'mouse' window-focusing modes in [[GNOME]] are known to cause issues with a variety of games, causing a 'click-through' effect. Users can remedy this problem by switching the focus mode to 'click' (with a tool such as {{Pkg|gnome-tweak-tool}}{{Broken package link|replaced by {{Pkg|gnome-tweaks}}}}), playing in a different desktop environment, or spawing their game in a separate X-session.<br />
<br />
=== Binaural Audio with OpenAL ===<br />
<br />
For games using [[Wikipedia:OpenAL|OpenAL]], if you use headphones you may get much better positional audio using OpenAL's [[Wikipedia:Head-related transfer function|HRTF]] filters. To enable, run the following command:<br />
<br />
echo "hrtf = true" >> ~/.alsoftrc<br />
<br />
Alternatively, install {{AUR|openal-hrtf}} from the AUR, and edit the options in /etc/openal/alsoftrc.conf<br />
<br />
For Source games, the ingame setting `dsp_slow_cpu` must be set to `1` to enable HRTF, otherwise the game will enable its own processing instead. You will also either need to set up Steam to use native runtime, or link its copy of openal.so to your own local copy. For completeness, also use the following options:<br />
<br />
dsp_slow_cpu 1 # Disable in-game spatialiazation<br />
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds<br />
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it does not interfere with your perception of the sound effects.<br />
snd_pitchquality 1 # Use high quality sounds<br />
<br />
=== Tuning PulseAudio ===<br />
<br />
If you are using [[PulseAudio]], you may wish to tweak some default settings to make sure it is running optimally.<br />
<br />
==== Enabling realtime priority and negative nice level ====<br />
<br />
Pulseaudio is built to be run with realtime priority, being an audio daemon. However, because of security risks of it locking up the system, it is scheduled as a regular thread by default. To adjust this, first make sure you are in the {{ic|audio}} group. Then, uncomment and edit the following lines in {{ic|/etc/pulse/daemon.conf}}:<br />
<br />
{{hc|1=/etc/pulse/daemon.conf|2=<br />
high-priority = yes<br />
nice-level = -11<br />
<br />
realtime-scheduling = yes<br />
realtime-priority = 5}}<br />
<br />
and restart pulseaudio.<br />
<br />
==== Using higher quality remixing for better sound ====<br />
<br />
PulseAudio on Arch uses speex-float-0 by default to remix channels, which is considered a 'medium-low' quality remixing. If your system can handle the extra load, you may benefit from setting it to one of the following instead:<br />
<br />
resample-method = speex-float-10<br />
<br />
==== Matching hardware buffers to Pulse's buffering ====<br />
<br />
Matching the buffers can reduce stuttering and increase performance marginally. See [http://forums.linuxmint.com/viewtopic.php?f=42&t=44862 here] for more details.<br />
<br />
=== Double check your CPU frequency scaling settings ===<br />
<br />
If your system is currently configured to properly insert its own cpu frequency scaling driver, the system sets the default governor to Ondemand. By default, this governor only adjusts the clock if the system is utilizing 95% of its CPU, and then only for a very short period of time. This saves power and reduces heat, but has a noticeable impact on performance. You can instead only have the system downclock when it is idle, by tuning the system governor. To do so, see [[Cpufrequtils#Tuning the ondemand governor]].<br />
<br />
== Improving performance ==<br />
<br />
See also main article: [[Improving performance]]. For Wine programs, see [[Wine#Performance]].<br />
<br />
=== Improving frame rates and responsiveness with scheduling policies ===<br />
<br />
Most games can benefit if given the correct scheduling policies for the kernel to prioritize the task. These policies should ideally be set per-thread by the application itself.<br />
<br />
For programs which do not implement scheduling policies on their own, application known as {{Pkg|schedtool}}, and its associated daemon {{AUR|schedtoold}} can handle many of these tasks automatically.<br />
<br />
To edit what programs relieve what policies, simply edit {{ic|/etc/schedtoold.conf}} and add the program followed by the ''schedtool'' arguments desired.<br />
<br />
==== Policies ====<br />
<br />
{{ic|SCHED_ISO}} (only implemented in BFS/MuQSSPDS schedulers found in -pf and -ck [[kernel]]s) – will not only allow the process to use a maximum of 80 percent of the CPU, but will attempt to reduce latency and stuttering wherever possible. Most if not all games will benefit from this:<br />
<br />
bit.trip.runner -I<br />
<br />
{{ic|SCHED_FIFO}} provides an alternative, that can even work better. You should test to see if your applications run more smoothly with {{ic|SCHED_FIFO}}, in which case by all means use it instead. Be warned though, as {{ic|SCHED_FIFO}} runs the risk of starving the system! Use this in cases where -I is used below:<br />
<br />
bit.trip.runner -F -p 15<br />
<br />
==== Nice levels ====<br />
<br />
Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is reccommended for most multimedia tasks, including games:<br />
<br />
bit.trip.runner -n -4<br />
<br />
==== Core affinity ====<br />
<br />
There is some confusion in development as to whether the driver should be multithreading, or the program. In any case where they both attempt it, it causes drops in framerate and crashes. Examples of this include a number of modern games, and any Wine program which is running with [[Wikipedia:OpenGL Shading Language|GLSL]] enabled. To select a single core and allow only the driver to handle this process, simply use the {{ic|-a 0x''#''}} flag, where ''#'' is the core number, e.g.:<br />
<br />
bit.trip.runner -a 0x1<br />
<br />
uses first core.<br />
<br />
Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for:<br />
<br />
bit.trip.runner -a 0x5<br />
<br />
which use virtual cores 0101, or 1 and 3.<br />
<br />
==== General case ====<br />
<br />
For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage.<br />
For a general case:<br />
<br />
bit.trip.runner -I -n -4<br />
Amnesia.bin64 -I -n -4<br />
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled<br />
<br />
etc.<br />
<br />
==== Optimus, and other helping programs ====<br />
<br />
As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as ''reverse scheduling'', it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from {{ic|SCHED_FIFO}}, since rarely consumes the whole CPU and needs higher prioritization when possible.<br />
<br />
optirun -I -n -5<br />
wineserver -F -p 20 -n 19<br />
steam.exe -I -n -5</div>Faith