Added hid_send_output_report() function

[mbcinergy]

Where hid_get_input_report() was already available for some time, hid_send_output_report() was still missing.

We have used our own fork with this function added for a couple of years now, but believe it's better to add this to the main repository as well.

The changes are tested for Windows and on Linux (hidraw and libusb).

The functions for mac and netbsd are also added but not tested, since we currently have no hardware available for that. It would be great if somebody can test this function for those platforms as well, but the functions are very straightforward so I don't expect any issues with them.

[Youw]

So far I haven't encountered cases when you have to use hid_send_output_report specifically, instead of using hid_write.

Most implementations of hid_write would try to use interrupt pipe to send the data if possible first, and would fallback to "hid_send_output_report" if there is no interrupt (output) pipe for a specific device.

On some platforms, the implementation of hid_write is identical to suggested hid_send_output_report, and on others - should work identically (but "better"). Have you tried it?

[mbcinergy]

So far I haven't encountered cases when you have to use hid_send_output_report specifically, instead of using hid_write.

Most implementations of hid_write would try to use interrupt pipe to send the data if possible first, and would fallback to "hid_send_output_report" if there is no interrupt (output) pipe for a specific device.

On some platforms, the implementation of hid_write is identical to suggested hid_send_output_report, and on others - should work identically (but "better"). Have you tried it?

I've tried hid_write, but it does not work in this case. The issue is that we have a couple of devices which do have an interrupt output pipe but use the control pipe for some vendor specific reports. That's why the hid_write does not work out of the box for those devices. So we need a function which is able to specify the pipe we need to write to.

[JoergAtGithub]

Wouldn't it be better to read the Endpoint Descriptor to determine if the particular interface of the USB device has a Interupt Out?

[Youw]

Not sure what do you mean. Right now libusb backend looks for a first interrupt endpoint of a particular interface. But it reads from a USB config descriptor.

I didn't check the linux/hidraw implementation, but Windows and macOS implementation is not exactly known.

[JoergAtGithub]

I meant this: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/standard-usb-descriptors#usb-endpoint-descriptor

[Youw]

I meant this: https://learn.microsoft.com/en-us/windows-hardware/drivers/usbcon/standard-usb-descriptors#usb-endpoint-descriptor

I'm pretty sure that's what we do on libusb backend. On other backends we don't have any control, as functions like write are the OS/Platform implementation, which appear to have in a similar way.