Newer version of Linux / MiSTer binary or other MiSTer-devel component degraded / removed Xinput support

[wiggy808]

I had an original MiSTer image from UltimateMister.com in May. I was able to use Xinput on my X-Arcade (Tri-mode PCB has Xinput/Direct/Keyboard) before the update_all script was executed last week (for the first time so don't know when between May and now this problem occurred). Now only DirectInput works properly (tested on CPS1 and SNES cores for Street Fighter 2).

My button mapping steps:

1. I unplug X-Arcade (not necessary but for good measure)
2. Set Switch to Xinput mode on Xarcade
3. Plug x-Arcade back in.
4. Reset MiSTer
5. Select OSD and Reset to map new joystick
6. Map joystick 1 starting with A button on joystick 1
7. Redo step 6 with A button and map all of player 2 joystick controls.
8. Start SNES core —> load SF2 core
9. Bring up OSD menu
10. Select Map buttons for game using A button on joy1
11. Repeat step 10 but using A button and map joy2

Problem Observed: Using the exact steps above, when step 2 is on Xinput, Joystick 1 and Joystick 2 both move / control player 1 (same for CPS1 core SF2). When step 2 is on DirectInput, both joysticks work as player 1 and player 2 just fine and have all 6 buttons working as expected.

[theypsilon]

Just to clarify, update_all or the MiSTer-devel Updater (which is the one bieng called by update_all) has nothing to do with this issue.

What you really mean is that you think that a newer version of Linux / MiSTer binary or other MiSTer-devel component, removed the support for Xinput.

[wiggy808]

Thank you, I wasn't quite sure how to word this one. I've updated the title to be accurate, much appreciated!

[rhester72]

I don't think that's the case, though.

Perhaps something changed, but even iPAC users have this problem - a single device can only have one set of directional inputs. This was sometime around the press-A-to-activate-controller change happening, I'm afraid I don't have specifics, but I think this was a knock-on effect of another change that the author indicated would not be reverted.

[wiggy808]

@rhester72 not sure, but there is definitely a difference in results between the X-input and the DirectInput. Using the Xinput, I get a single device kind of result, so its no longer usable. Using the DirectInput, I get two devices one for each player as desired.

[sorgelig]

if X-Input wouldn't be supported then it wouldn't work at all. Problem is this specific device. Some input devices don't conform the standard where each input device should be presented as virtually separate device. Nothing to do with X-Input. Just this specific device may have buggy code used in X-Input mode.

[wiggy808]

Good point, except the only code that changed in this case was the MiSTer code. It worked fine before the update_all script ran and that’s the biggest key.

The other important note is that the Xinput selection still works great on my PC gaming (Street Fighter 5) and Raspberry Pi 3 and 4 even after updates to those devices.

I’ll open a ticket with the X-Arcade techs as well and see what they say, hopefully we get some more insight.

On Aug 3, 2020, at 9:07 PM, Alexey Melnikov notifications@github.com wrote:

 if X-Input wouldn't be supported then it wouldn't work at all. Problem is this specific device. Some input devices don't conform the standard where each input device should be presented as virtually separate device. Nothing to do with X-Input. Just this specific device may have buggy code used in X-Input mode.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[sorgelig]

I don't know which versions you are comparing. Because there are many composite devices having several virtual devices inside, MiSTer has to distinguish them. Before MiSTer used "uniq" field only, which had problems in many devices because many manufacturers misuse uniq filed and use the same (not unique!) value for all their devices. Now MiSTer uses USB device tree to find the "leaves" where each leaf considered as a separate input device. And in 99% it works fine, but some manufacturers are "smart" enough to break even this rule and put several input devices belonging to different players into a single "leaf" in this tree. So MiSTer has no way to distinguish the players from such non-standard devices.

[wiggy808]

That’s really interesting , I like details like that. I wish I had a MiSTer version for you, unfortunately dates is the best I can do:

June: MiSTer with Xarcade using Xinput works (CPS1 and SNES tested) July: MiSTer update_all script ran, MiSTer with Xarcade using Xinput don’t work (CPS1 and SNES tested).

I did get a response from Xarcade support regarding the Xinput and it’s implementation. They replied on two occasions, here is the combined:

“Works fine with Android, NVIDIA Shield, PI, PC, Mac, Unix. etc. These systems benefit from large quantity of developers/commercial support, years of driver updates.....

We cannot provide any help for open-source third-party systems like this.

...

Issue is that these systems have developed input controls/mappings. Mister does not.

X-Arcade is a keyboard, so if you instead used your keyboard to play games, you would just need to map the keys assigned to X-Arcade Player 2 to functions of Player 2. If you cannot do that on Mister, that's a limitation of Mister mapings.

If you are using Direct inptu or XINPUT, that's also a limitation of Mister if they are only able to read a single USB Game Controller although 2 are connected to 1 USB port. “

The last paragraph is interesting. Let me know if I can help with more info, but all I can verify that: Xinput worked on Xarcade before the update_all script was ran in July.

On Aug 4, 2020, at 2:52 PM, Alexey Melnikov notifications@github.com wrote:  I don't know which versions you are comparing. Because there are many composite devices having several virtual devices inside, MiSTer has to distinguish them. Before MiSTer used "uniq" field only, which had problems in many devices because many manufacturers misuse uniq filed and use the same (not unique!) value for all their devices. Now MiSTer uses USB device tree to find the "leaves" where each lief considered as a separate input device. And in 99% it works fine, but some manufacturers are "smart" enough to break even this rule and put several input devices belonging to different players into a sing "leaf" in this tree. So MiSter has no way to distinguish the players from such non-standard devices.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[rhester72]

@OP: You are having literally exactly the same problem (for the same reason) as detailed in this thread:

https://misterfpga.org/viewtopic.php?f=32&t=448

[wiggy808]

Yes! Thanks for the link.

I read through it and thought well, I’m not the only one affected, I-pac/J-pac users are too.

Looks like this was in early to mid June, which is the timing of my issue too.

Should I try the steps laid out by the OP? I hesitate because the OP puts a note that makes it sound like J-pac users are in same boat as XArcade users:

“ Note: You CANNOT change the key mappings for Player 2. This is a limitation of the current implementation of MiSTer, as it expects each player to have a unique device. A J-PAC/I-PAC etc is treated as a single keyboard, so it is impossible to map each side separately.”

On Aug 4, 2020, at 6:07 PM, rhester72 notifications@github.com wrote:

 @op: You are having literally exactly the same problem (for the same reason) as detailed in this thread:

https://misterfpga.org/viewtopic.php?f=32&t=448

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[Nousjadeul-Ger]

Just to chime in, I have a newer version of the JPAC (2019 model) that allows changing modes and it no longer works in Dual Xinput mode on my Mister for Player 2 support. It was working around May and now Player 2 only provides the Player 1 inputs (same inputs on both sides). I understand that there's an alternative way to set it up in Keyboard Mode but that actually does not appear to work for all JPACs. Keyboard mode is Mode 1 and my JPAC does not provide the VID/PID when trying to obtain it via the Mster. And even after obtaining those values from the JPAC developer and plugging them into the Mister INI it still does not allow me to map the inputs through the mister. This Keyboard mode workaround does not appear to be compatible for everyone.

For now I've reverted back to the original Dual Xinput mode and I'm just stuck with only Player 1 support.

I'm concerned that things are just going to be left as-is based on comments above. Is this going to be looked into or are we SOL?

[sorgelig]

Any USB device provides VID/PID. I see here users have little technical knowledge and it becomes to "me too" thread leading to nowhere. I suggest to move to forum for discussion where other owners of JPAC/IPAC and similar devices may help to setup it correctly.

[paulb-nl]

This should be fixed. VID & PID can be set in MiSTer.ini in no_merge_vid & no_merge_pid and player 2 should work.

https://github.com/MiSTer-devel/Main_MiSTer/blob/404eec311fd3f96bcfb43aba17a5c80c6da65001/MiSTer.ini#L115-L118

[sorgelig]

yeah, i've thought about it too but i have no such HW to verify.

[wiggy808]

Tested, and now Xinput mode on my TankStick is letting me use both joysticks each as P1 and P2 separately as desired. Tested on CPS1 SF2 and on SNES SF2.

Couple questions.

1. When was the no_merge_vid/pid options added. I saw this example in my latest "MiSTer_example.ini" but never thought to look there for a solution until I saw @paulb-nl 's post.
2. What is that option doing and is it to remedy the TankStick Xinput mode specifically?

[paulb-nl]

The options were added in september. MiSTer tries to detect if separate input devices should be merged but sometimes it merges devices that shouldn't be merged like player 1 & 2. I think the PS4 controller is an example of a device that should be merged. So the no_merge options force disable merging for the provided VID/PID.

[ghorricks]

X-Input - maybe thats what my 8Bitdo N30 uses. In this same time period, I noticed my 8Bitdo N30 stopped working. It pairs via BT using multiple dongles, however MiSTer wont allow me to define DPAD right (despite changing the function of the D-Pad using SELECT and up, down, left or right). Seems like it supports SWITCH... works fine, WIndows... works fine. Used to work with MiSTer but not it doesnt at all... although it connects correctly, is recognised etc.

[x0rtrunks]

Is no_merge_pid and no_merge_vid actually working in V220108? I have two 8bitdo controllers, SN30 and M30. The SN30 in bluetooth mode and the M30 in wired mode both share the same VID/PID values 045E:028E. I've added those values to the no_merge lines but when mapping one or the other the map file gets overwritten regardless.

no_merge_vid=0x045E no_merge_pid=0x028E

Am I misunderstanding how the no_merge is supposed to work? Thanks.

[sorgelig]

no_merge option has no relation to button mapping. All devices with same VID:PID share the same button mapping. If you want different mappings then try to switch one of your controller to other mode like d-input, so it will get different VID:PID.

[x0rtrunks]

I should have mentioned that when using these controllers in 2 player games each controller is able to control both 1p and 2p at the same time. Does that make sense?

[sorgelig]

sounds as an issue if both controllers are treated as single.

[x0rtrunks]

I've done some more testing and I think I've unraveled some of the issues but still some remain. If I can pin it down further I will create a new specific issue. The 8bitdo controllers sharing an ID is apparently a known issue and not much can be done about it. I've worked around the buttons over writing the mappings for each other by reversing the mapping on one and then when I map the other controller it corrects the button mapping on the first.

The issue of 1p and 2p inputs controlling each other still exists though. I just have to pin down exactly when and where.

[sorgelig]

The problem probably because one controller has UNIQ field (because wireless) and another don't (not all wired controller have it). And having the same VID/PID MiSTer treat the later one as a part of earlier. I suggest to switch one controller to other mode and it will have other VID/PID. Pretty much simple fix.