@Comic-Sans Hey - bit late to the party here, but incase you (or anyone reading in future) swings by...
I'm making an arcade machine of my own (albeit mini). After a first proto (enclosure for a 5" display and USB ports for a few retro USB controllers) I decided to make a slightly larger one (7in screen this time) - and I also wanted arcade buttons.

I got the EG Plays ones (specifically these: https://www.amazon.co.uk/dp/B075DFNK24 ) and I've been really pleased with them. The stick is sturdy and feels really nice. The buttons are perhaps a little cheaper looking than some, but they're really responsive too and look really nice when lit up.

That's not to say the Sanwa ones (which I don't know much about) wouldn't be noticeable better, but at the end of the day I see many of these things as things that could be upgraded. The dimensions etc appear to be somewhat standard across both brands (and others). The type of person who builds an arcade cab is likely a hobbyist - so I'm sure the EG buttons won't go to waste if you replace them in future with better ones :)

There's a single encoder board which everything plugs into (with extra connections for other bits, etc) and this goes straight out via USB. I had these all plugged in and tested in my computer within 5 minutes of opening the box.

Good luck!

@jbsapp
Great information.

I was curious and managed to locate a little detail on the fuzz and other arguments.

https://stackoverflow.com/questions/16110515/explanation-of-fuzz-and-flat-in-input-absinfo-struct-in-input-h

You can find that

fuzz: specifies fuzz value that is used to filter noise from the event stream.

Which means that the input system in linux will drop events generated by the device driver if the difference from the last value is lower than the fuzz. This is done in the input layer.

Another user posted:

So it would seem that any changes less than fuzz are should be filtered out / ignored.

Also,
https://python-evdev.readthedocs.io/en/latest/apidoc.html
The Device section talks about the fuzz argument.

@mitu Cool, thanks! That puts my mind at ease.

@mitu Ummmmmm.... maybe! Hahahahaa. Skimming through, looks like what I need, I'll have to try it tomorrow.

THANKS!

I'll update this post as needed. I'm certain it will be needed... lol.

The controller configuration for Daphne is explained in the Docs.

lr-daphne seems to be dead (only one minor commit since Sep 2019). The most promising Daphne fork at the moment seems to be Hypseus-Singe. It is mainly discussed here and here.

Which files were conflicting? I'm having a similar problems, but with n64 instead.

Taken from the website:
xm-10.png

Everything worked flawlessly, I really appreciate the event lookup code, I never would have figured that out. I did notice that if a hotkey was enabled that it does not work which I believe you mentioned in the other thread. All in all it does exactly what I wanted it to do.

Try to test the encoder using jstest - (see here) - to check if the joystick and buttons produce correct results.

Is there a schematic you've followed to wire the joystick and buttons to make sure they're correctly wired ? Or does the encoder has labels for each connections indicating the correct wiring ?

@uraverageplayer What emulator/game are you starting when it's not working ?
Configuring the joysticks in EmulationStation would automatically create a configuration for RetroArch based emulators (the ones that start with lr-), but certain emulators are not auto-configured (i.e. advmame or mame4all).

TLDR; -- map your USB encoder to match USB console pads

REYANN ENCODER appears to work best as
0:B, 1:A, 2:R1, 3:Y, 4:X, 5: L1, 6: L2, 7:R2, 8:SELECT, 9: START

Did some more work with this. The joysticks work great when (when mapping of multiple are the same - as discussed). There was an issue where I started to need to remap per system if I was using USB console-like controllers.

It started out to be fine, then started to become a pain - especially once I found and started to use this GEM by @meleu
https://retropie.org.uk/forum/topic/740/having-more-than-one-player-1/18

Since one set was remap, and the other wasnt, the graceful fallback didnt work.

I rewired the USB encoder pins and its all working great. PIN:BUTTON layout at the top. LOVE I

@grant2258 I have followed this video, but I can't get it to work properly. Maybe it is a version issue (I use a CH-616). When I connect the COIN and COUNTER to the encoder, the voltage is always running. It seems like the contact of the coin module is not potential free. So when I try to use it in retropie, it constanly thinks I am throwing coins in it. Did anyone get this running properly?

@DorkVonWaterfall
I can't see in the images well enough to know exactly where they are, but those encoders look a lot like the ones I got. My encoders had two sets of plugs for the joystick - one the 5 pin white cable you're using, and the other used 4 of those 2-pin plugs. They should be labelled as such. If you have anything in the 2-pin dedicated joystick plugs, you need to move them to another plug. That will cause interference of the signal.

^Someone posted this for me and it was the solution. I put the led connector in the left joystick input connector. Thanks for the help man

RetroPie does controls per controller/encoder name, so if two controllers share the same same name, if you change one, you change the other. If you have 2 different controllers using the dragon rise encoder, but they are different, it may be that one is wired up differently than the other.

@robertvb83 said in Zero Delay usb controller Mode and function switches:

accept analouge input by switching the dragonrise mode to analogue...

when the light is orange/red its in analog mode when its green its digital. if you want a true analog control you are probably going to have to add a analog sensor of some sort to it though. The mode button press changes this

@caver01 Great then, thanks!

@mitu 0_1517607033957_upwrk.png

For example... you don't mention what USB controller board you are using.

I am using 2 x Sanwa JLF joysticks via an Ultimarc IPAC2. But I'm not going to explain at length what you need to do if you're not even using the same board :P

@jayofcastleford those buttons are probably analogue rather than the digital 1 or 0

The rubber will be less conductive, and the more it is squashed, the lower the resistance. If you have access to a multimeter, try measuring the resistance between the 2 points then vary the levels of pressure and see what happens