Natec Genesis P65 (xbox360/ps3) gamepad - xbox360 mode stopped working
Closed this issue · 10 comments
What I tried
- Roll back to a pinned uBlue image I keep as a backup. That image is from Aug 18, 2023 and the controller WORKS THERE.
- I also tried rebasing to normal, official, latest Silverblue. It also WORKS THERE.
Info about the controller
- It has xbox360 and a ps3 mode switch.
- In the ps3 mode, it works, but that mode is unusable even on Windows.
- In xbox360 mode, under /dev/input/by-id, it shows up as 'usb-ShanWan_Controller_XBOX_360_For_Windows..' Using cat on that file throws SIGPIPE error. This mode worked flawlessly for like 3 years until now.
What I suspect is the issue
- Considering normal latest Silverblue works, a pinned uBlue image from Aug 18, 2023 also works, looking around here I suspect commits from Aug 27, 2023 caused it. Those mention stuff related to xbox controllers.
Rebasing using date tags
- silverblue-nvidia:20230826 - WORKS
- silverblue-nvidia:20230827 - DOES NOT WORK
Please see my response here: ublue-os/main#314 (comment)
I suspect enrolling the ublue MOK will fix your issue.
As I'm using nvidia, I already have the key enrolled. Tried to run 'just enroll-secure-boot-key' again and it indeed says SKIP, already enrolled.
The output of 'dmesg -T -w' (xbox360 mode) shows this:
[Sun Sep 3 20:48:42 2023] usb 3-1: new full-speed USB device number 14 using xhci_hcd
[Sun Sep 3 20:48:42 2023] usb 3-1: New USB device found, idVendor=045e, idProduct=028e, bcdDevice= 1.10
[Sun Sep 3 20:48:42 2023] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Sun Sep 3 20:48:42 2023] usb 3-1: Product: Controller(XBOX 360 For Windows
[Sun Sep 3 20:48:42 2023] usb 3-1: Manufacturer: ShanWan
[Sun Sep 3 20:48:42 2023] input: Microsoft X-Box 360 pad as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/input/input43
Let me know If I'm missing something.
I'm not sure what to tell you. My understanding is that the xpad-noone driver is stock, upstream linux xpad... except we've commented out support for Xbox One controllers.
The driver should support your device as it shares the device and vendor ID's: { 0x045e, 0x028e, "Microsoft X-Box 360 pad", 0, XTYPE_XBOX360 },
As can be seen here:
ublue-os/xpad-noone@c6746b3#diff-3d985fe7837dec4db1df27733cece3b37633535ef91b1cbdf1c8b6eec4f692dbL154
Perhaps try manually loading the module after plugging in the controller? sudo modprobe xpad-noone
@KyleGospo not sure if you have anything more to add?
sudo modprobe xpad-noone unfortunately doesn't fix it.
I missed this though, when I unplug the controller in xbox360 mode, it shows:
[Wed Sep 6 15:54:12 2023] xpad-noone 3-1:1.0: xpad_try_sending_next_out_packet - usb_submit_urb failed with result -19
Went through some forums, tried sudo rmmod xpad-noone && sudo modprobe xpad-noone and sudo service fwpud stop suggested as 'fixes', but that also didn't do nothing in my case.
Looks like 8bitdo had a similar issue, and it's due to how they fake their VID.
In the meantime you can blacklist the 3 new drivers and override the xpad blacklist by making an empty copy in etc with the same name, returning you to stock kernel behavior.
In the meantime you can blacklist the 3 new drivers and override the xpad blacklist by making an empty copy in etc with the same name, returning you to stock kernel behavior.
What do you think of making just command for this?
Made this for myself, if it helps somehow
# Use stock gamepad drivers
use-stock-gamepads:
sudo bash -c '> /etc/modprobe.d/xone.conf'
sudo bash -c '> /etc/modprobe.d/xpadneo.conf'
sudo bash -c '> /etc/modprobe.d/xpad-noone-blacklist.conf'
sudo bash -c '> /etc/modules-load.d/xpad-noone.conf'
# Use uBlue gamepad drivers
use-ublue-gamepads:
sudo rm -f /etc/modprobe.d/xone.conf
sudo rm -f /etc/modprobe.d/xpadneo.conf
sudo rm -f /etc/modprobe.d/xpad-noone-blacklist.conf
sudo rm -f /etc/modules-load.d/xpad-noone.conf
Fixed by #115