Difference between revisions of "Game Controller Support in Linux"

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search
m (→‎Utilities for Unsupported Games)
m (→‎evdev)
 
(27 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
Steam support will be referenced
 
Steam support will be referenced
 +
 +
== controller system interface methods ==
 +
How the game application recognize and use the game controller depends as there are different ways. 
 +
# Joystick API - /dev/input/jsX
 +
# evdev API - /dev/input/eventX (''the event number will typically not correspond to the js number'')
 +
# raw input device access - /dev/hidraw
 +
# Direct USB Communication or custom driver
 +
 +
=== Joystick API ===
 +
This is an older method for games to use the game controller in Linux.  You can use jtest or joyutils to test this.
 +
 +
=== evdev ===
 +
This is what the antimicro utility uses along with most modern games such as many of those in Steam (Steam itself).  If you set file permissions on the evdev devices to 000 then antimicro and these games will not detect the game controller.
 +
 +
evdev API - The new 'evdev' API can be tested using the SDL2 joystick test application or using evtest.
 +
 +
Now the X.Org server is using the evdev driver and sometimes the default settings for the evdev joystick makes it appear as a mouse or keyboard.
 +
 +
A game typically queries the available input devices when it launches and keeps those devices open for the duration of its runtime even if you change the file permissions of an evdev device to 000 (chmod 000 eventX). This is typical behavior for applications using the evdev event interface. Even if the permissions on /dev/input/eventX are changed during runtime, the game retains access because it already has the file descriptor open.
 +
 +
To locate the evdev device of the game controller use 'evtest' which will show the devices as '/dev/input/eventX' and allow you to select one to view input.
 +
evdev
 +
 +
=== raw input ===
 +
To identify if your controller is being used through a raw input method:
 +
 +
ls /dev/hidraw*
 +
lsusb -v | grep -i -A 10 "HID"
 +
 +
If your game controller appears in these outputs, it indicates alternate access points.
 +
 +
=== direct USB communication ===
 +
Some applications bypass standard input subsystems (like evdev or hidraw) and directly communicate with the controller via USB. This is typically done using libusb or similar libraries, which allow applications to interact with USB devices directly.
 +
 +
Look in /dev/bus/usb to find the game controller.  You can identify which BUS and DEVICE by using the 'lsusb' command.  The BUS refers to which directory under /dev/bus/usb and the Device refers to device file.  For example, Bus 001 Device 009 can be hidden via:
 +
sudo chmod 000 /dev/bus/usb/001/009
  
 
== connect and test usb game controller ==
 
== connect and test usb game controller ==
Line 19: Line 55:
 
  udevadm monitor -kp|grep DEVNAME
 
  udevadm monitor -kp|grep DEVNAME
 
You might be interested in the lines /dev/input so you can see where is assigned.
 
You might be interested in the lines /dev/input so you can see where is assigned.
−
 
−
=== Joystick API vs evdev API ===
 
−
Joystick API - Use jtest or joyutils
 
−
 
−
evdev API - The new 'evdev' API can be tested using the SDL2 joystick test application or using evtest.
 
  
 
== Customization, Mapping, and Utilities for Unsupported Games ==
 
== Customization, Mapping, and Utilities for Unsupported Games ==
Line 30: Line 61:
  
 
===QJoyPad===
 
===QJoyPad===
−
There are a number of utilities that allow you to map keyboard and mouse actions to the controller.  One that is highly effective and easy to configure is [http://qjoypad.sourceforge.net/ QJoyPad]
+
There are a number of utilities that allow you to map keyboard and mouse actions to the controller.  One that is <s>effective</s> and easy to configure is [http://qjoypad.sourceforge.net/ QJoyPad]
 +
 
 +
Issues which should be mentioned: QJoyPad interface shows more buttons than controller.  Sometimes so many false buttons are displayed the application control bars extend beyond the size of the screen.  Activating both Turbo and sticky on a mapped key doesn't work.  QJoyPad is too buggy.
  
 
QJoyPad:
 
QJoyPad:
Line 36: Line 69:
  
 
There are limitations in using these utilities.  Keyboard events mapped have the same limitations as playing with keyboard except the controller platform more readily exhibit these limitations.  For example, multiple events simultaneously on the controller cannot be processed at the same time.  So if you are pushing buttons to fire while trying jump, strafe, and duck you might notice some of these actions will not occur.
 
There are limitations in using these utilities.  Keyboard events mapped have the same limitations as playing with keyboard except the controller platform more readily exhibit these limitations.  For example, multiple events simultaneously on the controller cannot be processed at the same time.  So if you are pushing buttons to fire while trying jump, strafe, and duck you might notice some of these actions will not occur.
 +
 +
The QJoyPad utility uses "Joystick API" and will NOT detect the game controller unless the Joystick API device is present and readable.  For example:
 +
 +
If our game controller is js0 event9 with the following permissions, QJoyPad will NOT recognize the game controller.  (hidden)
 +
crw-rw----  1 root input 13, 73 Feb  9 15:12 event9
 +
c---------  1 root input 13,  0 Feb  9 15:12 js0
 +
 +
QJoyPad will NOT recognize the game controller. (hidden)
 +
c---------  1 root input 13, 73 Feb  9 15:12 event9
 +
crw-rw----  1 root input 13,  0 Feb  9 15:12 js0
 +
 +
QJoyPad will recognize the game controller. (correct)
 +
c---------  1 root input 13, 73 Feb  9 15:12 event9
 +
crw-rw-r--  1 root input 13,  0 Feb  9 15:12 js0
 +
 +
 +
'''It has to be sudo chmod 664 js0''' - exceptions depending on certain group permissions, however, typically 660 is not enough.
 +
 +
===AntiMicro / AntiMicroX===
 +
UPDATE: ''The anitmicro repo is currently unmaintained. Contributors are maintaining an extended and updated Linux version, antimicrox at https://github.com/AntiMicroX/antimicroX.  I recently downloaded antimicrox-3.2.1-x86_64.deb on a Mint 20.1 system and it installed correctly. 
 +
''
 +
Better alternative to QJoyPad, however, not in the official repositories.  Download from web site.  Debian package manager. 
 +
* wget https://launchpad.net/~mdeguzis/+archive/ubuntu/libregeek/+files/antimicro_2.23~artful-1_amd64.deb
 +
* antimicro_2.23~artful-1_amd64.deb compatible with Mint 19.2 Bionic
 +
 +
Testing antimicro as an alternative to QJoyPad on Linux Mint 19.2 - antimicro is proving to be a superior utility for mapping keystrokes to a game controller.  QJoyPad fails to functioned as claimed.  Both "Sticky" key (simulating the holding down of a keyboard key) and "rapid fire" can be used together with antimicro.  Although QJoyPad claims to have the ability to use both enhancements together, in practice it does not work with QJoyPad.
 +
 +
[[File:antimicro01.png]]
  
 
== steam support ==
 
== steam support ==
Line 60: Line 121:
  
 
If you do not want Steam to recognize it so you can use QJoyPad then you must lock steam out of access to the device.  When you use Steam settings to disable the controller many games still access the controller though Steam settings.  The Steam game controller configuration is problematic and difficult to use.  Sometimes it is necessary to prevent Steam from having any access to the device so you can use another utility such as QJoyPad.
 
If you do not want Steam to recognize it so you can use QJoyPad then you must lock steam out of access to the device.  When you use Steam settings to disable the controller many games still access the controller though Steam settings.  The Steam game controller configuration is problematic and difficult to use.  Sometimes it is necessary to prevent Steam from having any access to the device so you can use another utility such as QJoyPad.
 +
 +
One method that can be used to keep an application (such as Steam) from reading a game controller is to disable read access for the corresponding device file under /dev/input.  You will have to change the permissions on the device before launching Steam. 
  
 
* event14 - Steam recognizes the controller via event14 - if you lock steam out of /dev/input/event14 then Steam will not recognize the controller.  This has to be done on every reboot.
 
* event14 - Steam recognizes the controller via event14 - if you lock steam out of /dev/input/event14 then Steam will not recognize the controller.  This has to be done on every reboot.
Line 74: Line 137:
  
 
If you disconnect and reconnect the controller, or if you reboot the computer the permissions will be restored and you will have to use console to execute the chmod command again.
 
If you disconnect and reconnect the controller, or if you reboot the computer the permissions will be restored and you will have to use console to execute the chmod command again.
 +
 +
== Troubleshooting ==
 +
reference
 +
/etc/udev/rules.d
 +
/lib/udev/rules.d
 +
/lib/udev/rules.d/60-steam-input.rules
 +
/lib/udev/rules.d/60-steam-vr.rules
 +
/lib/udev/hwdb.d/70-joystick.hwdb
 +
/lib/udev/rules.d/51-these-are-not-joysticks-rm.rules
 +
/lib/udev/rules.d/60-joystick.rules
 +
/lib/udev/rules.d/70-joystick.rules
 +
/lib/udev/rules.d/80-stelladaptor-joystick.rules
 +
 +
=== identify input devices ===
 +
There are tools to identify and test input devices, those things under
 +
/dev/input
 +
One useful tool is evtest
 +
sudo apt install evtest
 +
evtest sample output
 +
root@ackbar:/dev/input# evtest
 +
No device specified, trying to scan all of /dev/input/event*
 +
Available devices:
 +
/dev/input/event0: Sleep Button
 +
/dev/input/event1: Lid Switch
 +
/dev/input/event2: Power Button
 +
/dev/input/event4: Video Bus
 +
/dev/input/event5: USB Gamepad
 +
/dev/input/event7: PS/2 Generic Mouse
 +
Select the device event number [0-7]:
 +
 +
=== Udev Joystick Blacklist ===
 +
Fix for keyboard/mouse/tablet being detected as joystick.  There are several devices that, although recognized by kernel as joysticks, are not joysticks.  Use "/lib/udev/rules.d/51-these-are-not-joysticks-rm.rules" to prevent the non-functional /dev/input/js* and /dev/input/event* devices from being recognized as joysticks.
 +
 +
see: https://awesomeopensource.com/project/denilsonsa/udev-joystick-blacklist
 +
 +
Turns out [[Mint Linux]] 18.1 placed a copy of 51-these-are-not-joysticks-rm.rules at /lib/udev/rules.d (probably inherited from it's parent distro Ubuntu 16.04), and it is outdated. 
 +
 +
See https://github.com/denilsonsa/udev-joystick-blacklist/issues/30
 +
 +
Default rule files you should never edit are supposed to be located here:
 +
* /lib/udev/rules.d
 +
And custom rules you can create and edit which will override any existing rules from /lib/udev should be located here:
 +
* /etc/udev/rules.d/*.rules
 +
 +
It is important to know that files with identical file names replace each other in active memory. Files in /etc have the highest priority and take precedence over files with the same name in /lib. 
 +
 +
Udev rules written by the administrator go in /etc/udev/rules.d/, and their file name has to end with .rules. The default udev rules are found in /lib/udev/rules.d/ (or /usr/lib/udev/rules.d). If there are two files by the same name under /lib and /etc, the ones in /etc take precedence.
 +
 +
A udev rule can match one of the following:
 +
#    KERNEL - match against the kernel name for the device
 +
#    SUBSYSTEM - match against the subsystem of the device
 +
#    DRIVER - match against the name of the driver backing the device
 +
 +
see also: evdev ignore on
  
 
== related ==
 
== related ==

Latest revision as of 14:43, 17 November 2024

Debian based distributions including Ubuntu and Mint will be referenced.

Steam support will be referenced

controller system interface methods

How the game application recognize and use the game controller depends as there are different ways.

  1. Joystick API - /dev/input/jsX
  2. evdev API - /dev/input/eventX (the event number will typically not correspond to the js number)
  3. raw input device access - /dev/hidraw
  4. Direct USB Communication or custom driver

Joystick API

This is an older method for games to use the game controller in Linux. You can use jtest or joyutils to test this.

evdev

This is what the antimicro utility uses along with most modern games such as many of those in Steam (Steam itself). If you set file permissions on the evdev devices to 000 then antimicro and these games will not detect the game controller.

evdev API - The new 'evdev' API can be tested using the SDL2 joystick test application or using evtest.

Now the X.Org server is using the evdev driver and sometimes the default settings for the evdev joystick makes it appear as a mouse or keyboard.

A game typically queries the available input devices when it launches and keeps those devices open for the duration of its runtime even if you change the file permissions of an evdev device to 000 (chmod 000 eventX). This is typical behavior for applications using the evdev event interface. Even if the permissions on /dev/input/eventX are changed during runtime, the game retains access because it already has the file descriptor open.

To locate the evdev device of the game controller use 'evtest' which will show the devices as '/dev/input/eventX' and allow you to select one to view input. 

evdev

raw input

To identify if your controller is being used through a raw input method: 

ls /dev/hidraw*
lsusb -v | grep -i -A 10 "HID"

If your game controller appears in these outputs, it indicates alternate access points.

direct USB communication

Some applications bypass standard input subsystems (like evdev or hidraw) and directly communicate with the controller via USB. This is typically done using libusb or similar libraries, which allow applications to interact with USB devices directly.

Look in /dev/bus/usb to find the game controller. You can identify which BUS and DEVICE by using the 'lsusb' command. The BUS refers to which directory under /dev/bus/usb and the Device refers to device file. For example, Bus 001 Device 009 can be hidden via: 

sudo chmod 000 /dev/bus/usb/001/009

connect and test usb game controller

sudo joystick
apt install jstest-gtk

If detected by the kernel joystick driver your game controller will appear as a device in /dev/input and will have a name in /dev/input/by-id.

  • /dev/input/jsX (Joystick API) maps to the Joystick API interface
  • /dev/input/event* (evdev API) maps to the evdev interface (this also includes other input devices such as mice and keyboards).

legacy Joystick API has names ending with -joystick while the evdev have names ending with -event-joystick

monitor for detection when connected

When you connect your USB hid device, in this case a game controller, you might be interested in knowing if the kernel detects it. 

udevadm monitor -kp|grep DEVNAME

You might be interested in the lines /dev/input so you can see where is assigned.

Customization, Mapping, and Utilities for Unsupported Games

jtest-gtk

You can use jtest-gtk to change the mapping for your game controller.

QJoyPad

There are a number of utilities that allow you to map keyboard and mouse actions to the controller. One that is effective and easy to configure is QJoyPad

Issues which should be mentioned: QJoyPad interface shows more buttons than controller. Sometimes so many false buttons are displayed the application control bars extend beyond the size of the screen. Activating both Turbo and sticky on a mapped key doesn't work. QJoyPad is too buggy.

QJoyPad: 

sudo apt install qjoypad

There are limitations in using these utilities. Keyboard events mapped have the same limitations as playing with keyboard except the controller platform more readily exhibit these limitations. For example, multiple events simultaneously on the controller cannot be processed at the same time. So if you are pushing buttons to fire while trying jump, strafe, and duck you might notice some of these actions will not occur.

The QJoyPad utility uses "Joystick API" and will NOT detect the game controller unless the Joystick API device is present and readable. For example:

If our game controller is js0 event9 with the following permissions, QJoyPad will NOT recognize the game controller. (hidden) 

crw-rw----  1 root input 13, 73 Feb  9 15:12 event9
c---------  1 root input 13,  0 Feb  9 15:12 js0

QJoyPad will NOT recognize the game controller. (hidden) 

c---------  1 root input 13, 73 Feb  9 15:12 event9
crw-rw----  1 root input 13,  0 Feb  9 15:12 js0

QJoyPad will recognize the game controller. (correct) 

c---------  1 root input 13, 73 Feb  9 15:12 event9
crw-rw-r--  1 root input 13,  0 Feb  9 15:12 js0


It has to be sudo chmod 664 js0 - exceptions depending on certain group permissions, however, typically 660 is not enough.

AntiMicro / AntiMicroX

UPDATE: The anitmicro repo is currently unmaintained. Contributors are maintaining an extended and updated Linux version, antimicrox at https://github.com/AntiMicroX/antimicroX. I recently downloaded antimicrox-3.2.1-x86_64.deb on a Mint 20.1 system and it installed correctly. Better alternative to QJoyPad, however, not in the official repositories. Download from web site. Debian package manager.

Testing antimicro as an alternative to QJoyPad on Linux Mint 19.2 - antimicro is proving to be a superior utility for mapping keystrokes to a game controller. QJoyPad fails to functioned as claimed. Both "Sticky" key (simulating the holding down of a keyboard key) and "rapid fire" can be used together with antimicro. Although QJoyPad claims to have the ability to use both enhancements together, in practice it does not work with QJoyPad.

Antimicro01.png

steam support

If Steam recognizes your controller you should not use QJoyPad also as both will interact with your game. Close QJoyPad to use the Steam game controller. If you wish to disable Steam from configuring your game controller and continue to use QJoyPad this is possible however simply disabling the controller within Steam settings is not effective. How to do this from the command line is discussed below.

Sony Playstation PS3 Sixaxis Support

Steam on Linux does not automatically recognize the controller.

You have different options to use the controller with games in Steam. The easiest is QJoyPad.

Success in game control achieved with QJoyPad 

sudo apt install qjoypad

Steam Controller Family

Tested with the EasySMX controller designed to work with multiple gaming platforms including XBox and PS3. When connected it will automatically be recognized by Steam. This controller will be recognized as an XBox controller by Steam. 

$ ls -laF /dev/input/by-id|grep -i game
lrwxrwxrwx 1 root root  10 Dec  7 09:13 usb-HJC_Game_GAME_FOR_WINDOWS___00000000-event-joystick -> ../event14
lrwxrwxrwx 1 root root   6 Dec  7 09:13 usb-HJC_Game_GAME_FOR_WINDOWS___00000000-joystick -> ../js0

Note the two associated devices for the controller: event14 and js0

NOTE: Your assignments may be different. When reading substitute "event14" for eventXX representing the number for the device on your system. Also, you may have js1 instead of js0. The assumption here is only one controller is connected.

If you do not want Steam to recognize it so you can use QJoyPad then you must lock steam out of access to the device. When you use Steam settings to disable the controller many games still access the controller though Steam settings. The Steam game controller configuration is problematic and difficult to use. Sometimes it is necessary to prevent Steam from having any access to the device so you can use another utility such as QJoyPad.

One method that can be used to keep an application (such as Steam) from reading a game controller is to disable read access for the corresponding device file under /dev/input. You will have to change the permissions on the device before launching Steam.

  • event14 - Steam recognizes the controller via event14 - if you lock steam out of /dev/input/event14 then Steam will not recognize the controller. This has to be done on every reboot.
  • js0 - QJoyPad recognizes the controller via js0 - if you lock QJoyPad out of /dev/input/js0 then the utility will notify you it does not believe a controller is present.

Adjust file permissions to lock Steam out of access to the controller. Make sure Steam is closed. 

$ sudo chmod 000 /dev/input/event14
$ ls -laF|grep event14
c---------+  1 root input 13, 78 Dec  7 09:59 event14

We can now see that event14 file permissions do not permit access by any user.

Open QJoyPad and it will recognize the controller. Open Steam and Steam will be unaware of the controller, thus not interfering with its QJoyPad configuration.

If you disconnect and reconnect the controller, or if you reboot the computer the permissions will be restored and you will have to use console to execute the chmod command again.

Troubleshooting

reference 

/etc/udev/rules.d
/lib/udev/rules.d
/lib/udev/rules.d/60-steam-input.rules
/lib/udev/rules.d/60-steam-vr.rules
/lib/udev/hwdb.d/70-joystick.hwdb
/lib/udev/rules.d/51-these-are-not-joysticks-rm.rules
/lib/udev/rules.d/60-joystick.rules
/lib/udev/rules.d/70-joystick.rules
/lib/udev/rules.d/80-stelladaptor-joystick.rules

identify input devices

There are tools to identify and test input devices, those things under 

/dev/input

One useful tool is evtest 

sudo apt install evtest

evtest sample output root@ackbar:/dev/input# evtest No device specified, trying to scan all of /dev/input/event* Available devices: 

/dev/input/event0:	Sleep Button
/dev/input/event1:	Lid Switch
/dev/input/event2:	Power Button
/dev/input/event4:	Video Bus
/dev/input/event5:	USB Gamepad 
/dev/input/event7:	PS/2 Generic Mouse
Select the device event number [0-7]:

Udev Joystick Blacklist

Fix for keyboard/mouse/tablet being detected as joystick. There are several devices that, although recognized by kernel as joysticks, are not joysticks. Use "/lib/udev/rules.d/51-these-are-not-joysticks-rm.rules" to prevent the non-functional /dev/input/js* and /dev/input/event* devices from being recognized as joysticks.

see: https://awesomeopensource.com/project/denilsonsa/udev-joystick-blacklist

Turns out Mint Linux 18.1 placed a copy of 51-these-are-not-joysticks-rm.rules at /lib/udev/rules.d (probably inherited from it's parent distro Ubuntu 16.04), and it is outdated.

See https://github.com/denilsonsa/udev-joystick-blacklist/issues/30

Default rule files you should never edit are supposed to be located here:

  • /lib/udev/rules.d

And custom rules you can create and edit which will override any existing rules from /lib/udev should be located here:

  • /etc/udev/rules.d/*.rules

It is important to know that files with identical file names replace each other in active memory. Files in /etc have the highest priority and take precedence over files with the same name in /lib.

Udev rules written by the administrator go in /etc/udev/rules.d/, and their file name has to end with .rules. The default udev rules are found in /lib/udev/rules.d/ (or /usr/lib/udev/rules.d). If there are two files by the same name under /lib and /etc, the ones in /etc take precedence.

A udev rule can match one of the following:

  1. KERNEL - match against the kernel name for the device
  2. SUBSYSTEM - match against the subsystem of the device
  3. DRIVER - match against the name of the driver backing the device

see also: evdev ignore on

related

Retrieved from "http://wiki.robotz.com/index.php?title=Game_Controller_Support_in_Linux&oldid=22994"