version 2.5 does not detect my joystick under linux

[Windfisch]

Mupen64plus version 2.5, as compiled under Gentoo Linux does not detect my USB gamepad. Instead, it reports Input: 0 SDL joysticks were found.

This is a regression in version 2.5: Mupen64plus version 2.0 (input-sdl-2.0-r1), the jstest program and other programs can successfully detect and use the joystick.

(Actually, I additionally tried this while emerge was upgrading from mupen64plus 2.0 to 2.5. It seems like it broke the very moment when the input-sdl-2.5 plugin was installed (and thus, the 2.0-r1 version was uninstalled).

The full output is attached below:

mupen64plus ZeldaOcarinaOfTime.n64 
 __  __                         __   _  _   ____  _             
|  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
| |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
|_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
             |_|         http://code.google.com/p/mupen64plus/  
Mupen64Plus Console User-Interface Version 2.5.0

UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.0
UI-Console:             Includes support for Dynamic Recompiler.
Core: Goodname: Legend of Zelda, The - Ocarina of Time (E) (M3) (V1.1) [!]
Core: Name: THE LEGEND OF ZELDA 
Core: MD5: D714580DD74C2C033F5E1B6DC0AEAC77
Core: CRC: B2055FBD BAB4E0C
Core: Imagetype: .z64 (native)
Core: Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
Core: Version: 1449
Core: Manufacturer: Nintendo
Core: Country: Unknown (0x150)
UI-Console Status: Cheat codes disabled.
UI-Console Error: dlopen('/usr/games/lib64/mupen64plus/mupen64plus-video-rice.so') failed: /usr/games/lib64/mupen64plus/mupen64plus-video-rice.so: cannot open shared object file: No such file or directory
UI-Console: using Video plugin: 'Glide64mk2 Video Plugin' v2.5.0
UI-Console: using Audio plugin: 'Mupen64Plus SDL Audio Plugin' v2.5.0
UI-Console: using Input plugin: 'Mupen64Plus SDL Input Plugin' v2.5.0
UI-Console: using RSP plugin: 'Hacktarux/Azimer High-Level Emulation RSP Plugin' v2.5.0
Video: opening /usr/share/mupen64plus/Glide64mk2.ini

INI_FindSection trying to find name for DEFAULT
Video: 3DNOW! detected.

Input: 0 SDL joysticks were found.
Input: N64 Controller #1: Using manual config for SDL joystick 0
Input: 1 controller(s) found, 1 plugged in and usable in the emulator
Input Warning: Couldn't open joystick for controller #1: There are 0 joysticks available
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input: Mupen64Plus SDL Input Plugin version 2.5.0 initialized.
INI_FindSection trying to find name for DEFAULT
INI_FindSection trying to find name for THE LEGEND OF ZELDA
Video: Using TEXUMA extension.

&ConfigOpenSection is 0x7fc3d95ec9e0
(II) Setting video mode 1440x1080...
Core: Setting video mode: 1440x1080
packed pixels extension used
NPOT extension used
use_fbo 1
Video: InitCombine() 
Video: extensions 
Video: initialized.
Video: 

Audio: Initializing SDL audio subsystem...
Input Warning: Couldn't open joystick for controller #1: There are 0 joysticks available
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Input Error: Couldn't init SDL haptic subsystem: SDL not built with haptic (force feedback) support
Core: Starting R4300 emulator: Dynamic Recompiler
Core: R4300: starting 64-bit dynamic recompiler at: 0x7fc3e4dd3af0
INI_FindSection trying to find name for UCODE
^CCore Status: Stopping emulation.
Core: R4300 emulator finished.
Core Status: Rom closed.

[richard42]

Hi Florian,

Can you run 'ldd' on your input plugin file? Like this:

ldd ./mupen64plus-input-sdl.so

See what version of SDL2 it's linking against. On my machine (also Gentoo) the joysticks are correctly detected, and here are the version of SDL2 that I have:

libSDL2-2.0.so.0 => /usr/lib64/libSDL2-2.0.so.0 (0x00007f3036bcd000)

Richard

On 11/21/2015 10:00 AM, Florian Jung wrote:

Mupen64plus version 2.5, as compiled under Gentoo Linux does not detect my USB gamepad. Instead, it reports |Input: 0 SDL joysticks were found.|

This is a regression in version 2.5: Mupen64plus version 2.0 (input-sdl-2.0-r1), the |jstest| program and other programs can successfully detect and use the joystick.

(Actually, I additionally tried this while emerge was upgrading from mupen64plus 2.0 to 2.5. It seems like it broke the very moment when the input-sdl-2.5 plugin was installed (and thus, the 2.0-r1 version was uninstalled).

The full output is attached below:

[kat-co]

+1 also have this problem. In my case it's a Wii classic controller that jtest-gtk detects just fine.

I can confirm that it's linked the same:

libSDL2-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f4e4521a000)

[richard42]

Hi kat-co,

I have compiled and uploaded an SDL2 joystick test program for 64-bit Linux. You can use this to determine how many joystick devices are visible to SDL2, and how they are configured. You can download this program from here: http://mupen64plus.org/old-releases/SDL2JoyTest-linux64.tar.gz If you run it with no arguments, it will report the number of joysticks detected. If you run it with a single argument, a number starting from 0, it will test the operation of that joystick number.

[kat-co]

Sure enough, it reports 0! However, this project reports everything available. I'm not very well versed in this area, but any pointers on why that project would find it, but your test program will not?

Thanks very much for not only the response but the test binary.

[kat-co]

I should also mention that I compiled the 2.0 tag and unlike the original reporter, this didn't seem to improve the situation -- likely because SDL isn't finding the joysticks in the first place.

[richard42]

So it's probably some kind of SDL problem. On that same old-releases page of our mupen64plus.org site, there is an SDLJoyTest archive which links against SDL1.2 instead of SDL2.. It's possible that the problem is with SDL2, and your joysticks may work with the older SDL1.2. You can test with the other SDLJoyTest program. If it does work, you can compile Mupen64Plus (either 2.0 or 2.5) to build against SDL1.2 instead of SDL2. To do this, each module should be compiled with:

make all SDL_CONFIG=sdl-config

Also note that all of the modules must be compiled against the same version of SDL, or else it will definitely not work right.

[erjoalgo]

Hello @richard42 . I'm running into this problem using a ShenZhen ShanWan Technology Co., Ltd. ZD-V+ Wired Gaming Controller. The controller is detected by jstest-gtk, but not by mupen64plus, nor by the test program you linked. I tried looking for the SDLTester program you referenced that is compiled against SDL1.2 but I can only see a windows version of SDLJoyTest-1.2.14-win32.zip:

█[asrock][src][0]$ ldd /usr/lib/x86_64-linux-gnu/mupen64plus/mupen64plus-input-sdl.so | grep -i sdl
        libSDL2-2.0.so.0 => /lib/x86_64-linux-gnu/libSDL2-2.0.so.0 (0x00007f8330efd000)
█[asrock][src][0]$

SDL2JoyTest says there are 0 joysticks:

█[asrock][src][130]$ ./SDL2JoyTest
There are 0 joysticks attached
█[asrock][src][0]$

But jstest detects it:

█[asrock][src][0]$ jstest /dev/input/js0 | head -c500
Driver version is 2.1.0.
Joystick (SWITCH CO.,LTD. Controller (Dinput)) has 6 axes (X, Y, Z, Rz, Hat0X, Hat0Y)
and 13 buttons (BtnA, BtnB, BtnC, BtnX, BtnY, BtnZ, BtnTL, BtnTR, BtnTL2, BtnTR2, BtnSelect, BtnStart, BtnMode).
Testing ... (interrupt to exit)
Axes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:ofAxes:  0:     0  1:     0  2:     0  3:     0  4:     0  5:     0 Buttons:  ^C
█[asrock][src][0]$

[richard42]

Yeah SDL 1.2 is really dead by now, so I don't think that's going to help you.

The core problem for you is that SDL2 doesn't recognize or support your joystick. There's nothing that mupen64plus can do to fix that, because it only uses SDL for joystick interfacing. Once you solve the problem with SDL2 then mupen64plus will be able to see and use your joystick.

Here is a stack overflow article which talks about this issue; I'm sure you can search and find others as well:

https://stackoverflow.com/questions/61603693/sdl2-does-not-see-joystick-but-os-does

It suggests checking the permissions on the /dev/input/event* files, and there is also a comment about running "strace -e" on the program to dump all the system calls to help diagnose. I think this could definitely point you to the source of the problem, though there will be lots and lots of logging information to dig through and that could be a bit of a job.

[erjoalgo]

I ran mupen64plus with sudo and the joystick was detected successfully:

sudo $(which mupen64plus) ~/Downloads/n64/Legend\ of\ Zelda,\ The\ -\ Ocarina\ of\ Time\ \(USA\)\ \(Rev\ 2\).z64

So it was indeed a permissions issue, thanks for the pointer.

[erjoalgo]

I do think that something is broken somewhere: why should debian-packaged jstest-gtk work with the joystick out-of-the-box but debian-packaged SDL/mupen64plus fail? I believe the answer is that jstest uses /dev/input/js* directly, which on my system has more open permissions than the /dev/input/event* files that SDL tries to read.

One possible workaround is to grant the mupen64plus executable input group permissions:

sudo chgrp input $(which mupen64plus)
sudo chmod g+s $(which mupen64plus)

However, I don't really like the idea of granting any executable keylogger-level, password-sniffing permissions. Perhaps a better approach would be to package and install the appropriate udev rules to automatically grant more open permissions to joysticks only.