Regression: Official wired Xbox 360 controller not detected

[richard42]

Originally reported on Google Code with ID 635

Operating System: Windows Vista (Service Pack 2)
Machine type: 32-bit
Mupen64Plus version: 2.0.0 (repository compiled on 18 October 2014 with M64Py 0.2.2)
Plugins used: GlideN64 (November Monthly Beta), Audio SDL, Input SDL, RSP HLE

An official Microsoft Xbox 360 wired controller (Hardware ID: USB\VID_045E&PID_028E&REV_0114)
is not detected using Mupen64Plus 2.0.0 with the repository compiled on 18 October
2014 by M64Py for version 0.2.2. The same controller works with the same repository
compiled on 9 March 2014 that was distributed with M64Py 0.2.1.

When running Mupen64Plus via command-line with the offending scenario, the message
"Input Warning: Couldn't open joystick for controller #1: There are 0 joysticks available"
is displayed. Using the same setup with the input plugin from 9 March 2014 does not
solve the issue.

I am using Squall Leonhart's XBCD 0.2.7 drivers, but the behaviour is still the same
when these custom drivers are uninstalled and the default ones are used.

Reported by mushman5@hotmail.com on 2014-11-11 07:29:59

[richard42]

Just tried it here and it works fine with M64Py 0.2.2 on Windows 7.

Can you check if it works with the binaries from the mxe builds

git clone https://bitbucket.org/ecsv/mupen64plus-mxe-daily.git

Please use the stuff in the folder i686-w64-mingw32 and then start to bisect:

git bisect start daffd89 a2b2305

It will checkout a version between the working and not working version. This is where
you do following

1. just test mupen64plus as you did before and stop it when you know what the results
are for this version
2. do either "git bisect good" when the gamepad was correctly detected (as in the version
from m64py 0.2.1) or "git bisect bad" (when it didn't worked as in m64py 0.2.2)
3. go to step 1

This has to be repeated until git tells you which build was the bad one. Please provide
this information here.

My best guess is that it broke with https://bitbucket.org/ecsv/mupen64plus-mxe-daily/commits/6364070db599f5cce9b6bebc2ccb74c9c10997f5
because SDL was updated in this version.

So following binaries should work: https://bitbucket.org/ecsv/mupen64plus-mxe-daily/get/da6f29b.zip

And following binaries should not work: https://bitbucket.org/ecsv/mupen64plus-mxe-daily/get/6364070.zip

If the first version works than you can also try putting this SDL2.dll in the m64py
folder.

And please provide complete logs. Not only what you think is relevant. Sometimes the
devs know better how to extract information from the logs

Reported by conchur@web.de on 2014-11-11 22:21:41

[richard42]

Richard42: Can you add copies of the XBox360 XInput version with the string "XInput
Controller #%u" (%u numbers starting from 1) to the controller config? This is how
SDL2 >= 2.1 is calling them under windows.

Reported by conchur@web.de on 2014-11-11 22:34:11

[richard42]

Aaargh. This Git stuff is such a struggle for me to get working, especially since lots
of the information for basic operation just isn't very accessible. I mean, I managed
to figure it out in the end, but I can't help but think it should be easier than it
was made.

Regardless, I followed your instructions and you were spot-on on every count. Here
is the result of the Bisect operation.

6364070db599f5cce9b6bebc2ccb74c9c10997f5 is the first bad commit
commit 6364070db599f5cce9b6bebc2ccb74c9c10997f5
Author: Sven Eckelmann <sven@narfation.org>
Date:   Mon Jun 30 11:56:12 2014 +0200

    2014-06-30

:040000 040000 7797032eb5c006da1f4d16d2d7423d3b99f00209 e6e91e9b05f0bd49b7cb605f9c581bd35c5f01b7
M      CHANGELOG
:040000 040000 ed6fdfa149d37ba692cc789755a7106e8d987fc6 5563f173a60689019e548a5631b4e3abaf562659
M      i686-pc-mingw32
:040000 040000 a9d691a970914899d44d22b5236b385317a07434 bf6059d3b1e1943058d933bb8226ff96140897d0
M      i686-w64-mingw32
:040000 040000 38d08c4c71ecd99cc92f14002eab52e7b97abfb8 9a79bc20e08c2808c8f6b6f33f4ea652ec00f3e9
M      x86_64-w64-mingw32

It was the exact build you predicted. The first binaries you linked worked and the
second ones did not. Copying SDL2.dll from that release to the M64Py 0.2.2 directory
solved my issue. Thank you very much!

I'm sorry but I don't know which logs you need. I absolutely understand that the developers
need unabridged records, but I'm not what you want me to provide or where it may be.

Reported by mushman5@hotmail.com on 2014-11-12 00:16:24

[richard42]

The stuff which is printed in the terminal when starting a rom in mupen64plus. Or in
m64py under help + log viewer

Reported by conchur@web.de on 2014-11-12 08:16:01

[richard42]

Thanks. These are the outputs of the last good version and first bad version without
being configured.

da6f29b75fd6381f51b27f89d82ff8ad3ccb9b8d (last good revision)
http://pastebin.com/uKf7ynkb

6364070db599f5cce9b6bebc2ccb74c9c10997f5 (first bad revision)
http://pastebin.com/0DTUDkb8

Out of curiosity, how do I get a particular revision using Git? I tried using the Fetch
command but I couldn't get it to work. I tried executing the command with the working
directory both inside and one above the repository's directory specifying the repository
as "mupen64plus-mxe-daily" and using the commit ID. In the end I just tested with the
linked builds.

Reported by mushman5@hotmail.com on 2014-11-12 09:23:33

[richard42]

You can just checkout the revision you want (must be done in your cloned working directory):

git checkout 6364070db599f5cce9b6bebc2ccb74c9c10997f5

Ok, it seems to be an SDL problem. Maybe you can contact the SDL2 team at http://www.libsdl.org/
to find out why it doesn't work for you but for me... but worked in SDL2 2.0.0. The
number of joysticks is directly from SDL_NumJoysticks. So no real mupen64plus code
used to get to this result. 

Reported by conchur@web.de on 2014-11-12 11:10:11

[richard42]

Thanks very much for your help. I will forward on the issue. Apologies for misidentifying
your project as the cause.

Reported by mushman5@hotmail.com on 2014-11-12 11:23:05

[richard42]

Was forwarded to https://bugzilla.libsdl.org/show_bug.cgi?id=2781

Reported by conchur@web.de on 2014-11-16 19:54:12