I ported this to Windows, but not working

[ziriax]

Thanks for this library!

Do I need to install anything extra for the code to work?

I ported the code to Windows, and although I don't get any error messages when sending commands to the pedal, whenever I press it, it just keeps sending the "b" keystroke.

I also noticed that -r hangs forever unfortunately.

The PCsoftware download URLs is down, so I can't install their drivers.

Any tips?

[rgerganov]

Sorry, I don't have a Windows machine so I can't help much. Maybe try to find some working examples of the hidapi library for Windows and try to adapt.

[ziriax]

No problem, I'm having fun with it 👍 How did you figure out the communication protocol, reverse engineering? Or does some document exists?

[rgerganov]

I reverse engineered the Windows app

[ziriax]

That is amazing! May I be so free to ask what USb sniffer tool you used? I used to be an assembly code hacker on Commodore 64 and Amiga machines, so this kind of hacking still interests me

…

On Tue, 7 Dec 2021, 12:15 Radoslav Gerganov, ***@***.***> wrote: I reverse engineered the Windows app — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#71 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASHK3Y6BJLUMWOIA3B25RDUPXUGFANCNFSM5JPGUIEQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rgerganov]

In this particular case, I just decompiled the Windows binary (.NET app) and figured out the commands it sends.
If you are interested into USB sniffing, you may take a look at https://github.com/scanlime/vusb-analyzer. This basically parses the USB logs from VMware VM.
Of course, there are also other methods, google is your friend :)

[ziriax]

On Windows, it seems that when writing to the device, I need to always start with a zero byte, then I was to program the footswitch.

So basically, I had to change the following function

void usb_write(unsigned char data[8]) {
#ifdef _WIN32
    unsigned char buffer[9];
    buffer[0] = 0;
    memcpy(buffer + 1, data, 8);
    int r = hid_write(dev, buffer, 9);
#else
    int r = hid_write(dev, data, 8);
#endif
    usleep(30 * 1000);

    if (r < 0) {
       fatal("error writing data (%ls)", hid_error(dev));
    }
}

The documentation of hid_write says;

The first byte of @p data[] must contain the Report ID. For devices which only support a single report, this must be set to 0x0. The remaining bytes contain the report data. Since the Report ID is mandatory, calls to hid_write() will always contain one more byte than the report contains. For example, if a hid report is 16 bytes long, 17 bytes must be passed to hid_write(), the Report ID (or 0x0, for devices with a single report), followed by the report data (16 bytes). In this example, the length passed in would be 17.

Not sure what that means, but starting with a zero byte did it for me.

[rgerganov]

Great! Could you please send a pull request?

[ziriax]

The -r command is not working yet, but it doesn't hang... So it certainly isn't complete yet.

I currently just make a Visual Studio 2019 project, using vcpkg as pakcage manager, but ideally I should convert this to cmake... That will take more time.

I see what I can do, maybe starting with a VS project and an updated README is good enough.