ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.26k stars 174 forks source link

Wired 360 Controller #2092

Open peterhazlewood opened 11 years ago

peterhazlewood commented 11 years ago

Inconsistant Gamepad behaviour:

/dev/input/js0

Games Serious Sam 3: BFE - controller is detected and works perfectly Bastion - controller detected, works perfectly TF2 - not detected - does nothing Trine 2 - detected (shows in controller selection) - does nothing

Big Picture Mode Settings -> Controller -> Controller Detected: No controller detected.

doing cat /dev/input/js0 shows expected binary characters and reacts to gamepad buttons, etc...

What is wrong with my setup that I can have a perfect gamepad experience in SS3 and Bastion, yet even Big Picture Mode does not even see a controller connected!

Thanks, Peter

slouken commented 11 years ago

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! :)

peterhazlewood commented 11 years ago

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.

slouken commented 11 years ago

Let me know if you'd like me to live debug this with you, slouken@libsdl.org

timroes commented 11 years ago

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 :)

Ezwen commented 11 years ago

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

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.

timroes commented 11 years ago

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?

l1bbcsg commented 11 years ago

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.

MayeulC commented 11 years ago

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)

Ezwen commented 11 years ago

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.

timroes commented 11 years ago

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.

slouken commented 11 years ago

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 slouken@libsdl.org

Cheers!

timroes commented 11 years ago

"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.

ubuntuaddicted commented 11 years ago

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?

Thermionix commented 10 years ago

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

Thermionix commented 10 years ago

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

foresto commented 10 years ago

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: