Cross-binding between green/downstrum as well as red/upstrum, RCM/Santroller 10.1.151 in HID mode

[LocalH]

I wish to use the input display with RB3DX on RPCS3. For this game, I run my RCM guitar in HID mode, and use the latest version of the RCM-branded Santroller firmware, which is v10.1.151. I am able to properly map all buttons. However, both upstrum and red result in a binding of button 11, and both downstrum and green result in a binding of button 12. yaid is the only software I'm using that reports these button mappings. joy.cpl shows the strum bar on the dpad/hat. An online tester I found showed the strum bar on axis 9 (?). I'd rather not switch my guitar to Xinput mode, as I feel HID mode gives me better playability. This is all tested without RPCS3 even running, as I don't see how that would make any difference.

[raphaelgoulart]

Thanks for the report, this is presumably because Godot for some reason always maps dpad up/down to buttons 11/12 regardless of controller (I've yet to test more to confirm, especially test different, non-guitar controllers). This is, however, outside of my control; I've tried Input.add_joy_mapping() to set a custom mapping but it did not work, and there are no other methods to modify how Godot detects controller input; it's simply an issue with the engine itself.

I will open an issue in Godot's repo itself once I gather more data to create a high quality bug report, hopefully increasing the likelihood of it being fixed.

[LocalH]

If there's anything I can do to help you gather information, let me know.

[raphaelgoulart]

Check if other controllers (guitar or otherwise) also reports dpad up/down as buttons 11/12 in yaid (or Godot's Joypads demo, which should be easier to visualize, let me know if you want me to compile it for you), and report which ones do, and which ones don't

Bonus points if you're able to replicate the cross-binding bug in other controllers (surely it's not only Santroller that uses buttons 11/12?)

Once I'm done with some urgent work matters, I'll also test this with the controllers I have, compile the info and open up the issue (and thanks for the availability!)

[LocalH]

I don't have a Godot development environment set up, so it would help if you would compile the Joypads demo. I have an overstrumming Xplorer I can test with, as well as a couple of bootleg DualShock 3s. I'm not sure if any of those use buttons 11 and 12 (which I'm pretty sure are 12 and 13 in joy.cpl), but I'll check.

[raphaelgoulart]

https://drive.google.com/file/d/1kVUibPdVWqxNnt07bp-ucLzEv1SnOSL-/view?usp=drive_link There you go, the bug happens here (G/R detected as dpad up/down)

[LocalH]

The Xplorer uses button 0, 1, 3, 2, 9 for GRYBO in that order, and 4 and 6 for back and start, so no conflict there. The bootleg DualShock is weird, as it doesn't seem to really have a dpad in joy.cpl terms, just a bunch of buttons (5,6,7,8 are URDL respectively). Joypads demo reports 9 for down and 10 for left, up and right don't seem to register. In joy.cpl, R1 registers as 12 and triangle as 13 (since it's one-based) yet in Joypads R1 is 8 and triangle is 5.

[raphaelgoulart]

Yeah, the bootleg dualshock kinda blows my theory that "dpad up/down is always 11/12" out of the water, haha. I'll still test the controllers I have, but it looks like a Santroller-only issue (still Godot's flaw as everything else works fine with it) rather than a problem with controllers in general

[SkyJumper409x]

If there's anything I can do to help you gather information, let me know.

Due to inputs being received twice on the same frame for xbox360 LPs, I added something that "eats" those cloned inputs by ignoring identical inputs on the same frame, i could imagine similar duplication of inputs going on with different button ids, and one button basically taking priority while mapping.

I created an admittedly messy build that will print a message to the command line if it detects multiple inputs occuring on the same frame.

windows: ya_inputdisplay-debug_duplicate_inputs-win64.zip linux: ya_inputdisplay-debug_duplicate_inputs-linux64_x11.tar.gz on windows, run the file ending in .console.exe via the command line/cmd; on linux, run the .sh script. it should log when multiple inputs happen on the same frame. Can you by chance check if anything is detected? (Keep in mind that pressing two different buttons on the same frame on purpose will be logged too, but not "eaten", so they might just be logged when you actually hit two buttons at once)

[raphaelgoulart]

(disclaimer: haven't yet tested the build)

The main issue is that Godot itself detects those buttons as the same ID (as confirmed by Joypads demo showing the same behavior), hence the issue

[SkyJumper409x]

i know. there are some preset input mappings in the project settings that can be adjusted but they seem to be only related to UI stuff, not regular input events.

[SkyJumper409x]

woops, i sent older builds. these should be newer and yield more information linux windows