First a little history (skip this if you know about the Linux driver)... Warning: Spoilers inside! So back in 2014, when the adapter first came out, ToadKing managed to sniff the communication between SSB4 and the adapter using a dev board (likely BeagleBone?). From this he (or she) deduced that by sending the byte 0x13 to USB endpoint 0x81, the adapter began spewing back packets containing the data from the controller. AFAICT, ToadKing assumed (claimed?) that the 0x13 was a 'secret knock' so to speak. By the same sniffing method, 0x11 was discovered to be the rumble command. From this, he (she) made Linux drivers that got ported to Windows and OS X. But... We're not done yet. Poking around at the adapter, it appears that 0x13 is not a 'secret' but rather one of several commands, 0x11 for rumble being another. By basically fuzzing the adapter, I've started to work out some of the other commands. The goal of this thread is to document what we know, and allow others to contribute new findings. So, without further ado, what I found: VID = 0x057E PID = 0x0337 The adapter exposes two USB endpoints, one in, one out, which we already knew. Commands are written to the in endpoint (0x81) and responses, if any are read from 0x02. Commands: 0x11 - RumbleSend: 5 bytes [0x11, R1, R2, R3, R4]Receive: noneTo turn on rumble, set the corresponding R to 0x01, or to 0x00 to turn off0x12 - Rest positionsSend: 1 byte [0x12]Receive: 25 bytes, 1 cmd (0x22) followed by 4 sets of [JoyX, JoyY, CstickX, CstickY, Ltrigger, Rtrigger]Gets resting or base positions for the analog parts of the controller (joysticks, analog triggers)If polling has not been started will return all zeros except for byte 0, status?0x13 - Begin PollingSend: 1 byte [0x13]Receive: 37 bytes, 1 cmd byte (0x21) plus 4 sets of 9 bytes:[status, BtnStateH, BtnStateL, JoyX, JoyY, CX, CY, LTrigger, RTrigger]The 'knock', will make the adapter begin sending updates to endpoint 0x02 every time it is read.Required before rumble and rest positions will work?0x14 - Suspend PollingSend: 1 byte [0x14]Receive: 2 bytes [0x24, WasPolling] 1 cmd byte (0x24) plus 0x01 if we were just polling, 0x00 if notStops the updates that 0x13 sends, useful if you just need a break, or are no longer interested in data0x15 - Kill?Send: 1 byte [0x15]Receive: ERRORAfter sending 0x15 and trying to use the device, libUSB gives an IO error, leading me to believe that 0x15turns off the adapter and requires it to be unplugged and reconnected to begin working again0x16 - ???Send: ??? [0x16, ...]Receive: ???Definitely a valid command, but no idea what it does0x17 - ???Send: ??? [0x17, ...]Receive: ???Definitely a valid command, but no idea what it does0x16 and 0x17 stall the polling data, just like an incomplete 0x11 packet, while 0x10, 0x18, 0x19, etc appear ignored. This makes me think 0x16 and 0x17 are other commands that require multi-byte packets. Fingers crossed for JOYBUS...Some more about the status bytes and button masks is known and implemented in the drivers and in Dolphin. I will update this after I read through those and figure out the status bytes for 0x12 and 0x14. Many of the things I initially labeled 'status' appear to actually be the command bytes for the packets the adapter sends back.Right now I just wanted to get the new info out there and seek any more info people have. I ran through all bytes from 0x00 to 0xFF and these were the only ones that I saw responses to, but there could still be others that don't return or require multi-byte packets. Originally I had hoped that there might be a general purpose JOYBUS mode lurking in there, but the chance of that seems slim (unless it's 0x16 and 0x17). The adapter gives no indication that a GBA link cable was inserted while polling via 0x13 either. In other words, controllers yes, GBA link no. Chime in with any more info you may have and I'll add it above.