Retro-bit "V2" 2.4Ghz controller (Genesis Big 6 or similar) not working when Hakchi installed.

[muesonline]

Describe the bug
When Genesis mini is factory set, and default kernel is running the "V2" 2.4GHz (Big6) wireless controller works as intended. When Hakchi kernel is installed the d pad stops working and buttons are mapped to different buttons.

To Reproduce
Installing Hakchi causes the controller buttons to be remapped and dpad not to work. It doesn't matter if new games are added or not and when custom kernel is removed the controller behaves like normal. All USB controllers don't have this issue.

[RosstheRoss]

I've found this too while running into the same problem reported both here and in Hakchi. I have not been able to find a solution, but with a lot of digging I have a lot of information to help anyone else. This might be on Discord but I have not and will not use Discord and Discord isn't searchable.

Below is testing two different controllers using the 8BitDo receiver 2 in both default XInput mode and "MD" Mode. The controllers are the NSO Genesis Controller and an Xbox Series Controller I had lying around. evtest outputs are attached to not hit the character limit.

NSO Genesis Controller, XInput

input: Microsoft X-Box 360 pad as /devices/platform/sunxi-ehci.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input4
input: 6B controller as /devices/virtual/input/input30

Button on Controller	Button According to evtest	Button According to Controller Demo
A	BTN_SOUTH	B
B	BTN_EAST	C
C	BTN_TR	Z
START	BTN_START	Start
MODE	BTN_SELECT	None (Opens the menu)
HOME	BTN_MODE	None

Output of evtest, NSO XInput

NSO Genesis Controller, "MD mode"

generic-usb 0003:2DC8:3105.0007: input,hidraw1: USB HID v1.11 Gamepad [8BitDo 8BitDo Receiver] on usb-sunxi-ehci-1.2/input0
dragonrise 0003:0079:0011.0012: input,hidraw1: USB HID v1.10 Joystick [8BitDo Receiver] on usb-sunxi-ehci-1.2/input0

Button on Controller	Button According to evtest	Button According to Controller Demo
A	BTN_THUMB	B
B	BTN_THUMB2	A
C	BTN_TOP2	X
START	BTN_BASE4	None
MODE	BTN_BASE3	None
HOME	BTN_BASE3	None

Output of evtest, NSO MD

For reasons beyond anyone's understanding the NSO genesis controller maps A to A, B to B and C to R on a Switch itself with absolutely no way to change it. Mapping A and B 1:1 makes sense from purely a UI standpoint only but C on R makes no sense whatsoever.

Xbox Series Controller, XInput

input: Microsoft X-Box 360 pad as /devices/platform/sunxi-ehci.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input6
input: 6B controller as /devices/virtual/input/input32

Button on Controller	Button According to evtest	Button According to Controller Demo
A	BTN_SOUTH	B
B	BTN_EAST	C
X	BTN_NORTH	A
Y	BTN_WEST	Y
LB	BTN_TL	X
RB	BTN_TR	Z
START	BTN_START	Start
SELECT	BTN_SELECT	None (Opens the menu)
HOME	BTN_MODE	None

Output of evtest, Series Xinput

Xbox Series Controller, "MD mode"

input: 8BitDo Receiver as /devices/platform/sunxi-ehci.1/usb1/1-1/1-1.2/1-1.2:1.0/input/input23
dragonrise 0003:0079:0011.0010: input,hidraw1: USB HID v1.10 Joystick [8BitDo Receiver] on usb-sunxi-ehci-1.2/input0

Button on Controller	Button According to evtest	Button According to Controller Demo
A	BTN_THUMB2	A
B	BTN_TOP2	X
X	BTN_THUMB	C
Y	BTN_TOP	Y
LB	BTN_TRIGGER	B
RB	BTN_PINKIE	Z
START	BTN_BASE4	None
SELECT	BTN_BASE3	None
HOME	BTN_BASE3	None

Output of evtest, Series MD

---

EDITOR'S NOTE

I don't think that this is caused directly by the Linux kernel. The kernel seems to be doing what it is supposed to do. Either the 8bitdo firmware is mapping things bizarrely or the emulator itself is mapping things in a strange way.

Without a working dev environment I cannot toy around with the kernel and messing with the xbox driver until it spits out something nice but I hope this helps at least someone out.

I think it might have something to do with clovercon possibly not liking the genesis mini, though I honestly have no idea.

[molul]

Here's hoping there's a solution to this someday. I just bought a Big6 and a 8button controller without knowing this and they both are useless :(

[molul]

Just bought a v2 8-button controller (not the big 6) and same issue.

At least the controller is usable as a 2nd player one, as RetroArch detects and maps it properly, but it's a pity you can't use it on the main menu.

[RosstheRoss]

I tried messing with udev rules and despite my repeated trying I cannot get it to work. It seems like the kernel or udevadm included is so old remapping controller buttons is just impossible. I am certain that without re-compiling the kernel, the issue is unfixable. Unfortunate that this project is dead, but so it goes.

[RosstheRoss]

By some miracle I was able to compile https://github.com/wez/evremap for arm-unknown-linux-musleabi to try to map buttons to their correct values on the wireless controller, and it worked in the menu! The one problem though is that the built in emulator sees it not as player 1 but player 2 ☹️. My best guess is the emulator is hard coded to find /dev/input/event4 as player 1 and /dev/input/event5 as player 2?
Some basic messing around seems to prove my hypothesis correct, event4 is always player 1 and event5 is always player 2. Maybe there is a udev rule for that?

Update: no. Seems like the kernel is the one that hands out eventX numbers. But why does 3 get skipped?
Update 2: I have hit a new roadblock. Even doing something dangerous like hardlinking the /dev/input/eventX values to something else seemingly does nothing. At least I made progress?