Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Natec Genesis P65 (xbox360/ps3) gamepad - xbox360 mode stopped working #59

Closed
lorduskordus opened this issue Sep 1, 2023 · 10 comments
Closed

Comments

@lorduskordus
Copy link

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.
@lorduskordus
Copy link
Author

Rebasing using date tags

  • silverblue-nvidia:20230826 - WORKS
  • silverblue-nvidia:20230827 - DOES NOT WORK

@bsherman
Copy link
Contributor

bsherman commented Sep 3, 2023

Please see my response here: ublue-os/main#314 (comment)

I suspect enrolling the ublue MOK will fix your issue.

@lorduskordus
Copy link
Author

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.

@bsherman
Copy link
Contributor

bsherman commented Sep 6, 2023

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?

@lorduskordus
Copy link
Author

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.

@KyleGospo
Copy link
Member

fwupd/fwupd#828

Looks like 8bitdo had a similar issue, and it's due to how they fake their VID.

@KyleGospo
Copy link
Member

KyleGospo commented Sep 8, 2023

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.

@fiftydinar
Copy link
Contributor

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?

@lorduskordus
Copy link
Author

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

@lorduskordus
Copy link
Author

Fixed by #115

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants