Autofire on the axis

[monchote]

Thanks a lot for double checking and uploading the patch.

Out of curiosity, couldn’t this be submitted as a pull-request to the RetroPie Github repo so it’s fixed for future releases?

[hijinksensue]

As far as I can tell, this kernel hack doesn’t work with 3.0 for both players.

I ran the upgrade binary script.
Then I ran the new most recent Kernel hack update.
Then I ran JSTest and it sees every button on the Xin-Mo individually, but still registers it all as one big controller (which is what I believe it always did).
Then I ran the input config option within Retropie. It said it detected 3 controllers (I assume Xin-Mo one and two plus the keyboard?), but no matter which button I held down it said I was configuring for player one.
Same happened when I used the old school controller config option within the Retropie settings.
At least for now, my player 2 is dead.

[feederchain]

@monchote… The directional fix, as I understand it, is that the device not really behaving properly. The kernel is filtering out these out of bound inputs. The patch here just stops that filtering. I may have read wrong information in the past, but when I was first searching for this problem I recall that being an issue. I don’t know if it causes issues with other devices. That could be the reason why it hasn’t gone into anything. I’d have to double check but I’m pretty sure it’s the same issue in other distros not related to the raspberry pi.

@hijinksensue… Ya this never fixed the device being seen as two separate joysticks. I didn’t try and get the second controller to work in emulation station itself. I don’t need the second controller working there. As for RetroPie itself. I keep a backup of my retroarch.cfg. So I just put that one into the config/all directory that was samba shared for me. That worked without a hitch.

[hijinksensue]

I might be confused, but in 3.0 they seem to have integrated the EmulationStation controls and the Retroarch controls. There’s only one set up as far as I can tell and it’s supposed to cover both. Am I missing something important?

[monchote]

@feederchain I’ve been doing some more investigation and I think this patch could be the real fix for both the autofire and the 2-player input.

The author never submitted the kernel patch upstream and thus it’s still not fixed.

I won’t have time to compile and test the patch until the weekend so if you happen to do it before then, please let us know!

[feederchain]

@hijinksensue… It’s true that they did make it so that the controller setup in 3.0 would also go to retroarch. My assumption is that they would just be writing that button mapping into the retroarch.cfg. I didn’t confirm that. I assumed that I was still going to have the issue with both controllers on the same joystick port. So one of the first things I did was replace retroarch.cfg.

@monchote… I’ve run into a couple quirks earlier that reported to fix the multi input of my adapter, but they never worked. I’ve never seen the NOGET one mentioned before. I’ll have to look into this.

That being said. This looks specific to the Xin Mo. I’ll have to figure out the vendor id for my adapter. As it is that patch won’t do me any good. I’m not using that controller.

[monchote]

@feederchain: No worries, I’ll test it out on mine and if it works, I’ll post the patch here for the other people to test it on the 2-player configuration.

If it fixes both the autofire and 2-player issues, I plan to submit the kernel patch upstream so it works out-of-the-box in the future. If you find the vendor id for your adapter and it works, send it my way and I’ll include it in the patch.

[feederchain]

Most definitely. This looks like it would be a lot cleaner solution and less of a hack to what I’m compiling in right now.

[hijinksensue]

@monchote Exactly! This hack DID fix my 2 player issue (in 3.0 beta). I never actually had the original auto fire issue in the first place. 3.0 (proper) seems to have undone that fix. Whether it was an accident or not, it worked.

@feederchain I have the Xin-Mo 2 player (or at least that’s what I paid for) but it shows up in Retroarch as a “THT THT 2 Player USB.” From what I understand, they’re essentially the same hardware.

Please let me know if I can be of help testing anything.

[darkheart1984]

Is there a better encorder that I should switch to over the Xin one so I will not have issues if I update

[feederchain]

OK… so monchote…. you sparked something in my brain with your talk of quirks. Or at least that patch you referenced.

While I has dealing with this months ago I remembered reading something about adding a quirk on boot. But I didn’t get it to work. Looking back now, it’s because I didn’t know what I was really doing then.

Anyway… So I figured out my vendor/product ids 1292/4745.

Which is when the spark happened. So you are allowed to add the following to the end of /boot/cmdline.txt

usbhid.quirks=0x1292:0x4745:0x040

The first two numbers are my vendor/product. The third is the quirk. Found here http://lxr.free-electrons.com/source/include/linux/hid.h#L313

So the 40 is for multi input.

So with my kernel and this above. I was seeing two controllers and they both worked.

