Rickety Cricket Feb 15, 2013 @ 6:39pm
Gamepad in Big Picture Mode
I have an old Playstation2 controller and a USB adapter. I'm running Gentoo amd64 on an Intel mobo with Intel HD graphics. Steam runs great, even in Big Picture mode. And the one game I have is running great too. The only problem I have is that when in Big Picture - Settings it says "No Controller Detected".

I have /dev/input/js0
I can run jscal and all my buttons and dpad/sticks work.
I even use this gamepad with a couple NES emulators. So I know its working.

But for some reason it won't work in Steam or any games. I can't find anything in Steam std out that says anything about joystick. I'm running Openbox, so no big bloated gnome/kde/etc to help me config the JS.

Any ideas?
Showing 1-15 of 22 comments
< >
crinapsis Feb 17, 2013 @ 7:48am 
I'm in the same situation as you.

Tested Trine 2, Bastion and Eversion, gamepad does not work on any of them.

Investigating for a solution, suggestions are welcome ;)

Thinking to use PlayDeb (http://www.playdeb.net/updates/ubuntu/12.04/?q=qjoypad) which maps gamepad's buttons to keyboard keys. But I'd prefer having gamepad working as expect.
Nyamiou@Debian:~$ Feb 17, 2013 @ 8:41am 
Most recent games on Steam only support XInput and some old gamepads only work with DirectInput (see : http://en.wikipedia.org/wiki/DirectInput). I suggest you buy and Xbox 360 controller, I don't know on Ubuntu but on Debian Sid it's literally plug and play.
[Linux] unbridledExüberance Feb 17, 2013 @ 8:51am 
Well, he said it shows up in /dev/input as a joystick, so that's not the problem. That's exactly how an XBox360 controller is handled.
ThOR27 Feb 17, 2013 @ 2:13pm 
XInput VS DirectInput is not an Issue on Linux, this is microsoft stuff as long as I know.

I think it's better if you report this on Steam bug tracker, here: https://github.com/ValveSoftware/steam-for-linux/issues
Nyamiou@Debian:~$ Feb 17, 2013 @ 6:05pm 
Well, I don't really know a lot about how this stuff works but I do know that people have the same problems with old controller on Windows and I do have old controllers that won't work with Bastion on Windows. If you have Windows on your system or on a friend system I think you'll probably see that it won't work with old controllers and that you need to buy new ones.
Rickety Cricket Feb 19, 2013 @ 12:27pm 
I just notice on the Intrusion 2 store page it says "Additional:supports XBox Controller" :( I just bought the game because I thought I could get it working with any controller via Big Picture mode for playing on my TV. I don't really want to go out and buy an xbox controller.

I'll def post something to github issues when I get all the details. But if it only supports 1 or 2 MS controllers at the moment they might not jump into it right away.

Here are my USB Adapter details:
usb 7-1: new low-speed USB device number 2 using uhci_hcd
usb 7-1: New USB device found, idVendor=0e8f, idProduct=0003
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 7-1: Product: USB Joystick
usb 7-1: Manufacturer: GreenAsia Inc.
input: GreenAsia Inc. USB Joystick as /devices/pci0000:00/0000:00:1d.1/usb7/7-1/7-1:1.0/input/input5
pantherlord 0003:0E8F:0003.0003: input: USB HID v1.10 Joystick [GreenAsia Inc. USB Joystick ] on usb-0000:00:1d.1-1/input0
pantherlord 0003:0E8F:0003.0003: Force feedback for PantherLord/GreenAsia devices by Anssi Hannula <anssi.hannula@gmail.com>

# jstest /dev/input/js0
Driver version is 2.1.0.
Joystick (GreenAsia Inc. USB Joystick ) has 7 axes (X, Y, Z, Rz, Hat0X, Hat0Y, (null))
and 12 buttons (Trigger, ThumbBtn, ThumbBtn2, TopBtn, TopBtn2, PinkieBtn, BaseBtn, BaseBtn2, BaseBtn3, BaseBtn4, BaseBtn5, BaseBtn6).
Testing ...


Will report back if I find out anything else.
richi902 Feb 19, 2013 @ 12:56pm 
you can also use the logitech f710/f510/f310 controllers in xinput mode :P since they are acting as 360 controller in that mode. the problem is most games will be made with the 360 controller in mind
Rickety Cricket Mar 29, 2013 @ 11:30am 
Well, I just updated steam and my gentoo system. I now have the newest steam client that requires SDL-2. And Big Picture mode has now recognized my GreenAsia PS2 adapter and controller. All the buttons work and I can go into Big Picture mode's settings and edit the buttons and I even uploaded my configs to Steam servers. The only sad part now is that the controller still doesn't work in Intrusion 2. But that's a whole other issue I believe, it's a flash game and it's advertised as full controller support. The Intrusion 2 forums have some posts about it. sux :/ It was the only reason I bought the game, to try it out in Big Picture mode on my TV with controller on linux. Might have to request a refund like others have.
V̟̋ì͚t̪͊r̳͛i͇͛o̦̅l̥ Apr 4, 2013 @ 1:41am 
Interesting... I'm still stuck with no controller detection under BPM. Running Ubuntu 12.10 here.

I've tried 5 different gamepad devices (DS3 via QTSixa, Wiimote via wminput, DS2 via USB adapter, Logitech RumblePad2, and a Logitech DualAction USB pad) that have all successfully enumerated and been tested with jstest, emus, etc. I'm running what I can only assume is the latest steam version (beta opt-in), build dated 2013.03.29, installed from the most recent .deb available on repo.steampowered.com today.

All the devices successfully enumerate on /dev/input/js* and can be tested with jstest, emulators, etc., and all appear to be working fine with udev/uinput. However, when I load up BPM, no controllers are detected -- either any/all at once or even individually as js0. I'd just been assuming that Steam uses a xinput-device whitelist or something to filter js devices, but then I ran across your post here and I'm stumped.

On Win7 I get all full controller detection/configuration options for these devices, but not under Linux.

Is there a secret nightly build I don't know about? What's your client version? I'd love to get past this bloody stupid hurdle. Ironic that Gaben complains that M$ is destroying the openness of the PC platform, but sets up camp on proprietary throwback M$ garbage like xinput.

In any case Steam should be the worst of it, you should be able to remap the axes/buttons with for individual games that only support the X360 mapping. I've had to do as much with Super Meat Boy because the menu controls are hard-coded.

I don't have Intrusion2 yet, but something like this should probably work if Gentoo's jscal has the -u option:

mv Intrusion2 Intrusion2-bin

nano Intrusion2

> jscal -u <axis/button remap>
> Intrusion2-bin
> jscal-restore

chmod +x Intrusion2

Steam should then be able to launch the game from BPM and apply a temporary remap transparently.


M@yeulC [Fr] May 25, 2013 @ 7:02pm 
The same here with a wireless controller.
issue on GitHub : https://github.com/ValveSoftware/steam-for-linux/issues/2092
V̟̋ì͚t̪͊r̳͛i͇͛o̦̅l̥ Jun 7, 2013 @ 5:13pm 
I probably should have posted this fix much earlier.

As it turns out, the Steam Linux client apparently tries to use the uinput event devices (/dev/input/event<#>) to read joystick/gamepad input. Which is, in fact, the wrong way to go about doing that.

When any input device is registered through uinput, a device stream is created in the uinput event directory (/dev/input on Ubuntu 12.04, which is Valve's target OS). Now since all input devices, including keyboards, have have event descriptors, it wouldn't do to to allow free access to them. Freely allowing software to read the event streams is tantamount to allowing any software to 'wiretap' your keyboard, thus no password could ever be entered securely.

As you might expect, Linux restricts read/write access to these streams to root-level permissions. Now, when a joystick-class device (this includes gamepads) is registered through uinput an additional stream is created (/dev/input/js<#> for Ubuntu) with user-level permissions so that it can be read without elevated permissions.

Reading /dev/input/js0 would be the correct way to read the first joystick under modern Ubuntu.

What Valve is doing is trying to read the wrong stream, and it doesn't have access by defaut, and for good reason. Which just really illustrates how in-the-dark Valve's devs are about properly using linux. There are dozens of other examples of this kind of thing when the Linux Steam client is closely examined. It does seem to be assembled via guesswork.

An easy way to circumvent this problem is to change the permissions that uinput creates devices all event<#> device streams with to be read/written at user-level.

WARNING: changing the uinput permissions to accommodate Steam, is generally a bad idea and should only be done on a system where security implications are acceptable.

I have done this on a completely dedicated custom Linux HTPC without any desktop environment. There are no other users, no passwords or personal information is ever entered via keyboard. Doing this on a desktop system is not recommended. Ye hath been warned.

I'm posting based on modern Ubuntu directory structure since that's what Valve supports, so for other distros it may be different.

The fix is actually pretty simple.

From a terminal:
sudo nano /etc/udev/rules.d/85-input-events.rules

Add the following line to the newly created file:
SUBSYSTEM=="input", MODE="666"

Save the file and reboot.

Steam should now have access to your joystick/gamepad devices.
V̟̋ì͚t̪͊r̳͛i͇͛o̦̅l̥ Jun 7, 2013 @ 5:27pm 
Oh an I've recently picked up Intrusion2 from HIB8. Turns out the damn thing is built with flash so my previous suggestion about using jscal is not going to fix anything (obviously, heh).

Adobe dropped flash support for Linux a while back so dont expect them to fix joystick support in their linux flash binary. Ever. Probably not for Mac either.

Srsly, ♥♥♥♥ Adobe.
Kniren Jun 26, 2013 @ 11:37pm 
I just want to say that Vitriol's workaround worked for me. Although, I wonder if there is a way to symlink /dev/input/jr# to /dev/input/event# thus avoiding the security problems of this method
iago Jul 9, 2013 @ 10:27pm 
Just throwing in my few cents here:

Vitriol is mostly correct, and the solution provided will work. However, I believe it's incorrect that Steam is reading joystick input the "wrong way" or that they are "in-the-dark".

In general, there are two ways for a piece of software to access a gamepad on Linux: using the Input API (/dev/input/event*), or the Joystick API (/dev/input/js*). The Joystick API is the older API, and doesn't support some of the things that the Input API does (such as force feedback).

So, theoretically, they can both be used, but why use the older API when you can use the newer one? This is what Steam has decided to do.

The problem with this approach is that some Linux distros continue to provide the default security settings of the Input API (the /dev/input/event* files) so high that a user cannot access the file, therefore making it impossible for software like games or the steam client to access them. So long as the Linux distros continue to make the /dev/input/event* files only accessible via root, users will have issues getting the best out of their hardware.

So, yes, the resulting problem, as Vitriol points out, is one of file system permissions. Vitriol's solution basically makes all of your input devices user-readable, meaning any program run on your system can easily gain access to your keystrokes or other input devices. If you're playing on your gaming desktop, this probably isn't a big deal for you, so you can just use that solution. Otherwise, you can do the following to only make the controller available to non-root users (this worked for me on a Debian testing system, your results may vary). You can find more info on this blog post:

http://buzzdavidson.com/?p=45

1.) Plug in your controller
2.) Identify the input device your controller: you need to know which /dev/input/event* file is your controller. Probably the easiest way to do this is to do the following...

mark@gobo:~$ ls -al /dev/input/by-id/usb-*
lrwxrwxrwx 1 root root 10 Jul 10 00:57 /dev/input/by-id/usb-Logitech_Gamepad_F310_B3F8248A-event-joystick -> ../event12
lrwxrwxrwx 1 root root 6 Jul 10 00:57 /dev/input/by-id/usb-Logitech_Gamepad_F310_B3F8248A-joystick -> ../js1
lrwxrwxrwx 1 root root 10 Jul 10 00:57 /dev/input/by-id/usb-©Microsoft_Corporation_Controller_1178A7E-event-joystick -> ../event11
lrwxrwxrwx 1 root root 6 Jul 10 00:57 /dev/input/by-id/usb-©Microsoft_Corporation_Controller_1178A7E-joystick -> ../js0

Here I have two controllers plugged in: a Microsoft X-Box and a Logitech Gamepad. The XBox Controllers points to js0 and event11, the logitech to js1 and event12. So, if I want to fix the XBox Controller, I need to remember event11 (/dev/input/event11).

3.) Make sure that your problem actually is the fact that the input system is using bad permissions. Try the following...

evtest /dev/input/event11

Of course, replace event11 with the event file you found in step 2. It will probably say "Permission denied". If it does, then yes, you have a permissions problem. Now try the following:

sudo evtest /dev/input/event11

Then try pressing buttons on your gamepad. You should see the console scroll a bunch of gibberish. This is your gamepad working, but only for root. If these are your symptoms, then continue following these instructions for a fix.

4.) Gaining identifying attributes:

Now you need to find out information that you can give to the Linux system to identify this device whenever you plug it into my computer....

sudo /sbin/udevadm info -a -p $(sudo /sbin/udevadm info -q path -n /dev/input/event11)

This runs two commands in one and returns a list of things that can identify your controller. Once again, replace event11 with your event. My results were as followed:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input11/event11':
KERNEL=="event11"
SUBSYSTEM=="input"
DRIVER==""

looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input11':
KERNELS=="input11"
SUBSYSTEMS=="input"
DRIVERS==""
ATTRS{name}=="Microsoft X-Box 360 pad"
ATTRS{phys}=="usb-0000:00:1d.0-1.1/input0"
ATTRS{uniq}==""
ATTRS{properties}=="0"

looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0':
KERNELS=="2-1.1:1.0"
SUBSYSTEMS=="usb"
DRIVERS=="xpad"
ATTRS{bInterfaceNumber}=="00"
ATTRS{bAlternateSetting}==" 0"
ATTRS{bNumEndpoints}=="02"
ATTRS{bInterfaceClass}=="ff"
ATTRS{bInterfaceSubClass}=="5d"
ATTRS{bInterfaceProtocol}=="01"
ATTRS{supports_autosuspend}=="0"

... a whole lot of more stuff ....

Specifically, I'm looking for something that I can use to identify this device, which I see at....

ATTRS{name}=="Microsoft X-Box 360 pad"

Since there's very little chance I'm ever going to plug a keyboard in that also has the name of "Microsoft X-Box 360 Pad", I can safely create a rule that says to look for this device and do something special with it.

5.) Now, I create a new file in /etc/udev/rules.d/99-joysticks.rules...

SUBSYSTEMS=="input", ATTRS{name}=="Microsoft X-Box 360 pad", MODE="0666"

What this is saying is, "Whenever I detect that a device on the input system with the name 'Microsoft X-Box 360 pad' is connected, I want to make sure to set the file mode to 0666". Mode of 0666 means "rw-rw-rw-". In other words; read- and writeable to all users.

Now you can apply the rule so that it can occur on your already plugged in device...

sudo /sbin/udevadm trigger

Continue adding another line in the 99-joysticks.rules file for all your devices using the same steps above. If all goes well, your gamepads should be able to be tested without root required, which you can test with....

evtest /dev/input/event11
Last edited by iago; Jul 9, 2013 @ 10:30pm
zzz Jul 10, 2013 @ 6:25am 
Easy and universal way to fix a joystick never being detected in a game/program.

Install qjoypad.

Make a layout in qjoypad for it and correspond the keybind configuration in the game with it.

Start the game with this script:

#!/bin/bash
qjoypad <name of layout> &
STEAM_RUNTIME=1 steam
pkill qjoypad
exit

Obviously, you could replace steam with any game/program you are ever having issues with. It does not ever actually fix the issue with a program, but it's a hell of a lot easier and much more convenient than trying to fight a program tooth and nail getting it to recognize a joystick.
Last edited by zzz; Jul 10, 2013 @ 6:29am
Showing 1-15 of 22 comments
< >
Per page: 15 30 50
Date Posted: Feb 15, 2013 @ 6:39pm
Posts: 22