Adding GameCube controller ports to my PC case (part 2)
Updated
Previously: Adding GameCube controller ports to my PC case (part 1)
Recap: Successfully integrated the ports with the case, but discovered way too late that this adapter boots in the wrong mode if plugged in from cold start. It does work correctly if then after boot it is physically unplugged from the PC and then plugged back in. Lacking an alternative adapter to test against and not eager to redo the whole thing, I will obviously just attempt to simulate literally that behavior, because it works.
My new Yepkit YKush3 hub arrived and was able to test it to great and immediate success. It has 3 USB ports, a dead-simple command surface to toggle them, and it works on Windows.
I had already configured a basic pipeline to deploy custom code to the box so I pulled in a package with some bindings for the ykushcmd app, which is used to control the power states of the individual downstream ports. I ran into some opaque errors getting the lib to work with its included ykushcmd binary, so I forked it and made the executable path configurable so I could point it at a newer release.
Commands to turn the ports on and off work predictably and reliably. Ports are turned on by default at boot; this is supposed to be configurable, but I haven't had luck getting the config to actually persist after reboot.
I plugged the GameCube adapter into ports 1 and 2 on the hub (it uses two ports, one to support rumble and one for all other controller data).
I wrote some code against the ykush lib to look for the adapter and power cycle the first two ports. This works as expected to take the device offline, making "POKKEN CONTROLLER" disappear from the USB controller list and replacing it with four "MAYFLASH GC CONTROLLER" ports.
Right now this code sleeps for 5 seconds twice; after turning the ports off and then again after turning them back on. The first time gives the port and device ample time to completely lose power and disconnect; the second gives Windows ample time to react to the status change and connect the new controllers before the script moves on to additional startup code that depends on those USB devices being connected already. I can probably make this more correct by replacing the sleeps with some listeners on USB disconnect/connect, but this version works reliably and I'm okay eating the extra seconds since it'll only happen on boot.
This was testing just fine until I tried to run it on boot, where it did nothing. Turns out: USB device control requires administrator privileges on Windows, which requires user interaction with a UAC prompt to approve.
I was previously launching the app on login using a shortcut in the startup folder; this method silently suppressed the UAC ask and failed. I learned that I had to create something called an "Elevated Shortcut", which bypasses this requirement by registering the shortcut as a scheduled task to run at login. Scheduling the task requires admin privileges, so it doesn't need to ask again at boot.
And it's working! At boot the adapter is incorrectly set up as the POKKEN controller, and a few seconds after login it automatically swaps over to 4 GameCube controller ports that are ready to use.
At present the Ykush board is hanging out plugged into the back of the PC with the cables from the Mayflash looped out there to connect; this made debugging easier since I didn't have to open the case, and could see the port status lights on the board to verify my ykushcmd calls were working. Now that I know it works I'll move it into the case and run my tests again; one challenge to this may be that the Ykush board has no enclosure and may be vulnerable to discharge inside the case if I don't shield it or suspend it somehow. Tentatively I could put the board directly inside the drawer enclosure the adapter hardware lives in, but
- I didn't plan for that and there's no space for the board with the current layout and
- I'd like to keep the unused downstream port available in case any other adapter has similar issues, or if another interesting use case for a powered USB port presents itself.
I am planning to integrate the Mayflash Wii "DolphinBar" Sensor with this whole setup; it's a great adapter overall but I've read of many users choosing to keep the device unplugged when not in use to avoid common conflicts that occur when trying to use other game pads. Programmatically toggling its power with the spare YKush port might be a more convenient answer; I could potentially take it a step further and trigger this automatically when Wii games are run and quit via Launchbox.