You can find the vendor/product using
lsusb

returned this for me
Bus 001 Device 005: ID 1292:4745 Innomedia

So the next logical step was to try and use HID_QUIRK_NOGET with a virgin kernel and see if the directionals work. Replaced the 40 with the 8.

Unfortunately that didn’t work for me.

Hopefully for you compiling in the quirk will help.

[monchote]

I’ve finally had some time to test the Xin-mo dual controller with a fresh installation of RetroPie 3.0 and the autofire on the axis issue no longer exists, so applying the previous patch is not needed anymore. Great news!

With regards to it not being recognised as 2 controllers, I’ve tested the addition to /boot/cmdline.txt method that @feederchain describes above and it also works with the Xin-mo dual controller. The code to add to the end of the line (after a white space) is:

usbhid.quirks=0x16c0:0x05e1:0x040

Reboot required after saving the file.

Having reached this solution, I’m not going to bother trying to patch the kernel as this fix is simple enough for those of us with the Xin-mo.

Thanks very much to @feeder for all the help and effort!

[hijinksensue]

If we’ve already patched the kernel, should we somehow re-patch to the original kernel? Or would an apt-get update take care of that?

I will try it on the THT-THT 2 player USB version of the controller that is being sold as the XIN-Mo and see if this fixes its problems as well.

[monchote]

[quote=104538]If we’ve already patched the kernel, should we somehow re-patch to the original kernel? Or would an apt-get update take care of that?[/quote]

The ‘axis autofire’ and the ‘2-player controller’ issues are separate so as long as you’re not getting autofire, don’t worry about the kernel patch. Adding the string in my previous post to /boot/cmdline.txt should make the Xin-mo be recognised as 2 controllers.

[coccobanana88]

Then i don’t need to install the custom kernwell. I need only to write the line in cmdline.txt to let retropie recognize the xin-mo as 2 controller, right?

[monchote]

[quote=104802]Then i don’t need to install the custom kernwell. I need only to write the line in cmdline.txt to let retropie recognize the xin-mo as 2 controller, right?
[/quote]

Correct (for Retropie 3.0 only though).

[Anonymous]

Hi everyone,

Having issues with the Xin Mo running RetroPie 3.0 on RPi 2. It is being recognized as one joystick, which isn’t a problem running RetroPie 2.4 on my Pi 1 B+. The difference is that the ‘2nd player’ D-pad controls are now recognized as the same buttons, respectively, as my 1st player controls in jstest, where they properly registered on 2.4/Pi B+. For instance, Player 1 “Up” is ‘-0’, where Player 2 “Up” should be ‘-2’. It is now recognized as ‘-0’, same as the other joystick.

I attempted feederchain’s cmdline fix with my own vendor/product, but no luck. My query is two-fold:

1. Does it really matter if the Xin Mo controller is recognized as 2-player, so long as the buttons register separately and retroarch.cfg is configured properly? If not,

2. Is there a way to force those d-pad buttons to register separately?

This topic has been most helpful to me over the past few months. Thanks everyone.

[krauthaus]

My solution yesterday:

1st Step: Fresh new 3.0 Retropie Installation (with the boot/config entry a few Posts above -> usbhid.quirks=0x16c0:0x05e1:0x040 )

2nd Step: Added Games and Scraped them

3rd Step: A Backup of the SD with Win32DiskImager

4rd Step: Applied feederchains Kernel Patch (I had the same Problem like you. In snes games, for example, Both Joysticks moved Player one because they had the same axis entrys.)

Step 5: Modded the “all” config file like this:

input_player1_joypad_index = 0
input_player1_a_btn = 2
input_player1_b_btn = 1
input_player1_y_btn = 0
input_player1_start_btn = 6
input_player1_up_axis = -1
input_player1_down_axis = +1
input_player1_left_axis = -0
input_player1_right_axis = +0

input_player2_joypad_index = 0
input_player2_a_btn = 10
input_player2_b_btn = 9
input_player2_y_btn = 8
input_player2_start_btn = 14
input_player2_up_axis = -3
input_player2_down_axis = +3
input_player2_left_axis = -2
input_player2_right_axis = +2

Step 6: PLAYING! After this steps every SNES Game worked for both Players.

I wired the Buttons and Joysticks a few months ago. But i think i wired the second Joystick not like it should be. I reversed the cables. (I wired “up” to “down”, “left” to “right” and so on.)

:D

And again: THANK YOU AWESOME GUYS FOR THIS! :D :D :D

[coccobanana88]

