I recently bought a Rii Keyboard, Mouse, & Xbox Controller combo for my RPi4 running 64 bit and RetroPie (unsupported on 64bit Rpi4), so I could have a convenient-enough input method for games and media server navigation while the Rpi4 was acting as a glorified Chromecast.
 |
| Much wow, very Rii. :P |
I encountered some weird driver issues, and I spent a bunch of time troubleshooting. Highlight the following for spoilers: My child decided to press the center "brand" button for 5 seconds, which was enough time to cycle to the next of the mapped drivers from one of the three supported "XboxDRV via HID driver" configurations described as "Android Game Controller", "Xbox360 via xpad driver" described as "Xbox 360 Controller", and "Direct Input via HID driver", which I could not get to work with my system. The colors of the controller light correspond with the enabled drivers, so I have simply started ensuring that it is "red" for Xbox360, and all the RetroPie, RetroArch, and EmulationStation mappings are happy. Using this as the solution has saved further headaches.
To describe the rabbit hole I went down, here is the following:
Troubleshooting and Permanently Mapping Gamepad Drivers on Linux
In the realm of Linux gaming, configuring gamepads can sometimes lead you into the depths of driver management. I spent time troubleshooting a gamepad driver issue and setting up xboxdrv as the permanent driver over the default usbhid then deleted my code because I realized a better solution 2 days later.
Understanding the Issue
My rii controller unexpectedly stopped working as "xbox 360" and started calling itself "android game controller" in emulation station. I fussed with it and got it all mapped then it stopped being recognized at all. My first thought was that my Rpi4 did not get updated, so for some reason the driver changed due to me adding a game rom to my retropie roms, so i went down the rabbit hole of looking for how the drivers were mapped and how to fix the broken mapping.
Investigation and Troubleshooting
Using the following commands:
cd /dev/input/
ls sleep 5 && ls
This helped me figure out that "/dev/input/js1" was unique to the controller input. I then examined the active drivers for the device:
lsusb -t # To show driver setup while the "keyboard" Rii was enabled sleep 5 && lsusb -t # To switch to the controller input and check its drivers
The relevant outputs of the final command was:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 017: ID 0079:181c DragonRise Inc. Android Game Controller
Based on that 0079:181c I could directly call out and verify that I am pointing to the right device ID.
sleep 5 && udevadm info -a -n /dev/input/js1
The command above prints device attributes used for creating udev rules. The relevant parts of the output were:
KERNEL=="js1" SUBSYSTEM=="input" DRIVER==""
KERNELS=="input75" SUBSYSTEMS=="input" DRIVERS==""
KERNELS=="0003:0079:181C.002D" SUBSYSTEMS=="hid" DRIVERS=="hid-generic"
KERNELS=="1-1.3:1.0" #note that my system included both 1.0 and 1.1 for other devices that were unique to the RII controller, so i had to include both in any "driver names" SUBSYSTEMS=="usb" DRIVERS=="usbhid" #this is the relevant "driver name" for any blacklisting commands as it contains the 1.0 kernel that actually was mapped.
KERNELS=="1-1.3" SUBSYSTEMS=="usb" DRIVERS=="usb"
KERNELS=="1-1" SUBSYSTEMS=="usb" DRIVERS=="usb"
Based on that output, no driver was set up for the first few layers, then it was mapping to the generic HID driver. It turned out to be a "Direct Input" driver in the Rii, and/or other troubleshooting steps had me uninstall the xpad driver. Another command that might be helpful is lsmod, which shows what drivers are loaded into the kernel.
Resolution Path
To correctly map the driver, I explored several methods:
Unbinding the Device: We attempted to unbind the gamepad from the
usbhiddriver. Theusbhidmodule is the USB human interface device driver in Linux, which sometimes needs to be detached to use a more specialized driver.- Note that when I tried this, I also unbound the RII keyboard driver, soo, I had to reboot. I do not recommend. Here is the code I used:
echo '1-1.3:1.0' | sudo tee /sys/bus/usb/drivers/usbhid/unbind && sudo xpad --evdev /dev/input/js1 && echo '1-1.3:1.1' | sudo tee /sys/bus/usb/drivers/usbhid/unbind && sudo xpad --evdev /dev/input/js1
Alternative Drivers: I tried to use a udev rule to make it load the correct driver "xpad" or so i thought during boot, but it ultimately didnt do anything. Here is the code I used:
sudo nano /etc/udev/rules.d/99-rii-gamepad.rules
The content of the file was the following:
SUBSYSTEM=="input", ATTRS{idVendor}=="0079", ATTRS{idProduct}=="181c", RUN+="/usr/bin/xboxdrv --device-by-id 0079:181c --type xbox360 --detach-kernel-driver &"
I then reloaded the udev rules with the following:
sudo udevadm control --reload-rules
sudo udevadm trigger
I tried to install xboxdrv outside of retropie but it didn't affect anything. I considered blacklisting the HID driver, but after my experience with unbinding, I didn't think it was a good idea without backing up my microSD card just prior to making it.
Automating the Solution
A huge downfall to this entire process was the fact that occationally and seemingly at random, the driver would change, and I couldn't nail it down even with all the troubleshooting and rules so far. Also a udev rule that is based on a device-by-id could change later, so I was less than enthusiastic that I had automated the solution to be always right.
Mapping within RetroArch
Conclusion
I found how to have a consistent experience with the RII controller: always have the controller LED be "red" aka xbox 360 xpad as the driver per the RII Manual. I hope that you save some time troubleshooting drivers or enjoying using this device.
No comments:
Post a Comment