Windows 8.1 x64 - get_feature_report fails --> Many other functions fail

[cboulay]

I don't know if I semi-broke my PSMove Controller, if I broke my 2 windows systems, or if there's an inherent problem in hidapi in Windows 8.1 with the PSMove Controller, but most of the get_feature_reports fail. See my more detailed results here.

Without the feature reports returning the serial, none of the functions that depend on the serial work. For example, I can run the (paired in OSX) PSMove controller through the magnetometer_calibration but it cannot save its output.

Can we get the serial from somewhere else?

magnetometer_calibration.exe
[PSMOVE CRITICAL] Assertion fail in psmove_calibration_new: Could not determine serial from controller
[PSMOVE CRITICAL] Assertion fail in psmove_calibration_supported: calibration != NULL
[PSMOVE CRITICAL] Assertion fail in psmove_get_magnetometer_calibration_filename: serial != NULL
[PSMOVE WARNING] Magnetometer in (null) not yet calibrated.
Calibrating PS Move #0
Calibration done. Press the MOVE button to continue.
[PSMOVE CRITICAL] Assertion fail in psmove_get_magnetometer_calibration_filename: serial != NULL
[PSMOVE CRITICAL] Assertion fail in psmove_save_magnetometer_calibration: fp != NULL

[betonme]

Can You try this changes:
https://github.com/thp/psmoveapi/pull/118/files

[cboulay]

Sorry that didn't work for me. It did get rid of the error, and it did report the address, but the LED never turned on and calibration phase never initiated.

I was able to get rid of my errors and enable calibration by simply changing

#ifdef _WIN32
    /* Windows Quirk: USB devices have "0" as serial, BT devices their addr */
    if (serial != NULL && wcslen(serial) > 1) {
        move->is_bluetooth = 1;
    }
    /* Windows Quirk: Use path instead of serial number by ignoring serial */
    serial = NULL;

    /* XXX Ugly: Convert "col02" path to "col01" path (tested w/ BT and USB) */
    char *p;
    psmove_return_val_if_fail((p = strstr(path, "&col02#")) != NULL, NULL);
    p[5] = '1';
    psmove_return_val_if_fail((p = strstr(path, "&0001#")) != NULL, NULL);
    p[4] = '0';
#endif

    if (serial == NULL && path != NULL) {
        move->handle = hid_open_path(path);
    } else {
        move->handle = hid_open(PSMOVE_VID, PSMOVE_PID, serial);
    }

to

#ifdef _WIN32
    /* Windows Quirk: USB devices have "0" as serial, BT devices their addr */
    if (serial != NULL && wcslen(serial) > 1) {
        move->is_bluetooth = 1;
    } else {
        /* Windows Quirk: Use path instead of serial number by ignoring serial */
        serial = NULL;
    }

    /* XXX Ugly: Convert "col02" path to "col01" path (tested w/ BT and USB) */
    char *p;
    psmove_return_val_if_fail((p = strstr(path, "&col02#")) != NULL, NULL);
    p[5] = '1';
    psmove_return_val_if_fail((p = strstr(path, "&0001#")) != NULL, NULL);
    p[4] = '0';
#endif

    if ((serial == NULL && path != NULL) || (move->is_bluetooth == 1)) {
        move->handle = hid_open_path(path);
    } else {
        move->handle = hid_open(PSMOVE_VID, PSMOVE_PID, serial);
    }

Now the magnetometer_calibration works as expected without all those errors.

[cboulay]

The feature report with first byte == 0x04 works for device with path col02. The serial number comes back in reverse order. I wrote a little script that queried all get_feature_report for my controller, connected by both USB and bluetooth.

The result is below. I snipped out all the "Parameter is incorrect" responses. Anything with "Incorrect function" is likely to use that first byte in a send_feature_report.
First, the PSMove_Request_Type enum from the API for reference.

    PSMove_Req_GetInput = 0x01,
    PSMove_Req_SetLEDs = 0x02,
    PSMove_Req_SetLEDPWMFrequency = 0x03,
    PSMove_Req_GetBTAddr = 0x04,
    PSMove_Req_SetBTAddr = 0x05,
    PSMove_Req_GetCalibration = 0x10,
    PSMove_Req_SetAuthChallenge = 0xA0,
    PSMove_Req_GetAuthResponse = 0xA1,
    PSMove_Req_GetExtDeviceInfo = 0xE0,
    PSMove_Req_SetExtDeviceInfo = 0xE0,
    PSMove_Req_SetDFUMode = 0xF2,
    PSMove_Req_GetFirmwareInfo = 0xF9,
    PSMove_Req_SetLEDsPermanentUSB = 0xFA,

TEST device with serial = (null) at path = \\?\hid#vid_054c&pid_03d5&col01#6&32e7a05&2&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}.

03: A device attached to the system is not functioning.
04: Incorrect function.
05: Incorrect function.
Feature Report
  10 00 0d 07 11 80 37 7f 16 91 31 6f 3a 7f f0 7f 7f 80 62 7f 4b 6f 58 91 39 7f 5f 80 79 80 45 90 5f 80 37 80 51 6e 27 80 e2 08 fc 7f f4 7f 7c 81 84 00 
Feature Report
  11 00 c8 00 28 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
a0: Incorrect function.
a1: Incorrect function.
Feature Report (e0)
  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

TEST device with serial = (null) at path = \\?\hid#vid_054c&pid_03d5&col02#6&32e7a05&2&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}.
01: Incorrect function.
02: Incorrect function.
03: Incorrect function.
Feature Report
  04 f3 cd 18 f7 06 00 08 25 00 10 54 64 70 f3 5c 00 
