Talk:Gamepad

From ArchWiki

Playstation 3 Controllers via Bluetooth

when creating the udev rule, what the address is supposed to be is unclear, as one can confuse the address of the bluetooth dongle and ps3 controller, so I feel this should be specified.

Additionally, simply putting in the bluetooth address for the udev rule for the ps3 controller does not appear to work. --Ase1590 (talk) 20:21, 16 February 2015 (UTC)Reply[reply]

It is quite obvious it is the address of the PS3 controller which should be specified here, I mean, why would you put the bluetooth controller address here? It would be a one-word change, anyways. But more refractoring is needed here, since the current Wiki page is self-contradicting and under two (and more if you count all PS3/4, Dualshock and Sixaxis) subheadings here, which should be combined. Under "PlayStation 3/4 controller" it is claimed that the process should be automatic and no udev rule creation is necessary. However under "PlayStation 3 controller via Bluetooth" the udev rule you refer to is mentioned. Is it required, or not? No matter wht I do, I can not get any of my Dualshock 3 controllers to work at the moment; though, it is certainly possible, that they are (carefully made) aftermarket knock-offs. I have no access to a real PS3 with confirmed original gamepads. Wild Penguin (talk) 13:57, 22 July 2018 (UTC)Reply[reply]

After a lot of trouble, I finally achieved to connect my two PS3 controllers to my computer. I can confirm that the udev rule isn't necessary. The only thing I had to do was to install bluez-plugins and that step isn't mentioned on the wiki. I think I will proceed to a full refactoring of the PS3/PS4 bluetooth connection sections. I'm waiting until my PS4 controller arrives so I can confirm the same procedure works for it Paragoumba (talk) 10:56, 2 June 2020 (UTC)Reply[reply]

Xbox 360 controllers

I own an Xbox 360 wired controller. A year ago I had no success with using only the xpad module and had to use the userspace xboxdrv driver with mixed success.

I am now pleasantly surprised to see that the Xbox 360 wired controller works with the xpad module only, without any other configuration. In particular, the issues that we list, "incorrect button mapping. (discussion in Steam bugtracker)" and "not-working sync. All four leds keep blinking, but controller works. (discussion in Arch Forum)", seem to be fixed, at least for a single-controller setup.

Should we update the text to reflect that? Suridaj (talk) 22:52, 6 June 2015 (UTC)Reply[reply]

Sure, just preserve old texts as a "if you encounter problems, you can fix them as follows" Tomato (talk) 07:52, 7 June 2015 (UTC)Reply[reply]


Recently spent a couple days getting my wireless controller to work, specifically with steam games. It was acting real wonky, but after much searching I found a reddit post with a configuration that worked:

/etc/default/xboxdrv/
[xboxdrv]
silent = true
device-name = "Xbox 360 Wireless Receiver"
mimic-xpad = true
deadzone = 4000

[xboxdrv-daemon]
dbus = disabled

Should this be added under the xboxdrv section? Raku (talk) 22:58, 4 September 2016 (UTC)Reply[reply]

Please do. This article is badly cluttered at the moment and needs some rewriting, but its better to have that information present than not. Silverhammermba (talk) 18:23, 6 September 2016 (UTC)Reply[reply]

iPEGA PG-9017S

I made a config[1] for bluetooth gamepad. This can be used as example. NeoTheFox (talk) 09:39, 11 November 2015 (UTC)Reply[reply]

Steam controller udev rules

Note: Related bug report: FS#47330

I've just undone these edits which add different udev rules for the Steam controller. This shouldn't be necessary because it should work with the rules provided by the steam package.

To the editor: are you absolutely sure they don't work for you? Could you try again by reinstalling the steam package, and making sure the rule is as follows:

/usr/lib/udev/rules.d/80-steam-controller-permission.rules
#USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"
KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", TAG+="uaccess"

Also make sure there are no other rules in either /etc/udev/rules.d/ or /usr/lib/udev/rules.d/ that might conflict with the one above. You might need to restart your computer before it works.

