XBOXDRV Guidance Needed
-
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!
-
@mediamogul said in XBOXDRV Guidance Needed:
ls /dev/input/by-path/
So these "paths" will never change as long as I keep the adapters connected on the same ports?
EDIT This still won't work for me. I did an evtest of each
event-joystick
and it only gives me the player 1 port of the adapter. -
Did two listings show up with
ls /dev/input/by-path/
? -
@mediamogul When I do
ls /dev/input/by-path
, I get this:platform-3f980000.usb-usb-0:1.2:1.0-event-joystick platform-3f980000.usb-usb-0:1.4.1.2:1.0-event-joystick platform-3f980000.usb-usb-0:1.4.3:1.0-event-kbd platform-3f980000.usb-usb-0:1.2:1.0-joystick platform-3f980000.usb-usb-0:1.4.1.2:1.0-joystick platform-3f980000.usb-usb-0:1.4.3:1.1-event-mouse platform-3f980000.usb-usb-0:1.4.1.1:1.0-event-joystick platform-3f980000.usb-usb-0:1.4.1.2:1.1-event-joystick platform-3f980000.usb-usb-0:1.4.3:1.1-mouse platform-3f980000.usb-usb-0:1.4.1.1:1.0-joystick platform-3f980000.usb-usb-0:1.4.1.2:1.1-joystick platform-3f980000.usb-usb-0:1.4.3:1.2-event-kbd
I tested each
event-joystick
, and I came up with this:Xbox platform-3f980000.usb-usb-0:1.2:1.0-event-joystick Raphnet platform-3f980000.usb-usb-0:1.4.1.1:1.0-event-joystick MayFlash platform-3f980000.usb-usb-0:1.4.1.2:1.0-event-joystick MayFlash platform-3f980000.usb-usb-0:1.4.1.2:1.1-event-joystick
So while it would work with the MayFlash (Atari/Sega) it only saw one entry for the the Raphnet (NES). When I do an generic
evtest
I get this:No device specified, trying to scan all of /dev/input/event* Not running as root, no devices may be available. Available devices: /dev/input/event0: Xbox 360 Wireless Receiver /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
So it looks like it sees multiple events but for a single device (which makes sense). But it doesn't do it that way with the MayFlash.
EDIT - If I run
evtest /dev/input/by-path/
, I get this:evtest: can't get version: Inappropriate ioctl for device
EDIT 2 - If I run
ls /dev/input/by-id
, I get this:usb-Mayflash_Ltd_Mayflash_MD_USB_Adapter-event-joystick usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v8.0-if01-mouse usb-Mayflash_Ltd_Mayflash_MD_USB_Adapter-if01-event-joystick usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v8.0-if02-event-kbd usb-Mayflash_Ltd_Mayflash_MD_USB_Adapter-if01-joystick usb-©Microsoft_Xbox_360_Wireless_Receiver_for_Windows_E1594E70-event-joystick usb-Mayflash_Ltd_Mayflash_MD_USB_Adapter-joystick usb-©Microsoft_Xbox_360_Wireless_Receiver_for_Windows_E1594E70-joystick usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v8.0-event-kbd usb-raphnet.net_nes2usb_1228-event-joystick usb-Microsoft_Microsoft®_2.4GHz_Transceiver_v8.0-if01-event-mouse usb-raphnet.net_nes2usb_1228-joystick
Looks like it's only seeing 1 raphnet there too. :(
-
@hansolo77 @mediamogul
I think I need to do this:
http://www.raphnet-tech.com/support/retropie/ -
The adapters that have multiple ports are notoriously difficult to map outside of Windows and they're all pretty much set up the same way. An example that I've worked with personally is the Mayflash Gamecube to WiiU adapter. In it's USB mode, all the ports register as being one device also. The only way I could get it working with my RetroPie setup was to use Toadking's driver in WiiU mode. It's been a while, but as I recall, there's a certain aspect of the USB HID spec that is responsible for delineating the multiple ports and it's unique to Windows for some reason.
Edit:
I think I need to do this:
http://www.raphnet-tech.com/support/retropie/Looks like your right as per:
"The way multi-player adapters and boards are implemented make them appear as one single controllers in Linux. For instance, the adapters based on the 4nes4snes board (eg: Four SNES to USB) used to register as a joystick with 4 pairs of axes, and 32 buttons (8 per controller). But at some point, this became 2 axis (a mix of all controllers) but still 32 buttons.
To fix this problem, I wrote a kernel patch to make the adapters appear as a set of independant controllers in march 2015 and it was included in the Linux kernel starting at version 4.2.0. With this patch, things are cleaner than ever. But as 2016-05-02, the kernel included in the RetroPie SD images is still one of the 4.1 series... So besides waiting, what can one do? Of course geting the kernel sources, applying the patch, compiling and installing it! But there is an easier way."
This will likely do the job and it's great to see that this addition is waiting around the corner in a future kernal update. Seeing as how several adapters use this same method, hopefully this will solve the issue all around.
-
Yeah I tried to run his script to update the
cmdline.txt
but it didn't work after rebooting. I think it's because I've updated the kernel in the past without including his patches. So I'm going through that now. Gonna take a good couple of hours. I sent his support email a message though to see if he suspects the problem I'm having is related, and see if he has any tips or suggestions. -
Let me know what he says. This is an interesting development and I might make use of it myself sometime in the future.
-
Sure thing. It's interesting the things we discover along the way trying to solve a problem. This all started because I wanted to get the latest version of RetroArch to have Leaderboard support. That led to the config files getting broke and needing to get replaced with the generic default. That led to all the custom changes I did for my controllers to work on the fly to disappear and stop working. Now I'm back to rebuilding the kernel so I can have a more permanent XBOXDRV solution. I still can't figure out why nobody else is having all these problems lol.
-
Ha! Let's face it, solving these issues is the real game, saving the princess is just a bonus round.
-
@mediamogul You sure got that right! But this is fun too. This is what keeps me spending money where I shouldn't. :)
-
Well after fully rebuilding the kernel with the correct patches, I'm still having the same symptoms. My Raphnet NES2USB adaptor is being identified with 2 event ID's, but only one device ID.
This ONE hindrance is causing me ALL my issues. :( If I can distinguish a specific device for Controller 1 and Controller 2, I'm SOL. Does anybody have any idea on a different approach here?
-
Does anybody have any idea on a different approach here?
Seeing as how the focus has shifted to something so different, it might help to start a new thread focusing on these types of multi-port adapters.
-
@mediamogul I agree. I'll continue to update in a new thread.
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.