Regression: Official wired Xbox 360 controller not detected

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by mushm...@hotmail.com on 11 Nov 2014 at 7:29

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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/6364070db599f5cce9b6beb
c2ccb74c9c10997f5 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

Original comment by conc...@web.de on 11 Nov 2014 at 10:21

[GoogleCodeExporter]

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.

Original comment by conc...@web.de on 11 Nov 2014 at 10:34

[GoogleCodeExporter]

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.

Original comment by mushm...@hotmail.com on 12 Nov 2014 at 12:16

[GoogleCodeExporter]

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

Original comment by conc...@web.de on 12 Nov 2014 at 8:16

[GoogleCodeExporter]

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.

Original comment by mushm...@hotmail.com on 12 Nov 2014 at 9:23

[GoogleCodeExporter]

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. 

Original comment by conc...@web.de on 12 Nov 2014 at 11:10

[GoogleCodeExporter]

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

Original comment by mushm...@hotmail.com on 12 Nov 2014 at 11:23

[GoogleCodeExporter]

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

Original comment by conc...@web.de on 16 Nov 2014 at 7:54