[quote=104541]

hijinksensue wrote:

If we’ve already patched the kernel, should we somehow re-patch to the original kernel? Or would an apt-get update take care of that?

The ‘axis autofire’ and the ‘2-player controller’ issues are separate so as long as you’re not getting autofire, don’t worry about the kernel patch. Adding the string in my previous post to /boot/cmdline.txt should make the Xin-mo be recognised as 2 controllers.

[/quote]

EDIT: SOLVED by myself. I had to write so the same line of the other commands in cmdline.txt

thank you

I finally configure retropie 3.0 and plugin my xin mo. I add the line in cmdline.txt and look like this
[attachment file=”Cattura.PNG”]
but when I configure the inputs by emulationstation I have only one controller detected. I have no buttons connected at the xinmo right now and I can’t do the jstest I also checked the vendor ID and is the same, then the line is correct.

[feederchain]

@coccobanana88… Forgive me, So you solved your problem? You’re all good? Just want to make sure that you didn’t only solve one problem.

[stephane]

Hi guys,

I’m experiencing the auto axis issue with Amstrad CPC and Amiga.
I use Retropie 3.0 image and a Logitech F710 as controller.
In the Amstrad emulator it happening for up and down, clicking once the sprite go up or down without stopping and for the Amiga emulator it happening only for up, but up is like locked, I mean if I drive a plane the plane go up all the time without push any control key.

Do you have any clue ?

[feederchain]

@stephane… That doesn’t quite feel like the same issue that I had happening. I was experiencing more of a pulsing. As in the direction would flip on and off.

Have you tried the latest kernel compile in this thread?

Autofire on the axis

[stephane]

@feederchain : Thank you for your help, I finally found the solution.

The issue is the CPC Emulator RiCPC I decided to install the RiCaprice32 and the control works fine.

So I hope it could help the develloper to fix the issue control on the next release for the riCPC emulator.

Best ergarsd
Stephane

[hijinksensue]

Finally did the cmdline.txt edit and nothing is different than before I made that change. The controller still shows up at 1 usb controller.

Looks like I’m in the same boat as krauthaus above. If you examine his solution, you see that he’s just using the Xin-Mo as one big USB controller with a lot of buttons. In his config file both players are using js0. This solution DOES work, but it doesn’t address the Xin-Mo being seen as one controller vs. two.

Any ideas?

####UPDATE#####

Solved this myself. I put a blank line instead of a single whitespace between the original content of the cmdline.txt file and the new additions. When I switched it to a single space the Xin-Mo shows up as two controllers now. Leaving this here in case anyone else has the same problem.

[hijinksensue]

This might be off topic, but ever since making all these fixes on 3.0 I can no longer scroll through games lists using the buttons assigned to L and R shoulder. Anyone else?

[colinshare84]

hijinksensue, I ran into this problem too.

What you need to do is go into your es_input.cfg and make sure that your buttons refer to page up and page down, similar to the following example:

<input name=”a” type=”button” id=”4″ value=”1″ />
<input name=”b” type=”button” id=”5″ value=”1″ />
<input name=”down” type=”button” id=”1″ value=”1″ />
<input name=”left” type=”button” id=”2″ value=”1″ />
<input name=”menu” type=”button” id=”13″ value=”1″ />
<input name=”pagedown” type=”button” id=”11″ value=”1″ />
<input name=”pageup” type=”button” id=”10″ value=”1″ />
<input name=”right” type=”button” id=”3″ value=”1″ />
<input name=”select” type=”button” id=”8″ value=”1″ />
<input name=”up” type=”button” id=”0″ value=”1″ />

After the auto configuration in Emulation Station, my buttons seemed to refer to top left and top right or bottom left and bottom right.

Hope this helps!

[hijinksensue]

@colinshare84

I tried the changes you mentioned above and it initially just broke my es_input.cfg file. Then I realized editing the file in OS X Text Edit was changing the type of quotation marks used in the strings. I copied and pasted them from the line above, saved and I’ve got my page up and page down buttons back.

More users are having the same issues. https://www.petrockblock.com/forums/topic/pageup-pagedown-retropie-3/

There must be a bug that only affects some in 3.0.

[grey]

This thread is full of gold. Everyone here is amazing.

@feederchain and @monchote I freaking LOVE you guys. Thank you so much for your work on this! Thanks to both of you I just solved my Xin Mo controller issues! Thanks to that incredibly easy /boot/cmdline.txt edit all my issues are over! Xin Mo turns up as two controllers under /dev/inputs and I’ve been able to successfully configure 2 players in MAME and all other emulators fine. Im running Retro Pi 3.0 upgraded from 2.4 and no further issues here.

