Are 3rd-Party Wii U Pro Controllers "different"?

[zeus86]

Hi,

just a simple question about an older 3rd-party Wii U Pro-Controller I had laying around, regarding the topic if they behave significantly different from OEM-Controllers.

The one I have is an "pdp AFTERGLOW Pro Controller for Wii U". Transparent shell, with blue LEDs inside and mini-usb (not only) for charging. It is basically this one, but there seem to be 2 versions: one with AA-batteries and one with an integrated LiPo (I've got the LiPo-Version), but I'd assume they are otherwise identical.

However, i just wondered if 3rd-party-controllers (for the Wii U) function significantly different, because it just won't connect to BR (tested with a v1-GC-singleport-Adapter, fw. 25.1). The LEDs just blink for a while, and the controller went off afterwards when not establishing a connection. I have used this controller on a Wii U, so function-wise there should be not much of a difference.

---

Some observations of this controller when directly connected to a Linux-Box via USB:

when connecting controller in non-connected off-state:

lsusb:

short:

Bus 009 Device 081: ID 0471:0666 Philips (or NXP) Hantek DDS-3005 Arbitrary Waveform Generator

long:

> sudo lsusb -d 0471:0666 -v
Bus 009 Device 092: ID 0471:0666 Philips (or NXP) Hantek DDS-3005 Arbitrary Waveform Generator
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0471 Philips (or NXP)
  idProduct          0x0666 Hantek DDS-3005 Arbitrary Waveform Generator
  bcdDevice            0.01
  iManufacturer           0 
  iProduct                0 
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0029
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 [unknown]
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      29
          Report Descriptors: 
            ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

dmesg:

on usb-connect while controller is in off-state:

[877838.736731] usb 9-1.2.3.4: new full-speed USB device number 83 using xhci_hcd
[877838.825587] usb 9-1.2.3.4: device descriptor read/64, error -32
[877839.037062] usb 9-1.2.3.4: New USB device found, idVendor=0471, idProduct=0666, bcdDevice= 0.01
[877839.037077] usb 9-1.2.3.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[877839.128079] hid-generic 0003:0471:0666.0056: hiddev98,hidraw11: USB HID v1.10 Device [HID 0471:0666] on usb-0000:05:00.4-1.2.3.4/input0

when pressing any button (except the power button) on the controller (connection-leds light up):

[877914.035665] usb 9-1.2.3.4: USB disconnect, device number 86
[877919.898524] usb 9-1.2.3.4: new full-speed USB device number 87 using xhci_hcd
[877920.017699] usb 9-1.2.3.4: New USB device found, idVendor=0471, idProduct=0666, bcdDevice= 0.01
[877920.017712] usb 9-1.2.3.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[877920.120003] hid-generic 0003:0471:0666.005A: hiddev98,hidraw11: USB HID v1.10 Device [HID 0471:0666] on usb-0000:05:00.4-1.2.3.4/input0

when pressing the power-button on the controller (connection-leds light up):

[877863.941232] ddcutil[2517550]: segfault at 0 ip 00007f3500fa081d sp 00007ffc3b5acc48 error 4 in libc.so.6[14a81d,7f3500e57000+16f000] likely on CPU 11 (core 5, socket 0)
[877863.941248] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 89 f8 48 89 fa c5 f9 ef c0 25 ff 0f 00 00 3d e0 0f 00 00 0f 87 33 01 00 00 <c5> fd 74 0f c5 fd d7 c1 85 c0 74 57 f3 0f bc c0 c5 f8 77 c3 66 66

(yes i know the last one is abit strange. I suspect something gets confused, when the controller changes from bus-powered to self-powered...)

...any ideas anyone?

[darthcloud]

I can look into it if you get me a BlueRetro debug trace:
https://github.com/darthcloud/BlueRetro/wiki/Debug-trace

[zeus86]

sure, here you have it. I assumed this would be only helpful on an successful connect, but whatever.
br_debug_trace.bin.zip

[zeus86]

for reference: order of actions was

• enabling debug mode
• powercylce
• realizing i have other bt-deviced active and within range. turned them off.
• powercycle again
• press sync button on controller
• wait for controller to give up and turn off
• download debug trace
• turn off debug trace

[darthcloud]

I see no trace of it in the trace, maybe it's not reporting itself as a HID device and as such is filtered out of the inquiry scan results.

Can you get a trace from a PC while trying to connect it?
https://github.com/darthcloud/BlueRetro/wiki/Bluetooth-HCI-trace-with-Win10

Or in linux:
sudo btmon -w wiiu_3rd_party.log

[zeus86]

tried a btmon-walk but nothing spectacular so far, all beacons i see came from other, known devices. However, wii and wii-u's controller connection-protocol isn't plain bluetooth at all, is it? i don't know if you'd see those requests in btmon anyways...

[darthcloud]

it's plain BT, it's just that the PIN code is the bdaddr, the HID descriptor is useless & it got some vendor specific HID cmds

You should see it in the inquiry result (from a genuine wiiu pro on ubuntu)

[darthcloud]

I suspect it got a werid "Class of Device" which may make the result to be filtered out. I guess I could make a debug build with no filter.

But try to get a btmon trace, it really cost nothing.

[zeus86]

i captured one or two traces, but nothing helpful. tried to poke abit into it with wireshark, but the first hurdle is that i don't know the exact mad-addr. of the controller. i'll try to connect it to a wii u to see if i somehow can see it there.

[zeus86]

...unfortunately this will have to wait a little longer, because my Wii-U has died from a faulty NAND within 2 month not using it :-/

...have to fix this first...