This rule really should work. It is also used by Ubuntu and other Linux distro's. Please let me know the results.

-- Lonaowna (talk) 23:27, 9 December 2015 (UTC)Reply[reply]

The rule is there in /usr/lib/udev/rules.d, however it seems some games don't recognize the controller with it. TokiTori 2+ worked before I removed my custom rule (and restarted) now it doesn't get see the controller at all.
If I look at /dev/uinput it's root:root only. Do I need to be in some group for this to work?
-- Almindor (talk) 23:27, 10 December 2015 (UTC)Reply[reply]
The uaccess tag should automate this, and give everyone who is locally logged in permission to the controller (similar to how you can run poweroff as a regular user, when logged in locally, but not when logged in via e.g. SSH).
You can see if this works by running getfacl /dev/uinput: your user should show up with rw- permissions.
It seems to work well on my machine, and all controller-enabled games seem to work. Unfortunately I can't test TokiTori 2+ as I don't have it (and the demo doesn't support Linux for some reason?). Are there any more games you are having issues with?
If you're absolutely sure that it doesn't work with the rule provided by the steam package but it does with the other one, we can keep it on this page as a backup, but I rather have everything works out-of-the-box. :)
-- Lonaowna (talk) 12:24, 13 December 2015 (UTC)Reply[reply]
I've done some more digging using strace on Toki Tori and using getfacl
It seems getfacl gives mostly identical results, only difference is the group section has no permissions when using the steam package rules only. But my user has rw in both cases.
What is more interesting is that by using strace I've compared all open syscalls when running Toki Tori and I found out that /dev/js0 and /dev/input21 are missing when using steam package rules only! I think that's the main issue.
NO idea why, however one thing that comes to mind is that my vendorid line in the custom rules has mode 0666 with users group, whereas the package has 0660 with the TAG+="uaccess"
Almindor (talk) 23:51, 14 December 2015 (UTC)Reply[reply]
Tried 0666 and it seems to work... But is that the suggested thing to do?
Tesfabpel (talk) 09:09, 15 December 2015 (UTC)Reply[reply]

Steam controller under wine

I'm the author of the section Steam Controller/Wine which has been flagged with "Accuracy Disputed" in January 2016.

The hoster link was at the time of writing the only one I could find. I now replaced it with a github repository from June 2016. Unfortunately that application doesn't seem to have an official site. I also removed the flag. I hope this meets the quality standards better than before. Let me know if it does not. Maybe there's a different emulator that works well enough under wine.

Scindix (talk) 17:26, 5 April 2017 (UTC)Reply[reply]

Steam universal joystick to mouse integration

I recently bought a random generic xbox 360 clone generic controller, and steam seems to fully integrate with it and even enables desktop mouse emulation and etc. Is steam doing that to all (non steam) controllers, now or steam mistakenly detecting my controller as a steam controller?

Samosaara (talk) 18:46, 1 April 2018 (UTC)Reply[reply]

IIRC it treats all controllers that way that identify as Xbox or PS4 gamepad. --MarkusS (talk) 22:59, 1 April 2018 (UTC)Reply[reply]

(Temporarily) disable (sixaxis) accelerometers

This may apply to other joystics with built-in accelerometers, but we really need a blurb here about how to, perferably temporarily, disable the accelerometer axes for sixaxis (PS3 controllers). It is more or less impossible to use the controller for any purpose other than the accelerometers so long as they are active. Their output is constant, so any program that requires a manual controller mapping picks them up for every button assignment. The article shows ways of specifing deadzones for joystic and evdev devices, but it isn't clear which of those a sixaxis is or how to find out (If I recall correctly, they are evdev). I haven't really worked with sixaxis since they finally got their own kernel driver, so I'm pretty lost. I'm going to keep looking for how this can be done; may come back with a proposal later. quequotion (talk) 17:41, 26 February 2020 (UTC)Reply[reply]

