MiSTer FPGA Forum

I've built several custom joysticks with various buttons and sticks but Ive run into a problem with Mister in that it detects them all as the same joystick ie their joystick ID are all the same.

This causes two big problems, firstly because they are all slightly wired differently they need their buttons reconfigured all the time as I swap joysticks and cores.

The second problem is that two player just doesn't work as only one player has the right button configuration at any one time.

The really strange thing is that Mister does recognise them as two different joysticks. As in one joystick works for player 1 and the other works for player 2 i.e the buttons don't collide/overlap it's just one joystick has the wrong mapping.

Anybody know a work around for this or if there is a fix in the pipeline?

This is the interface board I'm using in all the joysticks: https://www.arcadeworlduk.com/products/ ... ry-pi.html

its works off the PID/HId of the controller board. You have used the same boards in yuor custom joysticks so as far as the Mister see it you are plugging in exactly the same joystick each time.

You either need to use a different interface board in each or find a way to change the hid/pid of the controller

Yes so thats not quite true - MiSTer or at least most arcade cores recognise that there's two distinct joysticks as in when you move the first joystick it will display the button mappings for the first player and when you move the second joystick it will display the button mappings for the second player. This even follows through into the actual game - I can move player one independently of player two using the associated joystick. The only thing I can't do is give them separate button mappings.

FPGA64 is right on the money. MiSTer identifies devices by their PID/HID and plugging additional controllers with the same PID/HID will inherit the buttons mappings for that specific USB device. There's an article on the wiki that goes in to input devices and mapping.

Anybody know a work around for this or if there is a fix in the pipeline?

This is working as intended. You will need to either wire your arcade controllers using that USB encoder identically, continue to remap as needed or use another controller board.

I don't know if you both read my initial post - it states quite clearly (or so I thought) what youve both said. I fully understand that the button mappings are set/stored under the joystick ID (which is made of the PID/HID).

However Mister IS detecting and uniquely identifying both of the sticks as when I move the stick associated with player one it only moves player one and when I move the stick associated with player two it only moves player two.

Therefore at some level Mister knows there are two different sticks. I'm wondering whether Mister can use this information to store the button mappings.

As far as I can think, maybe it's to do with the usb port and whilst you may not want to store button mappings per usb port in the general case maybe there could be an option that when turned on links a button mapping based on usb port and joystick ID.

Maybe though there is some other thing that is going on that explains the behaviour I'm seeing.

Ok re-reading the first paragraph of my initial post is not as clear as I had intended. So apologies for that. I fully understand though that as it currently is the button mappings are mapped to joystick ID and as my joysticks all have the same ID they effectively all have one mapping which then leads to the problems I'm seeing.

billythefisherman wrote: ↑Sat Aug 06, 2022 1:20 pm Anybody know a work around for this or if there is a fix in the pipeline?

I cannot think of a way how it could work otherwise. Devices with the same usb ids actually are all the same for the linux kernel. It has no further way to differentiate them, and will not neccessarily enumerate them in the same order on boot. So it makes sense that MiSTer stores one configuration per id combination and applies that to every instance.

mapf wrote: ↑Sat Aug 06, 2022 5:41 pm

billythefisherman wrote: ↑Sat Aug 06, 2022 1:20 pm Anybody know a work around for this or if there is a fix in the pipeline?

I cannot think of a way how it could work otherwise. Devices with the same usb ids actually are all the same for the linux kernel. It has no further way to differentiate them, and will not neccessarily enumerate them in the same order on boot. So it makes sense that MiSTer stores one configuration per id combination and applies that to every instance.

Ok so let's try this from a different direction (as I'm obviously not explaining my self well) So you're right, the above is true, I know it is BUT how do you explain the behaviour I am seeing as in I have two joysticks both with the same joystick ID/usb ID/PID-HID but when I am in a two player Mister core I am able to use joystick one to move only player one and I am able to use joystick two to only move player two. If Mister truly sees them as the same joystick why doesn't both sticks move player one and neither of them move player two (as would be expected if there wasn't something else going on, on top of what we've both agreed above).

you're confusing one essential part, the identifying part is correct, same hid / pid is the same device, no way to differentiate any further.

that it sees two devices that can operate apart from eachother without one device influencing the other is because these devices are each connected to their own usb port and the system / os can enumerate through that, effectively you have two devices that are equal but still can operate independant from eachother.

MostroW wrote: ↑Sat Aug 06, 2022 8:17 pm you're confusing one essential part, the identifying part is correct, same hid / pid is the same device, no way to differentiate any further.

that it sees two devices that can operate apart from eachother without one device influencing the other is because these devices are each connected to their own usb port and the system / os can enumerate through that, effectively you have two devices that are equal but still can operate independant from eachother.

Ok great now we're getting somewhere and this is what I was alluding to above: can't we have an option that when set to true allows us to store a button mapping on a 'usb port + joystick id'? I get that that you can't guarantee order of enumeration BUT in a fixed system it will always be the same order unless some software update changes that which will be very infrequent and the only problem that will occur is that you'd have to either remap all your buttons or swap around the ports the joysticks were in. It's pretty much a non issue and in return you can have custom near identical devices plugged in and them have their own unique button mapping.

