XBOXDRV Guidance Needed
-
yesireebobbyjimbo.
-
Grumble Grumble
I hate opening up old threads, but it looks like I'm back into this whole XBOXDRV again. Turns out, I'm having issues where the RunCommand menu won't trigger with my Xbox controller on any of the systems I configured in the
runconmmand-onstart.sh
file. To counteract this, I tried adding a mapping inside the if/then statements to include the Xbox controller. But that doesn't work. I wonder if it's a mapping issue, and not necessarily a driver issue. I just did a simple cut and paste without really thinking about it.For starters, I'm having trouble with NES. Originally, I only had the Xbox controller, and it sent over proper autoconfigs from EmulationStation into RetroArch. I could also access the RunCommand menus with it just fine. Then I added the XboxDRV into the mix to use the original NES controllers. While they worked fine with the remapping, I lost the ability to access the RunCommand. This might be due to the re-working of my plugs on the Pi, and having to move them around. Right now, I can navigate ES, RetroArch, and play games with my Xbox Controller, but I can't access the RunCommand. If I attach an NES controller, I can access the RunCommand, but then I can't navigate inside it, nor does the controller work inside a game. The only way I can navigate RunConmmand is by using a keyboard, after triggering it from the NES controller.
Sounds confusing.
Xbox Controller - Works in ES, Doesn't Trigger RunCommand, Doesn't work in RunCommand, Works in RetroArch/Games
NES Controller - Works in ES, Triggers RunCommand, Doesn't work in RunCommand, Doesn't work in RetroArch/Games
Keyboard - Works in ES, Triggers RunCommand, Works in RunCommand, Works in RetroArch/GamesPerhaps you can take a look and help me? :)
Example from
runcommand-onstart.sh
:if [ "$1" = "nes" ] then sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv > /dev/null 2>&1 \ --evdev /dev/input/by-id/usb-©Microsoft_Xbox_360_Wireless_Receiver_for_Windows_E1594E70-event-joystick \ --detach-kernel-driver \ --silent \ --force-feedback \ --deadzone-trigger 15% \ --deadzone 4000 \ --mimic-xpad \ --dpad-as-button \ --evdev-absmap ABS_X=x1,ABS_Y=y1,ABS_RX=x2,ABS_RY=y2,ABS_Z=lt,ABS_RZ=rt \ --evdev-keymap BTN_SOUTH=a,BTN_EAST=b,BTN_NORTH=x,BTN_WEST=y,BTN_TL=lb,BTN_TR=rb,BTN_THUMBL=tl,BTN_THUMBR=tr,BTN_MODE=guide,BTN_SELECT=back,BTN_START=start,BTN_TRIGGER_HAPPY3=du,BTN_TRIGGER_HAPPY4=dd,BTN_TRIGGER_HAPPY1=dl,BTN_TRIGGER_HAPPY2=dr \ --ui-buttonmap x=KEY_X,a=KEY_C,b=KEY_V,lb=KEY_A,Y=KEY_S,rb=KEY_D \ --ui-buttonmap guide=KEY_B,start=KEY_ENTER,back=KEY_ESC \ --ui-buttonmap du=KEY_UP,dd=KEY_DOWN,dl=KEY_LEFT,dr=KEY_RIGHT \ & sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv > /dev/null 2>&1 \ --evdev /dev/input/event3 \ --detach-kernel-driver \ --device-name "NES Pad Player 1 (xboxdrv)" \ --evdev-absmap ABS_X=x1,ABS_Y=y1 \ --evdev-keymap BTN_TRIGGER=a,BTN_THUMB=b,BTN_THUMB2=back,BTN_TOP=start \ --dpad-only \ --ui-axismap x1=KEY_LEFT:KEY_RIGHT,y1=KEY_UP:KEY_DOWN \ --ui-buttonmap start=KEY_T,back=KEY_E,b=KEY_B,a=KEY_A \ & sudo /opt/retropie/supplementary/xboxdrv/bin/xboxdrv > /dev/null 2>&1 \ --evdev /dev/input/event4 \ --detach-kernel-driver \ --device-name "NES Pad Player 2 (xboxdrv)" \ --evdev-absmap ABS_X=x1,ABS_Y=y1 \ --evdev-keymap BTN_TRIGGER=a,BTN_THUMB=b,BTN_THUMB2=back,BTN_TOP=start \ --dpad-only \ --ui-axismap x1=KEY_G:KEY_H,y1=KEY_I:KEY_J \ --ui-buttonmap start=KEY_LEFTSHIFT,back=KEY_RIGHTSHIFT,b=KEY_M,a=KEY_K \ & fi
I checked the input devices, and can confirm that even though I moved their locations physically on the Pi, the
evdev /dev/input/device ##
is stll the same. -
DERP - I think the problem with the controller INSIDE a game might be because I had to restore the original default
retroarch.cfg
file because the latest update to RetroArch was broke. GRR now I have MORE work to do. :( -
Good to see that you nailed down what the problem was. Half the time that's the hardest part.
-
@mediamogul Yeah, but I'm not much closer now than I was a couple hours ago. Back to the old starting grounds.
-
My memory on this is a bit wobbly, but I believe I've always had trouble with xboxdrv mappings triggering and navigating the Runcommand window and I just used my little wireless keyboard for these occurances. Was this something that was previously working for you?
Keep in mind that the Runcommand window's control scheme is limited to up, down, left and right, as well as 'A' on a standard controller and up, down, left and right, as well as 'Enter' on a keyboard. If the xboxdrv mapping differs from these two schemes, it's unlikely to work.
-
@mediamogul I thought I had it working, but I could be mistaken. I don't really need to get into the RunCommand window, other than when I need to try an experiment with an alternative LibRetro core. Realizing I couldn't do it with my Xbox controller led me to discover that it works with an NES controller. But even then, navigating doesn't work, or at least, not correctly. I press up on the NES controller, and the selector scrolls down. None of the A/B/Start buttons work. It's a bummer for sure. I guess there's no happy solution. I'm looking at "KEYBOARD ONLY" for RunCommand navigation, and "ORIGINAL CONTROLLER" (not Xbox) for triggering it.
-
It sounds like a mapping issue that may originate from the base xboxdrv controller map, where you might have accidentally mapped the physical 'Up' button to the virtual 'Down' button on the simulated xbox controller that xboxdrv creates. If this is so, when you then mapped 'Up' inside of Emulation station, it would set the 'Down' direction as being 'Up', which would work fine in all of the RetroArch emulators, but still be read as 'Down' in any software that doesn't use the configuration that ES created, such as the Runcommand menu. Of course, it's just a guess. These types of issues can be a bit like untangling Christmas tree lights.
-
Well, I started off today with NOTHING working. Now I'm back to at least the NES controllers working correctly through XboxDRV. It's the strangest thing. I still can't do much inside of RunCommand other than press UP to go DOWN. Not sure what that's all about. But I also can't do the START+SELECT to exit a game with the NES controller. I think it has to do with the SELECT button not registering in RetroArch as the hotkey.
Is there a way to override a key mapping per emulator? I know, that's a stupid question. But it seems like if I'm using XBOXDRV, there's no way to access the Controller Remap functionality for RetroArch. Or is there? I think I need to experiment more. Maybe it works like it's supposed to, but I have the SELECT button mapped wrong.
-
@hansolo77 said in XBOXDRV Guidance Needed:
But it seems like if I'm using XBOXDRV, there's no way to access the Controller Remap functionality for RetroArch. Or is there?
It should work all the same. RetroArch should map the simulated XBox controller to it's own 'RetroPad' and allow it to be remapped from the GUI just like anything else. Even if you're keymapping, RetroArch should map those keys to it's 'RetroPad' so long as they correspond to the keyboard controls you set in Emulation Station.
-
OK new problem... :(
How can I get it to pull the USB EVENT by-id? I get it working like I want it, then turn the system off and back on, and its not working. Every time I reboot, the
/dev/input/event##
changes. Sometimes its/dev/input/event3
other times it's/dev/input/event4
. So to get around that with my Xbox controller way back with SORR, I set it to use/dev/input/by-id
. The problem is that the controller is one of 2, and theevent-joystick
only offers 1 choice. When Ievtest
that, it only gives me the keys for Controller 2. :( UHG! -
Your controller's ID can be discovered with
ls /dev/input/by-id/
. However, if it doesn't have an ID, you can also call out to the USB path where you know the controller is. For example, by adding:--evdev /dev/input/by-path/platform-3f980000.usb-usb-0:1.2:1.0-event-joystick
you're telling xboxdrv to map the controller in the upper, left USB port on a Pi 3. To discover the other path listings, plug a controller into whichever port you're looking to use and type
ls /dev/input/by-path/
. -
I am figuratively pulling my hair out. Because I wasn't getting anywhere, I decided to start completely over. I deleted all the controller config files that RetroArch uses. I then disconnected the USB hub that the Mayflash Sega/Atari adapter and Raphnet NES adapter were connected to. I then replaced the retroarch.cfg file with the default. I then went into the RetroPie-Setup scripts and triggered the ES function to reset ALL controllers (removing them and prompting for a re-configure). That should put me back to bare minimum with no configured controllers right? Well...
With everything still disconnected, except for the Xbox controller, I turned the machine off then back on. ES prompted for input. I configured ONLY the Xbox controller. I then tried to load up a game. The game loads, but none of the controls do. WTF. OMG I can't believe it. Not even the USB keyboard I have is being recognized by RetroArch.
This is crazy. I'm restoring my backup SD card and just living with it the way it was. I can't figure out what's going on, and it's really upsetting me. With NOTHING connected, bare essentials, it should work with whatever is picks up is connected. It used to work fine until I updated RetroArch. Now I got nothing but trouble.
-
I can definitely relate. It's situations like your having where you almost start believing in poltergeists or gremlins. I hope it works out. Just tag me in if you decide to give it another go down the road.
-
Oh you bet I will. :) Honestly, I think I just need to sleep this off and come back some other day. I don't want to ruin my vacation being pissed off at this thing. It's supposed to be enjoyable. lol
-
@mediamogul
Back at it again. I started with your doc you wrote on how to set this all up. You indicated a possible workaround using a SYMLINK in the dev rules so you can get proper remaps with Bluetooth controllers. This got me thinking. Since part of the problem I seem to be having is due to the devices being enumerated differently on bootups, could I use this method here? The only obstacle is that theATTRS{name}
andID_MODEL
is the same for both event's. There is only 1 USB plug, but it has 2 controller connectors on it. Is there a way to create the SYMLINK dev rule another way? Without it requiring those two indicators? Maybe an alternative?Here is what I'm looking at (
evtest
):Available devices: /dev/input/event1: Microsoft Microsoft® 2.4GHz Transceiver v8.0 /dev/input/event2: Microsoft Microsoft® 2.4GHz Transceiver v8.0 /dev/input/event3: Microsoft Microsoft® 2.4GHz Transceiver v8.0 /dev/input/event4: raphnet.net nes2usb /dev/input/event5: raphnet.net nes2usb /dev/input/event6: Mayflash Ltd Mayflash MD USB Adapter /dev/input/event7: Mayflash Ltd Mayflash MD USB Adapter
Essentially (for this part), the
event4
andevent5
devices change to 3/4 respectively on the occasion. This typically happens based on whether or not the Xbox Controller is turned on (not listed now because it's off).
EDIT - Guess I was wrong there too. I turned ON the Xbox Controller, and re-ran the
evtest
. It sets the controller up onevent0
and the NES events didn't change. I don't get it. :(
EDIT 2 - Tried again. Turned the system off, Xbox Controller off, boot up,
evtest
shows the NES controllers now onevent3
andevent4
. Then I turn on the Xbox controller, andevtest
shows it onevent7
now. So I definitely need to establish some kind of rule that would allow me to map the controller based on it's "name" (symlink) rather than by it's event id.
EDIT 3 - Did another test. This time
evtest
comes up with the Xbox controller onevent5
. So maybe it's the Xbox controller that's being unreliable, and depending on where the Pi installs it to determines the placement of all the other controller events. In either case, I still need to do something to assign the devices to specific events or something. -
@hansolo77 said in XBOXDRV Guidance Needed:
In either case, I still need to do something to assign the devices to specific events or something.
The symlinking you mentioned would probably do the job, but the whole udev process to achieve it might be overkill in your case. As long as your controller is always plugged into the same port, assigning the mappings via
/dev/input/by-path/
is always a very reliable option. I actually have to use this method, as I use four identical controllers and they all naturally share the same ID information. -
Any chance I could get you to elaborate? :) I could probably figure it out on my own, but you 'd probably know how to do it faster.
-
Sure. Just plug your controller into whichever port you plan on keeping it in, then run
ls /dev/input/by-path/
. As an example, a controller plugged into the upper, left usb port on a Pi 3 will likely read as being; platform-3f980000.usb-usb-0:1.2:1.0-event-joystick. After you have that, you'd just add it to your xboxdrv config as:--evdev /dev/input/by-path/platform-3f980000.usb-usb-0:1.2:1.0-event-joystick
-
@mediamogul Thanks, I'll take a look at it soon as I finish dinner!
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.