I had moderate success with setting the deadzones of axes 4 and 5 to 255, using the evdev method:
evdev-joystick --evdev /dev/input/event25 --axis 4 --deadzone 255
evdev-joystick --evdev /dev/input/event25 --axis 5 --deadzone 255
One could extrapolate a udev rule, but I'm still hoping for a more convenient way of turning them on and off as needed (run this as a toggling script?).
My success was not entirely complete: disabling the accelerometer axes greatly improved the situation, but my controllers seem to be very sick, with buttons going off randomly all over the place (one controller practically plays games all by itself, badly, while another has less frequent glitches). Likely a problem with the hardware. quequotion (talk) 19:09, 26 February 2020 (UTC)Reply[reply]

Joystick API vibration support

The article says: "... evdev interface ... adds support for force feedback". Does this mean that Joystick API does not support force feedback? If yes, I think it should be said explicitly.
Also, is there a way to disable one of the APIs for testing purposes? I have found unanswered question here. There are some problematic games (f.e. Oddworld New n Tasty) which fails to activate vibration for gamepads. So I wanted to test how game will behave if hide Joystick API's entries from /dev/input/. Could it be described here in wiki?

—This unsigned comment is by Ashark (talk) 18:26, 19 September 2020‎ (UTC). Please sign your posts with ~~~~!Reply[reply]

Add section for Gamepad emulation?

It could include software like sc-controller and antimicrox.

It is useful for custom mappings, emulation to support more controllers, additional functions like on-screen-menus etc.

G3ro (talk) 20:10, 17 October 2020 (UTC) G3roReply[reply]

Setting deadzones permanently via script vs hwdb approach

In the section for evdev deadzones it says "Use udev rules file to set them automatically when the controller is connected." I think it would be a good idea to give an example here or – since it's similar to the joydev reference that one.

The script approach is what you find widely in the internet when searching for solutions to make such a config permanent, but actually there is a way now which personally I think is better, at least for smaller changes like the deadzone. It makes use of udev's hwdb, to which the user can add own entries. In the example listed there, it would be similar to (assuming the device in the joydev and evdev example are the same, since no vendor/product ids are listed in the latter):

/etc/udev/hwdb.d/10-custom.hwdb
# match vendor id 10C4 and product id 8B02
evdev:input:b0003v10C4p8B02*
# matching by name is also possible
# evdev:name:NameToMatch:*
# part of the name can be matched using wildcards
# evdev:name:*Madcatz Saitek Pro Flight X*:*
# format is ABS is absolute axis, 00 is axis number 0, 01 is axis number 1 etc.
# entry is MIN:MAX:STEP:FUZZ:DEADZONE
# omitted values remain unchanged
 EVDEV_ABS_00=::::512

followed by

$ systemd-hwdb update
$ udevadm control --reload

