I'm not sure, I just tried a wired XBox 360 controller and it worked fine.

You can debug this by downloading the debug runtime and using gdb:
STEAM_RUNTIME=debug DEBUGGER=gdb steam
(gdb) b SDL_SYS_JoystickInit
(say yes when prompted that this symbol doesn't exist)
(gdb) r
...
Then step through the code when you get to SDL_SYS_JoystickInit

Let me know what you find! :)

Hi, I ran the code, but I am unfamiliar with debugging in Linux. What am I supposed to see? What is an error, I press S to step through, but I don't see anything obvious.

Let me know if you'd like me to live debug this with you, [email protected]

I have pretty much the same problem. Gamepad is running fine in everything except Steam (and SDL games). jstest outputs the right results, and so on.
I did the steps @slouken recommended and got the following output:

(gdb) b SDL_SYS_JoystickInit
Function "SDL_SYS_JoystickInit" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (SDL_SYS_JoystickInit) pending.
(gdb) r
Starting program: /home/timroes/.local/share/Steam/ubuntu12_32/steam 
warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Inferior 1 (process 5108) exited normally]

After that it is waiting again at (gdb) but even when starting big picture mode and going to joystick settings, no breakpoint is ever hit.

Using Gentoo 64bit, will be glad to help this, since it really looking forward playing The Cave :)

I have a similar problem with an official wired 360 controller:

• controller shows up in /dev/input/js0, and "cat /dev/input/js0" reacts to gamepad buttons
• big picture: "no controller detected"
• trine 2: not working (the controller appears in the controller setup menu, but I can't choose it)
• tf2: working perfectly out of the box (which differs from OP)

I am running Fedora 18 x64.

SDL packages I have:

[xxxx@yyyy ~]$ yum list installed | grep SDL
SDL.i686                        1.2.15-3.fc18       installed                   
SDL.x86_64                      1.2.15-3.fc18       installed                   
SDL2.i686                       2.0-0.2.20130412hg7062.fc18
SDL_image.x86_64                1.2.12-3.fc18       @fedora                     
SDL_mixer.i686                  1.2.12-3.fc18       @fedora                     
SDL_mixer.x86_64                1.2.12-3.fc18       @fedora  

EDIT: I tried what slouken said (STEAM_RUNTIME=debug DEBUGGER=gdb steam), but it says that the function is not defined. Maybe I did something wrong?

(gdb) b SDL_SYS_JoystickInit
Function "SDL_SYS_JoystickInit" not defined.

EDIT2: Adding some details.

I used sdljoytest (http://sdljoytest.sourceforge.net/) and it showed one connected controller X-Box 360 pad, and all buttons and axis work like expected. So it doesn't seem to be a problem with SDL and the controller, but something inside steam.

I guess the sdljoytest uses my installed libSDL 1.2.15-r2 version installed via Portage (Gentoo's package manager) and steam uses the bundled libSDL 2.0 version. So it might also be a problem with libSDL2.0?

I'm having the same issues with wired Xbox controller.
Tested right now:
Beat Hazard, Bastion and Cave Story+ work fine without any extra setup.
Trine 2, Dungeon Defenders and newly released Brutal Legend do no work at all.
Big Picture mode also can't detect the controller.
I believe at least Trine, DD and Big Picture worked just fine at some point earlier.

I have the same issue Here : My xbox 360 wireless controller works fine with serious sam 3, XBMC, etc... But not recognized by steam.
I tried both xpad and xboxdrv (with and without --mimic-xpad and --mimic-xpad-wireless)

The problem disappeared for Big Picture Mode on my system, probably thanks to recent steam client updates.

I still have to try with Trine 2 to see if things got better there as well.

Not fixed for me yet. (Update from 15th Aug, where changelog states an update of SDL).

I also downloaded SDL2 sources from their website, and build their joystick test, that says, that it doesn't find any joystick. So this might be a problem with SDL2 in general (since SDLJoystickTest using libsdl 1.2.15-r2 detects the joystick).

I am happy if I can offer my PC for debugging, so this can be fixed.

Can you build a debug version of SDL (CFLAGS=-g ./configure; make install) and step into the code and see what's going on?

If not, I'll be happy to log into your system next week and debug the issue. You can send me login information confidentially at [email protected]

Cheers!

"Debugged" around in SDL and found the problem (@slouken, I spammed your mailbox :D).

Problem:

udev has a default rule, that should use ACL (Access Control Lists) to make the joystick readable for the user, who plugged it in. On some systems that rule seems not to work (even if you have ACL support enabled in your kernel and compiled udev with the acl feature). So the problem is, SDL has no rights to access the joystick, because the permissions are wrong. (Nothing SDL could do against that.)

Why does it work for some games? Because some games, don't use SDL to access the joystick, but joystick functions in linux. These work against /dev/input/jsX (instead /dev/input/eventX). And this joystick device file should always be mounted world readable and so these games work.

Workaround:

1. Find out which event device is your joystick execute udevadm monitor and then plug your controller in. You will find a line that has something with eventX in the end (where X is a number).
2. Make the device world readable: chmod +r /dev/input/eventX
3. Start Steam and have fun. Your controller should now be detected.

Hope this will work for the people here who had the problem!

As soon as I find a solution, why the ACL rule is not working in udev, and how to fix it, I will post the solution here. But until then you will need to use the above workaround.

timroes, i did exactly what you suggested and you were correct, /dev/input/event11 was only readable by it's owner, root. so when i added read writes for everyone i thought that would solve it but the controller still does NOT work in any Valve source linux steam game like Team Fortress 2, Portal, or L4D2. I really want to use my wired xbox 360 controller to play these games. Its the defauly xpad driver that is being used here. I am wondering if it's each games 360controller.cfg file. I looked within them and the joy_name is something very generic but even when I attempted to change it to match what dmesg informed me the name of the controller was when I inserted the controller, it still didn't work. Any other ideas how to get this work?

find /dev/input/by-path/ -name '*event-joystick' | xargs sudo chmod +r fixed for me on arch64

echo 'KERNEL=="event*", ENV{ID_INPUT_JOYSTICK}=="1", MODE:="0644"' | sudo tee /etc/udev/rules.d/joystick-perm.rules will make it permanent

The permissions set by udev on /dev/input/event* are indeed a problem on many systems, but for some of us, Steam's Big Picture still says "no controller detected" after the permissions have been fixed. Alexey Loukianov did an outstanding job of investigating, and posted details in #1894.

In short:

• Steam detects game controllers using libsdl, which uses libudev to find the appropriate /dev/input/event* device file. (It ignores /dev/input/js0.)
• Steam ships its own version of libudev; one that is incompatible with the the version of udev that runs on many modern linux distributions, so it can't find the /dev/input/event* device file it needs. (Meanwhile, other SDL applications on the same system handle game controllers just fine.) This is a problem that really ought to be fixed.
• As a temporary workaround, you can figure out which /dev/input/event* file corresponds to your gamepad, manually make it readable, and set the SDL_JOYSTICK_DEVICE environment variable to that file's path when launching Steam. Something like this: env SDL_JOYSTICK_DEVICE=/dev/input/event18 steam