Freaking adore you all <3

If any of you have the time, check out my thread here:
http://thevideogameforum.com/showthread.php?tid=390

I’ve been documenting my first arcade build and I think it’s turned out fantastic. I just finished wrapping last weekend. After 2 months of building I can finally start enjoying it for its intended purpose, playing my fav arcade games.

One more time: THANK YOU ALL. THIS THREAD IS OFF THE HOOK.

Also heres a quick pic of the arcade wrapped:

[enigma90]

I have been having the same issue as everyone else on this page and glad to see I’m not the only one, I’ll work through these tonight but I think I updated the CMD line from reading another thread

My Retropie.cfg looks like this at the moment

input_player1_joypad_index = “1”
input_player1_up_axis = “-1”
input_player1_down_axis = “+1”
input_player1_left_axis = “-0”
input_player1_right_axis = “+0”
input_player1_a_btn = “3”
input_player1_b_btn = “4”
input_player1_x_btn = “0”
input_player1_y_btn = “1”
input_player1_l_btn = “2”
input_player1_r_btn = “5”
input_player1_start_btn = “8”
input_player2_joypad_index = “0”
input_player2_up_axis = “-1”
input_player2_down_axis = “+1”
input_player2_left_axis = “-0”
input_player2_right_axis = “+0”
input_player2_a_btn = “19”
input_player2_b_btn = “20”
input_player2_x_btn = “6”
input_player2_y_btn = “7”
input_player2_l_btn = “18”
input_player2_r_btn = “21”
input_player2_start_btn = “9”

Do you think that if I took the quotation marks out I will have this up and running? That being if the CMD line etc is all ok

However at the moment when I go into Emulation station/Retropie the joystick etc works fine however when I load an emulator no configuration is there except when I press Button 0 it does everything :S on the same button i.e Start, A, B. All in one go

I am a complete novice at programming etc so may need some more help. Is there any information I can copy and paste into a reply that you can let me know what’s right and wrong

[luckylocky]

Hi
I too have just signed up to say thankyou. I have just set up retropie 3.1 and can report the cmdline.txt edit worked! I am a complete noob but managed to follow instructions. 1 problem though, my reroepie decree my left side of arcade controls as player 2 and right side as player 1 (reversed) anyway I can fix this. It’s probably something simple but like I said I’m a noob. Feederchain any ideas?

[feederchain]

@enigma90 Quotes or no quotes. It doesn’t matter. As for the button map. You’ll have to check back in this thread to find what others have used. I find it odd that player 1 is mapped to index 1 and 2 is mapped to 0. That would probably swap them around. Also it’s odd that the button numbers don’t match between player 1 and 2. You can use jstest as a way to check which button does what.

@luckylocky Is you button mapping swapped? As in player 1 index is mapped to 1 and player 2 is mapped to 0. Or is it wired up wrong? There is references earlier to using jstest to check the buttons. You could use the that to see if it’s just the emulators that are seeing you controllers wrong or not.

[luckylocky]

All I did is your cmdline.txt then booted up retropie and held button on arcade left side. N mapped it, then held button on right side n mapped it. I notice when I held button left side said player pad 3 n right side said player pad 2. I did have a PS3 controller plugged n which was pad 1. Xin mo is wired up correctly so not sure why it is swapped. Maybe I held down left side first so it recognized it as pad 2? Could it be that simple?

[feederchain]

It may be just that simple. Have you tried checking the controllers with jstest?

Drop out of emulationstation and run

jstest /dev/input/js0

That should show you the buttons on joystick 1. In your case I guess you should check js1 or js2 since the ps3 is on 0.

[luckylocky]

Looks like button mapping index is swapped. I did a jstest and player 1 was js1 and player 2 was js0. So how do I swap them?

Appreciate the help, my family all arrive in 2 days so would be awesome to have fixed and running properly :)

Also struggling with n64 emulator the first one runs blurring in menu’s but races fine except joystick doesn’t work? Guessing cause in uses analog controls n not dpad which my joysticks assigned too, other 2 emulations don’t boot (they use to in retropie 3.0) so I installed the experimental ones n they run fine but no buttons work in game :(

[feederchain]

That is a good question. If they show up opposite in jstest. To me that says the OS sees it that way. May sound like a hardware issue. As is wiring? Other than that I’m not sure.

[Author]

Posts