Talk:How to use the Official GameCube Controller Adapter for Wii U in Dolphin

Weird formatting in the main site
Uh, viewing the guide from the main site doesn't display the Infobox properly. Shouldn't we ping delroth or Parlane? It may not be fixable by us... - Jhonn (talk)

I didn't look in detail, but looks like it may just be a stylesheet issue of some sort. Adding this mainly corrects for it, though it seems there's some additional missing style beyond that...

.infobox { background: none repeat scroll 0 0 #f9f9f9; border: 1px solid #aaa; clear: right; color: black; float: right; margin-bottom: 0.5em; margin-left: 1em; padding: 0.2em; } Kolano (talk) 18:57, 2 January 2015 (CET)

I pinged delroth immediately upon making it, but haven't gotten a response. I left it up so he could see it, I just... didn't expect it to take this long. I'll update when I get a reply. - MaJoR (talk) 03:28, 3 January 2015 (CET)

He doesn't want to fool with it, so I'm going to just remove the infobox. - MaJoR (talk) 03:30, 3 January 2015 (CET)

OS X native support
A change that referred to a codeless kext that allows the native Gamecube adapter support to work was removed by MaJoR with the comment "That is not native gamecube controller support, that's a system driver." Thought I should make the comment that codeless kexts are not absolutely not system drivers. They are specially crafted kernel extensions that prevent other drivers from loading. In this case we need to prevent IOUSBHIDDriver from loading as the HID report descriptor of the WUP-028 makes the device unusable (believe me, I have tried to get it working as a Joystick). With the a codeless kext installed libusb is able to access the WUP-028 in the same way as is done under Linux. So, it is native support!

Now, there are problems with the codeless kext route. As of 10.10 all kernel extensions (codeless or not) need to be signed by a paying developer. The alternative is to turn on kext debugging mode but that is undesirable for end users. I would be willing to sign the kernel extension if there is any interest.


 * Since you brought this up again, I decided to go ahead and show this to skidau. Turns out I was right, but so are you! https://github.com/mitchdzugan/osx-wiiu-gcc-adapter contains the codeless kext you were referring to, and it is true and proper native support, as with any other operating system, where dolphin has full control. skidau looked at the code and confirmed it. However, the reddit link has a google drive file that turns this into a system level driver, akin to the vjoy drivers. Yea, weird. I saw the original poster saying it works for everything and realized it was a system level driver and deleted it. Basically, system level driver instructions should not be in this article. Everything on https://github.com/mitchdzugan/osx-wiiu-gcc-adapter however is perfectly fine. So, are you mitchdzugan? If so, is it ok for the instructions on the github page to be listed here with a link to the github page for the download? Or would you just prefer a mention that it is available and a link to the github page? - MaJoR (talk) 12:39, 2 April 2015 (CEST)

No, I am not mitchdzugan. I was looking at his work earlier this week and I couldn't tell how his software works as he only provides binaries. When I first tried to tackle getting the WUP-028 I wrote a driver that intercepts the HID descriptor and report requests and exposes the WUP-028 as 4 virtual gamepads. The benefit of my kernel extension over the codeless one is it should allow other applications (openemu for example) to use the WUP-028 as an input device. I will release the kernel extension code once I have it fully working the OS X force feedback interface. As for mentioning the codeless kext method, I think that would be a good idea. It is a well-known practice for supporting pseudo-hid devices. Before a mention to this method is added let me see if I can code-sign a codeless kext for the WUP-028. Hjelmn (talk) 7:17, 2 April 2015 (MDT)