RFC: to include hidapitester as it is a very useful tool for debugging

[mcuee]

hidtest is using a test device based on modified Microchip Simple HID demo. It can be kept as an example but not that useful as a test tool for the project.

hidapitester is an excellent tool for testing of HID devices and HIDAPI. It will be good to include it in HIDAPI.
https://github.com/todbot/hidapitester

[mcuee]

Only issue to include hidapitester is probably the GPL 3 license, which may or may not be a problem. I do not see it as a problem. But if some people see it as a problem, we can ask @todbot to see if he is willing to change the license.

[mcuee]

@todbot How do you like the idea of including hidapitester in HIDAPI project?

[todbot]

Sounds great to me

[todbot]

I can change the license to whatever is most useful

[mcuee]

HIDAPI license:
https://github.com/libusb/hidapi/blob/master/LICENSE.txt

hidapitester is already licensed under GPL3, just need to add the other two licenses.

[mcuee]

Just FYI on the original hidtest, it is based on Microchip Demo FW (part of Microchip USB Stack) but I do not know if Alan Ott published the modified FW or not.

With the original FW (04d8:003f), here is the output.

Device Found
  type: 04d8 003f
  path: \\?\hid#vid_04d8&pid_003f#e&24ba9f4d&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
  serial_number: (null)
  Manufacturer: Microchip Technology Inc.
  Product:      Simple HID Device Demo
  Release:      2
  Interface:    -1
  Usage (page): 0x1 (0xff00)

Manufacturer String: Microchip Technology Inc.
Product String: Simple HID Device Demo
Unable to read serial number string
Serial Number String: (0)
Indexed String 1: Microchip Technology Inc.
Unable to send a feature report.
Unable to get a feature report.
Incorrect function.waiting...
Data read:
   81 01 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 00 00 00 00 00 00 00 00 00 00 00 00
Press any key to continue . . .

[mcuee]

With the enhancement for hidtest, it is of course worth to keep it now. But still I think hidapitester is a worthy add-on for the hidapi project as it is useful for different type of HID devices.

[mcuee]

Example run log of hidapitester with a modified Lakeview Research Generic HID example.
FW: https://github.com/mcuee/picusb/tree/master/lvr_genhid_mod

Device: input report ID 1, output report ID 2, feature in report id 3 and feature output report id 4.

From the run log, it seems that my FW sent an extra byte for the Feature IN report. But I need to check again under different OS.

$ ./hidapitester --vidpid 0925 --list-detail
0925/7001: Lakeview Research - Generic HID
  vendorId:      0x0925
  productId:     0x7001
  usagePage:     0xFF00
  usage:         0x0001
  serial_number: (null)
  interface:     -1
  path: \\?\hid#vid_0925&pid_7001#6&461d29f&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

$ ./hidapitester --vidpid 0925:7001  -l 3 --open --send-output 2,2,3 --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 02 03
Reading 3-byte input report 0, 250 msec timeout...read 3 bytes:
 01 02 03
Closing device

$ ./hidapitester --vidpid 0925:7001  -l 4 --open --send-output 2,2,3,4 --read-input 1
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 4-bytes...wrote 3 bytes:
 02 02 03 04
Reading 4-byte input report 0, 250 msec timeout...read 3 bytes:
 01 02 03 00
Closing device

$ ./hidapitester --vidpid 0925:7001  -l 3 --open --send-feature 3,4,5 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 3-byte feature report...wrote 3 bytes:
 03 04 05
Reading 3-byte feature report, report_id 4...read 4 bytes:
 04 04 05
Closing device

$ ./hidapitester --vidpid 0925:7001  -l 4 --open --send-feature 3,4,5,6 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 4-byte feature report...wrote 4 bytes:
 03 04 05 06
Reading 4-byte feature report, report_id 4...read 4 bytes:
 04 04 05 00
Closing device

With the libusb test code, here is the output. Take note I purposefully send one more byte.

$ ./libusb1_lvrhid8.exe
Successfully find the LVR Generic HID device
Successfully set usb configuration 1
Successfully claimed MYINTERFACE
Testing control transfer using loop back test of feature report
03, 04; 21, 21; 22, 22; 23, 00;
Testing control transfer using loop back test of input/output report
02, 01; 31, 31; 32, 32; 33, 00;
Testing interrupt transfer using loop back test of input/output report
02, 01; 41, 41; 42, 42; 43, 00;

[mcuee]

HIDAPI Test GUI seems to say the FW is correct.

[mcuee]

Test under Linux (Raspberry Pi 400), hidapitester performs fine (tested with the hidraw backend).

hidapitester on  master ❯ make
gcc -I ../hidapi/hidapi -c ../hidapi/linux/hid.c -o ../hidapi/linux/hid.o
gcc -I ../hidapi/hidapi -c hidapitester.c -o hidapitester.o
gcc -I ../hidapi/hidapi ../hidapi/linux/hid.o hidapitester.o -o hidapitester `pkg-config libudev --libs`
hidapitester on  master ❯  ./hidapitester --vidpid 0925 --list-detail 
0925/7001: Lakeview Research - Generic HID
  vendorId:      0x0925
  productId:     0x7001
  usagePage:     0xFF00
  usage:         0x0001
  serial_number:  
  interface:     0 
  path: /dev/hidraw6

hidapitester on  master ❯ sudo ./hidapitester --vidpid 0925:7001  -l 3 --open --send-output 2,2,3 --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 3-bytes...wrote 3 bytes:
 02 02 03
Reading 3-byte input report 0, 250 msec timeout...read 3 bytes:
 01 02 03
Closing device

hidapitester on  master ❯ sudo ./hidapitester --vidpid 0925:7001  -l 3 --open --send-feature 3,4,5 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 3-byte feature report...wrote 3 bytes:
 03 04 05
Reading 3-byte feature report, report_id 4...read 3 bytes:
 04 04 05
Closing device

[mcuee]

@todbot It seems to me that hidapitester report reading of one more bytes for the Feature report under Windows. Not so sure if this is a problem with hidapitester or hidapi under Windows. If it is related to hidapi under Windows, the test gui seems to be correct. That is strange.

[todbot]

hidapitester is using hidapi directly, and not doing anything platform-specific. If there's a byte miscount, I think it's either in the testgui or the build of hidapitester you're using uses a hidapi with off-by-one errors (this used to exist in hidapi for certain situations, I forget the details at the moment)

[mcuee]

The thing is that I am using the same version of hidapi here, the latest git. Test GUI is also from the latest git.

Supposedly the off-by-one has been fixed.
#232 : for input report
6fcb0bb : for feature report

[mcuee]

It could be an hidapi issue under Windows in the end. Here is the test result from the original generic HID example here:
http://janaxelson.com/hidpage.htm

The C# based GUI application works fine. And the libusb1 hid backend works fine with the off-by-one fix libusb/libusb#986

Host libusb1 codes:
https://github.com/mcuee/picusb/blob/master/lvr_genhid/libusb1_lvrhid4.c

C:\work\picusb\picusb\lvr_genhid [master ≡ +17 ~2 -0 !]> .\libusb_lvrhid4.exe
Successfully find the LVR Generic HID device
Successfully set usb configuration 1
Successfully claimed interface
Testing control transfer using loop back test of feature report
20, 20; 21, 21;
Testing interrupt transfer using loop back test of input/output report
40, 40; 41, 41;

[mcuee]

C# GUI is working fine.

[mcuee]

hidapitester output: total number of read bytes seems to be correct (2 bytes). But the data read seems to be not consistent between input report and feature report. I think we probably need to report reading 3 bytes for the Feature In report, including the report id 0. Let me try other os as well.

C:\work\hid\hidapitester2 [master ≡]> .\hidapitester.exe --vidpid 0925:7001 --open --send-feature 0,0x08,0x88 --read-feature 0
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 2 bytes:
 00 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Closing device
C:\work\hid\hidapitester2 [master ≡]> .\hidapitester.exe --vidpid 0925:7001 --open --send-output 0,0x08,0x88 --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 64-bytes...wrote 3 bytes:
 00 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 250 msec timeout...read 2 bytes:
 08 88 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 00 00 00 00 00 00 00 00 00 00 00 00
Closing device

[mcuee]

The Test GUI indeed has an issue to cut the feature in report by one byte. But the question is that should we report reading 3 bytes or 2 bytes? I think we probably need to report reading 3 bytes, including the report id 0. In that case the GUI will work fine for the reading of feature report.

[mcuee]

@todbot In the end I think hidapitester is good.
The issue is probably for feature report under Windows. Shall we report one more byte so that data will not be truncated? Or shall we discard the first byte (report id 0) to be consistent with the input report under Windows and other OS (edit: this may not be correct, please refer to the comments below)?

[mcuee]

Now I start to question the following commit which I proposed in #232 with regard to feature report. It may be correct when the report id is not zero but may not be correct when the report id is zero. It seems to me for Windows, we may need to read one more byte when the report id is zero.
6fcb0bb

[mcuee]

@Youw : please take a look as well for the feature report. Thanks.

Ref:
#229 (comment)

That is at least a reasonable interpretation of the documentation for hid_get_input_report. However, the same text appears in hid_get_feature_report which, in turn, seems to have conflicting implementations:

liquidctl/liquidctl#312

When looking into #229, I noticed that the behavior of hid_get_feature_report when report IDs are not used is not as clear as I thought, and perhaps not even well defined.

[mcuee]

My recommendation is to discard the report id 0 for feature report under Windows, to be consistent with input report handing under Windows, and also other OS.

Edit: this may not be correct. From the Linux hidapitester output, indeed there is a difference in dealing with input report the feature report. Not so sure if this is because of API difference or real different on the wire.

[mcuee]

Output under Linux:

hidapitester on  master [?] ❯ sudo ./hidapitester_hidraw --vidpid=0925:7001 --open --send-feature 0,0x40,0x41 --read-feature 0
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 3 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device
hidapitester on  master [?] ❯ sudo ./hidapitester_hidraw --vidpid=0925:7001 --open --send-output 0,0x80,0x81 --read-input    
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 64-bytes...wrote 64 bytes:
 00 80 81 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 250 msec timeout...read 2 bytes:
 80 81 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 00 00 00 00 00 00 00 00 00 00 00 00
Closing device

Output under macOS (Mac Mini M1, macOS Big Sur ARM64), same as Linux.

mcuee@mcuees-Mac-mini hidapitester % ./hidapitester --vidpid=0925:7001 --open --send-output 0,0x40,0x41 --read-input   
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 64-bytes...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 250 msec timeout...read 2 bytes:
 40 41 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 00 00 00 00 00 00 00 00 00 00 00 00
Closing device
mcuee@mcuees-Mac-mini hidapitester % sudo ./hidapitester --vidpid=0925:7001 --open --send-feature 0,0x40,0x41 --read-feature 0   
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 3 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device

[mcuee]

Linux test gui is consistent with hidapitester

[mcuee]

Hopefully other Windows users can chime in and test latest git of hidapi to see if there is a real issue for the feature report or not.

[mcuee]

Just tried hidapitester with hidapi-0.10.1 release and hidapi git head, with regard to input report, the result is the same since it is using hid_read_timeout(). So #232 does not matter in that case.
https://github.com/todbot/hidapitester/blob/master/hidapitester.c#L379

With regard to feature report, then the result will be different as it uses hid_get_feature_report(). So commit 6fcb0bb does matter for getting the feature report. In this particular case without report id (report id zero), it seems to me the commit is not correct.
https://github.com/todbot/hidapitester/blob/master/hidapitester.c#L403

$ ./hidapitester_release0101.exe --vidpid=0925:7001 --open --send-feature 0,0x40,0x41 --read-feature 0
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 3 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device

$ ./hidapitester_git4d63a50.exe --vidpid=0925:7001 --open --send-feature 0,0x40,0x41 --read-feature 0
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 2 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device

[mcuee]

For those with report id, commit 6fcb0bb seems to be correct.

C:\work\hid\hidapitester [master ≡ +1 ~1 -0 !]> .\hidapitester_release0101.exe --vidpid 0925:7001 --open --send-feature 3,0x08,0x88 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 03 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 4...read 4 bytes:
 04 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Closing device
C:\work\hid\hidapitester [master ≡ +1 ~1 -0 !]> .\hidapitester_git4d63a50.exe --vidpid 0925:7001 --open --send-feature 3,0x08,0x88 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 03 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 4...read 3 bytes:
 04 08 88 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 00 00 00 00 00 00 00 00 00 00 00
Closing device

[mcuee]

Here is a quick hack of hidapitester with libusb backend (todbot/hidapitester#8)

With patched libusb-1.0.dll (libusb/libusb#986), it works fine.

C:\work\hid\hidapitester [master ≡ +3 ~0 -0 !]> .\hidapitester_libusb.exe --vidpid=0925:7001 --open --send-feature 0,0x40,0x41 --read-feature 0
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 0...read 3 bytes:
 00 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device
C:\work\hid\hidapitester [master ≡ +3 ~0 -0 !]> .\hidapitester_libusb.exe --vidpid=0925:7001 --open --send-output 0,0x80,0x81 --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 64-bytes...wrote 4 bytes:
 00 80 81 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 250 msec timeout...read 3 bytes:
 80 81 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 00 00 00 00 00 00 00 00 00 00 00 00
Closing device

hidapitester_mingw64_libusb.zip

It also works fine with devices with report ids (my mod FW of the above generic hid example from Jan Axelson).

C:\work\hid\hidapitester [master ≡ +3 ~0 -0 !]> .\hidapitester_libusb.exe --vidpid=0925:7001 --open --send-output 2,0x80,0x81 --read-input
Opening device, vid/pid: 0x0925/0x7001
Writing output report of 64-bytes...wrote 3 bytes:
 02 80 81 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte input report 0, 250 msec timeout...read 3 bytes:
 01 80 81 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 00 00 00 00 00 00 00 00 00 00 00
Closing device
C:\work\hid\hidapitester [master ≡ +3 ~0 -0 !]> .\hidapitester_libusb.exe --vidpid=0925:7001 --open --send-feature 3,0x40,0x41 --read-feature 4
Opening device, vid/pid: 0x0925/0x7001
Writing 64-byte feature report...wrote 64 bytes:
 03 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Reading 64-byte feature report, report_id 4...read 3 bytes:
 04 40 41 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 00 00 00 00 00 00 00 00 00 00 00
Closing device

[mcuee]

All in all, hidapitester is okay. But we may need to fix hidapi under Windows, for reading of feature report. Therefore I have created an issue #328.

[mcuee]

I will close this as hidapitester is already mentioned in hidapi README.md.
https://github.com/libusb/hidapi/blob/master/README.md