This approach might be useful for other settings on the same page (which I didn't look at right now). Personally, I think it's better, because it omits the necessity of writing an udev rule and a shell script (which is still a valid option for more complex scenarios). If you agree, I'd add this to the page. Berniyh (talk) 16:28, 12 December 2020 (UTC)Reply[reply]

Sony DualShock 4 appearing as DualShock 5

Things used to worked out of the box for me, but things started to work partially as in ok in Linux Native games and not for games running via proton (xbox controller detected, but no inputs were working).

With xboxdrv.service enabled I used the script for the DualShock 5, changing DualShock 4 with correct path bellow didn't work. Also had to disable Sony gamepad's support in Steam (easiest to do in big screen mode I guess).

$ lsusb | grep Sony;ll /dev/input/by-id/usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-joystick
Bus 001 Device 013: ID 054c:09cc Sony Corp. DualShock 4 [CUH-ZCT2x]
lrwxrwxrwx 1 root root 10 Jul  5 02:02 /dev/input/by-id/usb-Sony_Interactive_Entertainment_Wireless_Controller-if03-event-joystick -> ../event24

I also turned off "touchscreen" (moving cursor by pad between select and start) by disabling that input in xorg.d, probably doesn't matter. BeamNG.drive nicely shows devices it detects as well as their current inputs and I thought "touchscreen" fools it.

Pulec (talk) 12:24, 6 July 2021 (UTC)Reply[reply]

Switch Pro controller udev rule outdated

According to a Valve employee (GitHub comment), the udev rule for Switch Pro controllers, as described in Gamepad#Steam, seems to be outdated and has been included in Steam for about 2 years.

Munzu (talk) 15:02, 31 December 2021 (UTC)Reply[reply]

Unclear instructions on how to calibrate

It is not very clear how to calibrate the joysticks of gamepad. I have a game in which the character is not running because my left joystick's upper spot is not reached (Y axes on top). The game uses evdev. I tried to set another min value (the top point is most negative number) with evdev-joystick. But it did not help: character is still walking instead of running. Then I started evtest-qt and see the same thing (that the lowest most value of axis 1 is not reached). By the way, in the manual it is said that you can test it with jstest. I think this is a mistake, because jstest only shows you a js[0-9] devices, not evdev-joystick devices. Can this be edited? I then tried to make the diapason much less (from -5000 to 5000), at which values the joystick can reach for sure. But still in the game the character cannot run. I then tryed to read resulting value (evdev-joystick --showcal) while holding the left joystick at upper top, and still got the old value (-30969):

Absolute axis 0x01 (1) (Y Axis) (value: -30969, min: -5000, max: 5000, flatness: 128 (=2.56%), fuzz: 16)

How it is possible that value is still less than minimum? Does the evtest-qt show "raw" value? And how can I read "calibrated" value? It makes me think that game could read the raw value instead of corrected one. Is that possible? Or game can only get relative values (from -1 to 1)? Also, it is unclear for me what is fuzz? In manual is is said "--fuzz, --f [val] Change fuzz for current joystick". Please, clarify these questions, if you can. Ashark (talk) 13:43, 23 April 2023 (UTC)Reply[reply]

Add HOTAS section?

I have information and procedures that can help users attempting to use VIRPIL and VKB HOTAS, or other modern HOTAS that are self calibrated or calibrated elsewhere that I believe should be visible to users trying to set them up and/or troubleshoot them. It can get confusing when troubleshooting from information in a consolidated page because much of the gamepad documentation comes with the assumption of button limitations, which can present problems and confusion on which tools to use to correct problems. However, I don't think HOTAS needs it's own page because most of the information needed to test and correct is already here. In that context just a HOTAS section makes sense. Especially as I don't have a ton of things to post.Thoughts? Runlevelzero (talk) 22:01, 17 May 2023 (UTC)Reply[reply]

As you said, it may confuse to see non gamepad controller on gamepad page. But as you say there is not much to add, I agree to create a section for now. By the way there is already a section for a specific controller to be mapped as two gamepads.Ashark (talk) 05:28, 18 May 2023 (UTC)Reply[reply]

Playstation (PS3) - bluez security update causes connection failure

After a bluez security update which implemented a fix for CVE-2023-45866, users will need to create/edit the bluetooth input configuration file and regress the security fix to enable PS3 controller support over bluetooth. Wired controller use is unaffected.

Be aware this is a security regression and making these changes puts your system at risk of HID spoofing attacks

/etc/bluetooth/input.conf
[General]
ClassicBondedOnly=false

After making these changes you will need to restart the bluetooth service.

systemctl restart bluetooth.service

NJodoin (talk) 19:31, 16 December 2023 (UTC)Reply[reply]

Thanks for mentioning this, I also found this information in an Ubuntu/Debian thread, but it wasn't enough for me to make my original PS3 controller work: bluetoothctl says it's connected but somehow it fails to assign the controller a number and it just turns off, otherwise I get this in my journal
org_kde_powerdevil[1304]: QObject::disconnect: Unexpected nullptr parameter 
org_kde_powerdevil[1304]: QObject::disconnect: Unexpected nullptr parameter 
kernel: usb 3-4: USB disconnect, device number 58 
kdeconnectd[1554]: qt.bluetooth.bluez: No uuids found for "22:22:FF:54:69:94" 
bluetoothd[138853]: sixaxis: compatible device connected: Sony PLAYSTATION(R)3 Controller (054C:0268 /sys/deviceS/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.0/0003:054C:0268.003A/hidraw/hidraw7) 
kernel: sony 0003:054C:0268.003A: input,hiddev100,hidraw7: USB HID v81.11 Joystick [Sony PLAYSTATION(R)3 Controller] On usb-0000:09:00.3-4/input0 
kernel: input: Sony PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.0/0003:054C:0268.003A/input/input143 
kernel: input: Sony PLAYSTATION(R)3 Controller Motion Sensors as /devices/pci0000:00/0000:00:01.2/0000:02:00.0/0000:03:08.0/0000:09:00.3/usb3/3-4/3-4:1.0/0003:054C:0268.003A/input/input144 
kernel: usb 3-4: Manufacturer: Sony 
kernel: usb 3-4: Product: PLAYSTATION(R)3 Controller 
kernel: usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 
kernel: usb 3-4: New USB device found, idVendor=054c, idProduct=0268, bcdDevice= 1.00 
kernel: usb 3-4: new full-speed USB device number 58 using xhci_hcd
Adelks (talk) 00:27, 20 December 2023 (UTC)Reply[reply]
Odd, I can confirm the above instructions were able to get another user working with a genuine PS3 controller on current bluez.
Just to confirm, you created the file "/etc/bluetooth/input.conf" with the contents as above verbatim and then restarted the bluetooth service?
Also, I may have been in that same Ubuntu/Debian thread. The thread I got the information from DID NOT mention that the input.conf file would need to be created on an arch system, but that was pretty straight forward since it didn't exist. However what was not immediately obvious without some digging was adding the "[General]" header on the line above where ClassicBondedOnly=false is set. After making those modifications to their original instructions I was able to get it working.
Could you post the contents of your input.conf?
Unfortunately,I'm not sure how much help I can offer from the information you posted, as I'm not a Bluez/Bluetooth hardware expert. It may be an unrelated issue if your configuration is the same as what I listed above. Speculating, but I also have seen connection issues related to non-genuine PS3 controllers. Could that be the case? NJodoin (talk) 00:04, 22 December 2023 (UTC)Reply[reply]
Thanks for your feedback (weirdly enough I did not get notified for your answer). I tried on Arch and Gentoo (which ships /etc/bluetooth/input.conf
# Configuration file for the input service

# This section contains options which are not specific to any
# particular interface
[General]

# Set idle timeout (in minutes) before the connection will
# be disconnect (defaults to 0 for no timeout)
#IdleTimeout=30

# Enable HID protocol handling in userspace input profile
# Defaults to false (HIDP handled in HIDP kernel module)
#UserspaceHID=true

# Limit HID connections to bonded devices
# The HID Profile does not specify that devices must be bonded, however some
# platforms may want to make sure that input connections only come from bonded
# device connections. Several older mice have been known for not supporting
# pairing/encryption.
# Defaults to true for security.
ClassicBondedOnly=false

# LE upgrade security
# Enables upgrades of security automatically if required.
# Defaults to true to maximize device compatibility.
#LEAutoSecurity=true
And apparently, according to the gentoo wiki, we need to turn UsespaceHID too https://wiki.gentoo.org/wiki/Sony_DualShock#BlueZ
Also found this bug report https://github.com/bluez/bluez/issues/407 and indeed I have middle-eastern Sixaxis Gamepads, maybe it's that. One thing I could confirm is that on Windows it works with https://github.com/nefarius/DsHidMini + https://github.com/nefarius/BthPS3 so I may delve into the rabbit hole to figure this thing out.
Adelks (talk) 01:21, 27 December 2023 (UTC)Reply[reply]