in that manner of regard i'd probably suggest to add mapping profiles to devices, so you could select different profiles for devices regardless of hid / pid or usb port.

maybe the possibility to assign default mappings to player ports, so that joyport 1 could have a different default mapping in regard to joyport 2?

I'm not not sure about that as you still want it automatic - it'd be a pain to have to select an input profile every time you boot and then comes the problem of how would you select it in the first place. I havent checked RetroArch yet to see how it deals with this problem.

it would be very hard to distinguish same devices on different usb ports

for example:

given two identical joypads, one on usb port 1 and the other on usb port 2.
pad on port 1 used profile 3 and pad on port 2 uses profile 5.
now swap these devices on the ports so pad 2 is now on port 1 and vice versa.

how would you suggest the system would / could make any distinction between these two?

the only other thing i personally could think of is that the device has a built in hardware profile memory that allows storing / switching configurations.

Yeah this isn't a problem though - just as it isn't a problem that the current way it works doesn't really work for all use cases as we've discussed. Sure in the above example your joysticks buttons would be wrong BUT you've explicitly set this mode of operation to true so you live with the fact you can't swap over usb ports for your joysticks in return for other benefits.

Think of the situation of a user with an arcade cabinet - they will (nearly) never want to swap usb ports but they will find having support for different button mappings for near identical joysticks a boon.

This mode of operation would not be the default, you'd opt into it. Also even if you did swap them over in the ports all you have to do is reconfigure the buttons again. It's no biggee and doesn't need any over engineering to try and solve edge cases: we know it's got weaknesses but it has strengths too.

Could it be possible that someone could build a small, add-on USB device that could solve such a problem? I ran some offline Fighting game tournaments at EVO2022 last week, and this issue comes up, because a huge % of the community uses Brook pcb's. Luckily most people use the exact same button config for Street fighter games. But you do come across a couple people with their devices wired differently. And in the case of NeoGeo, people use all types of different configs.

It's definitely an unfortunate issue. I hope one day, some people way smarter than me, can solve it

I custom made two arcade sticks using the same brand and model of USB interface and faced the same problem. My solution was to rewired the buttons exactly the same for the two sticks and now it works as expected. The only problem is that you cannot have different configurations for each sticks but I am ok with that.

The same issue is becoming an ever increasing problem for fighting game tournaments. At Fight Kingdom 2023 a lot of time was spent when two players with custom sticks that had the same board and different wiring had to play against each other.

There should be a "tournament mode" setting where input is based on USB id instead of PCB id. In this case, one USB slot can be designated for player 1, and another for player 2. Players plug their sticks into the appropriate pre-designated slots, and button configs are saved on a per slot basis.

Is there an issue tracker where this issue can be reported to the dev team?

I've posted an issue tracker on github here: https://github.com/MiSTer-devel/Main_MiSTer/issues/782

Please feel free to comment there to raise visibility!

+1 for this feature zass mentioned

if the MiSTer is going to be used for FGC tournaments, there should be an easy way to connect USB devices in a way that defines them as player 1 vs player 2

I wouldn't count on this being changed in MiSTer any time soon (if ever).

A workaround for this is to use one or more of Mayflash's MAGIC adaptors that accept USB controllers. The host (MiSTer) will see the adaptor and not the real controller behind it. Another trick is to use the different modes (XInput, DirectInput, etc.) as different profiles for your controller, as the host will see each mode as a different type of controller.

jlancaster86 wrote: ↑Sun May 21, 2023 9:33 pm

I wouldn't count on this being changed in MiSTer any time soon (if ever).

This was added yesterday to the unstable branch

ahh, very cool

the MiSTer community is full of some hardworking people, creating the best way to play retro

Lightwave wrote: ↑Sun May 21, 2023 11:08 pm

This was added yesterday to the unstable branch

Exactly what was added? I have been hoping for a revamp of the input system from the beginning to be more like Mame. This sounds like a step in the right direction. Do you have a link to the details?

Edit: I see this is in the .ini file:

; Enable per controller and per USB port mapping, both gamepads and keyboards
; Even same model of controller connected to different USB ports will have different button sets,
; thus make sure to define buttons for all controllers if you set this option to 1.
controller_unique_mapping=0

Sounds great. Just to be clear, if you turn this on, does it make all controllers map to player 1? So if I have USB pedals, and separate USB stick shift, and a separate USB steering wheel, they would all work together for player 1? I hope so. This could be configured per core section in the .ini file. Alternatively, this might map each USB controller to different players. I have no idea.

thorr wrote: ↑Mon May 22, 2023 3:53 am

Just to be clear, if you turn this on, does it make all controllers map to player 1?

No, this won't merge different controllers together for a single player (which is a separate feature request that would also be nice to have in certain cases).

Player controllers will still be assigned to successive players in order of activation as usual (1st controller touched becomes p1, second controller touched is p2, etc.). The difference with this feature activated is that if for example p1 is using a DualSense and p2 is using a DualSense, they can map buttons differently in the same core without affecting/overriding each other. This was not previously possible (as any specific controller could only have 1 map per core, and any attempt to remap would affect all controllers of that type).