Generic Usb Joystick To Xinput
Hayley Sweigard
/dev/input/jsX maps to the Joystick API interface and /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 /dev/input/by-id/ and /dev/input/by-path/ where the legacy Joystick API has names ending with -joystick while the evdev have names ending with -event-joystick.
While SDL1 defaults to evdev interface you can force it to use the old Joystick API by setting the environment variable SDL_JOYSTICK_DEVICE=/dev/input/js0. This can help many games such as X3. SDL2 supports only the new evdev interface.
As you can see, there are many different modules related to getting your joystick working in Linux, so everything is not covered here. Please have a look at the documentation mentioned above for details.
You need to load a module for your gameport (ns558, emu10k1-gp, cs461x, etc...), a module for your joystick (analog, sidewinder, adi, etc...), and finally the kernel joystick device driver (joydev). You can load the module at boot, or simply modprobe it. The gameport module should load automatically, as this is a dependency of the other modules.
You need to get USB working, and then modprobe your gamepad driver, which is usbhid, as well as joydev. If you use a usb mouse or keyboard, usbhid will be loaded already and you just have to load the joydev module.
There are a lot of applications that can test this old API, jstest from the 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 > Input Devices > Game Controller. There is jstest-gtk-gitAUR as an alternative.
The new 'evdev' API can be tested using the SDL2 joystick test application or using evtest from evtest or evtest-qt from evtest-qt-gitAUR. Install sdl2-jstest-gitAUR[broken link: package not found] and then run sdl2-jstest --test 0. Use sdl2-jstest --list to get IDs of other controllers if you have multiple ones connected.
Go to -tester.com/. Currently, testing vibration and producing a visual of the gamepad is supported in Chromium but not Firefox. Additionally, as of version 107.0.5304.121-1, Chromium can read Joystick devices but not evdev.
1000 is the default value, but you can set anything between 0 and {{30000. To get the axis number see the "Testing Your Configuration" section of this article.If you already have an option with a specific axis just type in the deadzone=value at the end of the parameter separated by a space.
The easiest way is using jstest-gtk from jstest-gtk-gitAUR. Select the joystick you want to edit, click the Properties button. On this new window, click the Calibration button (do not click Start Calibration after that). You can then set the CenterMin and CenterMax values, which control the center deadzone, and 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.
If the commands above give you an empty output, it could be because your controller is connected via Bluetooth, making these unique attributes only visible on the parent device(s). To mitigate this, you could try finding other unique attributes by running:
Imagine that you tested your gamepad with evtest-qt, and find out that your left joystick cannot reach the maximum read value when you direct it to top most position. The side effect of this is that in some games (for example, HITMAN 2) the character cannot run.
Run xboxdrv and determine how the problematic axis is called. In this case it is Y1. Now try to direct it to top most position several times, and determine the lowest value that you saw. Imagine it is 29426. Now to be on a safe side, we take the value that is lower than that, like 29000. Run the command:
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. You can now see in jstest that the values of axis 1 (corresponds to vertical axis of left joystick) is read from 0 to -32767, and in evtest-qt that you can reach the maximum value. And your character in game can run.
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.
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.
You can also modify the responsiveness by setting the sen (sensitivity) parameter. 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.
If you want to play games with your gamepad, you might want to disable its joystick control over mouse cursor. To do this, edit /etc/X11/xorg.conf.d/51-joystick.conf (create if it does not exists) so that it looks like this:
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 kodi version 11.0 and joy2keyAUR 1.6.3-1, this setup no longer worked and the following was created for letting Xorg handle joystick events.
Gamepads can be remapped for SDL2 applications using the SDL_GAMECONTROLLERCONFIG environment variable. For each line, it includes the gamepad's GUID, a name, button / axis mappings and a platform. The controller's GUID can be retreived by installing sdl2-jstest-gitAUR[broken link: package not found] and then running sdl2-jstest --list.
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 the following sections thoroughly!
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:
Dolphin Emulator has a 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".
The hid-nintendo kernel HID driver was mainlined in kernel 5.16. If you are using an earlier kernel, you will need to install the DKMS module named hid-nintendo-dkmsAUR. 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.
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. joycond-gitAUR 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.
Some games and emulators are hardcoded to work with an Xbox 360 controller, and will not work with other controllers. To get around this, you need to create a virtual Xbox 360 controller that emulates the expected interface, but is bound to your controller's inputs. This can be done with Steam Input or xboxdrv.
By default, SDL2 maps buttons on Nintendo controllers according to the gamepad's label instead of the button's position. This is enabled by the SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS setting, which defaults to 1 for controllers known to use the Nintendo button layout,[2] and 0 for other controllers.[3] This behavior can be overridden for all controllers by setting the SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS environment variable. For example, if Nintendo's conception of A/B and X/Y is undesirable, set SDL_HINT_GAMECONTROLLER_USE_BUTTON_LABELS=0.
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 xboxdrvAUR, bluez and bluez-utils. You should connect it in gamepad mode (if there are different modes, choose the gamepad one). Technically it is ready to be used, but in most cases games would not recognize it, and you would have to map it individually for every application. The best way to simplify it and make it work with all applications is to mimic Microsoft X360 controller with xboxdrvAUR.Once connected you can create a udev rule to give it a persistent name, that would come in handy when setting it up.
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 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.
c80f0f1006