USB subsystem lunacy/need to restart subsystem on every boot?(on PC)

Libretro Lakka
#1

Hello, and thanks for taking the time to read this and hopefully helping me find a solution.

I’m relatively new to Linux(well, it’s been a long time since I’ve needed it for anything) and I’m having this bizarre issue with the USB subsystem used in Lakka(or rather OpenELEC, i think?) where my gamepads USB dongle has to be physically disconnected and reconnected EVERY single time i boot the machine up which is extremely inconvenient for something intend to have mounted high up on a shelf in my entertainment center.

The machine is an acer aspire x1300, the gamepad is an AfterGlow DS3 wireless USB controller configured as a generic HID gamepad. I’ve never encountered any problems with it before, and it certainly worked in Windows 7 even after reboot or wakeup. I’ve tried tuning the hibernation and ACPI powerstates in the BIOS and tried using some subsystem restart tricks I’ve found online(wayyy too many to list) to no avail. After reconnecting the dongle physically it works perfectly, but should the machine need to be rebooted it APPEARS as though the subsystem is simple put into sleep or hibernation and is never reactivated(i noticed this also happened with the flash drive I had connected to it, which worked fine after plugging it back in)

Is there possibly a way for me to configure a subsystem reset EVERY time Lakka is booted???

#2

I’m also having this exact issue with my AfterGlow PS3 wireless USB controllers. This controller is wireless to a USB dongle that is connected, it does not use the computer’s bluetooth at all. It takes physically reconnecting the dongle to make them work after a reboot.

I’ve searched for solutions on other Linux platforms and the most prevalent suggestion is to rebind the driver which would run the detection again:

echo -n “0000:00:xx.y” > unbind;

echo -n “0000:00:xx.y” > bind;

This, however does not work because after the reboot the system does not even register that anything is plugged in and so it can’t be targeted for the unbind/bind. It’s just not in the list until after the re-plug.

I’ve tried doing the above rebind on the USB subsystem itself, which, as expected, unbound and rebound all USB devices on the bus, but this still did not make the controller show up.

I have also tried udevadm trigger which did nothing that I could tell.

The issue might be that the controllers aren’t ready when the device gives them power and asks them for identification information, but I don’t know how to test this. What is needed is for there either to be a way of re-powering the USB ports somehow after the reboot, or perhaps for the USB subsystem to wait just a bit longer before it queries. I don’t know how to do either, and the latter might be a race condition nightmare.

These are the only controllers I have so I haven’t tested the behavior of other models/manufactures. My guess is that this is a malfunction (or feature) of the controller, not the system. But, I don’t fancy spending another $80+ on 2 more controllers.

Any suggestions would be helpful. Until then, I’m going to put them on a switched USB hub and see if that helps.

1 Like