05: A device attached to the system is not functioning.
06: Incorrect function.
10: Incorrect function.
11: Incorrect function.
a0: Incorrect function.
a1: Incorrect function.
e0: Incorrect function.

TEST device with serial = (null) at path = \\?\hid#vid_054c&pid_03d5&col03#6&32e7a05&2&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}.
00: The parameter is incorrect.
01: Incorrect function.
02: Incorrect function.
03: Incorrect function.
04: Incorrect function.
05: Incorrect function.
06: Incorrect function.
10: Incorrect function.
11: Incorrect function.
a0: A device attached to the system is not functioning.
a1: A device attached to the system is not functioning.
e0: Incorrect function.

TEST device with serial = 0006f718cdf3 at path = \\?\hid#{00001124-0000-1000-8000-00805f9b34fb}_vid&0002054c_pid&03d5&col01#8&2700fb9e&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}.
04: Incorrect function.
05: Incorrect function.
Feature Report
  10 01 07 fe 7f f1 7f 79 81 00 00 00 00 00 00 00 01 00 01 de 08 e0 01 70 95 11 80 c4 81 e0 01 02 80 5b 92 7d 81 e0 01 d3 7f 1d 80 69 95 a2 07 e4 fa 00 
Feature Report
  11 00 f0 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
a0: Incorrect function.
a1: Incorrect function.
Feature Report
  e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

TEST device with serial = 0006f718cdf3 at path = \\?\hid#{00001124-0000-1000-8000-00805f9b34fb}_vid&0002054c_pid&03d5&col02#8&2700fb9e&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}.
01: Incorrect function.
02: Incorrect function.
03: Incorrect function.
Feature Report
  04 f3 cd 18 f7 06 00 08 25 00 10 54 64 70 f3 5c 00 
06: Incorrect function.
10: Incorrect function.
11: Incorrect function.
a0: Incorrect function.
a1: Incorrect function.
e0: Incorrect function.

TEST device with serial = 0006f718cdf3 at path = \\?\hid#{00001124-0000-1000-8000-00805f9b34fb}_vid&0002054c_pid&03d5&col03#8&2700fb9e&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}.
01: Incorrect function.
02: Incorrect function.
03: Incorrect function.
04: Incorrect function.
05: Incorrect function.
06: Incorrect function.
10: Incorrect function.
11: Incorrect function.
Feature Report
  a1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
e0: Incorrect function.

[cboulay]

@nitsch What would be the best way to hack the API to get the correct serial number in Windows?

[nitsch]

@nitsch What would be the best way to hack the API to get the correct
serial number in Windows?

Hm, I am a little confused. Didn't you just say you already fixed it
(the change inside psmove_connect_internal())?

Since this seems to be a Windows 8 issue (and I cannot test on this
platform) I cannot even say for sure what the problem is -- besides
Feature Report 0x04 only working for the "col02" device. But hidapi
probably knows the Bluetooth device address already. The device is
connected after all, so the OS has that information.

psmove_connect_by_id() is probably a good place to start looking. hidapi
enumerates the devices and we probably know the BDADDR at this point
already.

[cboulay]

Sorry, I didn't post an earlier comment that I intended to make: My hack from above in my second comment only works in a few situations, and definitely doesn't help when a device is connected by USB. I'm trying to come up with a more general solution. I think a better solution might be to, in Windows, always connect temporarily to the col2 device to pull the serial (anything else?) then disconnect from that device, change the path, and proceed as usual. In fact I did that and it improved things somewhat. It also gets rid of the need to have NULL serial anywhere. But I don't know if this breaks anything.

I guess I'm still trying to understand the preferred workflow for connecting to move devices. This is rather complicated because of the cross-platform support and linux using an entirely different (non-hidapi) scheme. I'm working through some of the example programs now to gain a better understanding.

Do you know of a better way to get the bluetooth address without connecting to the device? I can't find anything in hidapi's docs.

[cboulay]

@betonme I understand what you did a little better now -> maintaining a connection to the 'other' devices because it is only through them that you can access certain information. I like it. It seems device with path col01 gives PSMove_Req_GetCalibration and ExtDeviceInfo, the col02 device gives PSMove_Req_GetBTAddr, and the col03 device gives PSMove_Req_GetAuthResponse maybe.

At least that's how it is on my setup. In your pull request you seem to open col02 as your main device and open col01 as your calib device, whereas the original API opens col01 as the main device (path with col02 is passed through the functions but never opened).

I'm going to work on a different solution based on what you did and the above.

Does this break Windows < 8.1? i.e. are all the feature reports on col01 but none on col02 or col03?

[nitsch]

I guess I'm still trying to understand the preferred workflow for
connecting to move devices. This is rather complicated because of
the cross-platform support and linux using an entirely different
(non-hidapi) scheme.

hidapi alone is not of much use for that on any of the 3 platforms.
Setting up the Bluetooth connection (i.e. somehow registering the Move
with the OS) is a big hack on every single one of them. Even
MotioninJoy's filter driver approach (which MiJ did not invent) is a
hack. Special devices require a special treatment, it seems. ;)

But I would love to see this done another way, preferably less hackish.
Maybe you figure something out.

Do you know of a better way to get the bluetooth address without
connecting to the device? I can't find anything in hidapi's docs.

Well, you could have a look at the Windows HID and Bluetooth APIs
directly. For Bluetooth, you can easily get access to a device's
BLUETOOTH_DEVICE_INFO struct. You can see that "in action" if you look
at https://github.com/nitsch/psmove-pair-win for example. It is a very
simple program and the code should be easy to follow.

[thp]

Is this still an issue on Windows 10?

[thp]

Closing as fixed (or at least not reproducible) in newer Windows versions.