(Better) support for 8BitDo Ultimate Wired Controller [PC/Switch] about xpad HOT 3 OPEN

As long as Steam or Retroarch are running, it's fine. catting its /dev/input entry works, too, but that's just too ugly for words. The problem doesn't occur with xboxdrv, either.

I found this issue here with this controller from the exact same symptoms, the constant disconnect/reconnect unless something was accessing it somehow.

(Switch mode is working in the interim)

from xpad.

Not sure if it helps.. but i wrote a script to avoid keeping steam open

https://github.com/b1337xyz/scripts/blob/main/python/8bitdo_attach.py

from xpad.

I'm also seeing the exact same issue on an Ayaneo Kun (a handheld device). The integrated controller identifies itself as a Xbox360 controller. The USB device of the controller quickly performs a reset, if one should not open the corresponding event device within a second or so. Looking at the kernel level opening the event device trigger periodic USB transfers to and from the device (to query button state, etc.). It seems like that these transfer make the watchdog in the controller firmware happy.

I have written my own set of workaround for this problem. You can find stuff here: https://github.com/tobiasjakobi/ayaneo_kun/tree/master/controller

Consists of an UDev rule that triggers a systemd unit when the device appears. The unit itself just launches a small application that opens the event device and then waits for a Unix signal (SIGTERM, issued by systemd when the unit stops).

This is clearly a workaround, and IMHO a fix in the kernel driver would be much more appropriate. However I don't know what implications it would have to talk to the USB device regardless if the evdev is open or not. At least from a powersaving perspective it's probably not a good idea.

In particular I don't really get this decision to implement this watchdog in the firmware in the first place. Why would you perform a USB reset when the watchdog hits? This just results in the device dropping from the bus, only to come back a little while later. And this way you never get any powersaving at all, since it's connect, probe, disconnect, connect, probe, ad infinitum.

The only way I would get the controller to sleep is to manually disable the bus port which it is connected to. Then you wait for some minutes (I'm not sure how many exactly), power up the bus port again and then device is quiet (it doesn't appear on the bus anymore). Pressing a button reactivates it again.

EDIT: Forgot to mention that I also saw a report about this issue on the LKML: https://lore.kernel.org/linux-input/[email protected]/T/

from xpad.