Added new method HidController::send_feature_report

[JoergAtGithub]

Made the method hid_send_feature_report from HIDAPI available to controller mappings.
This generic USB HID "Set Reports (Feature)" functionality is needed to set the NI Traktor Z2 in a mode, where it accepts the bulk HID reports for LED control. See also: https://mixxx.zulipchat.com/#narrow/stream/113295-controller-mapping/topic/Traktor.20Kontrol.20Z2
The USBlyzer dump looks now like this:

[JoergAtGithub]

Do I need to document this new API method anywhere?

[Be-ing]

This is a new feature so it should go to the master branch.

[Be-ing]

Do I need to document this new API method anywhere?

https://github.com/mixxxdj/mixxx/wiki/hid%20mapping#sending-data-to-the-controller

[Be-ing]

I'd argue we should even use the more general API spec where we mandate the reportID to be included in the buffer itself instead of being passed separately just of it to be prepended in the C++ later.

Hmm, we could do this. Or we could make the report ID the first argument so it can't be omitted by the script. However, that could get confusing because controller.send has the arguments the opposite way around. So I think requiring the script to provide the report ID in the buffer would be better.

[JoergAtGithub]

If it's the common opinion, that the method HidController::send_feature_report should have the Report ID at the begining while the nearly identical method HidController::send has it at the end, I will change it!
But my personal opinion is, that such an inconsistent order of arguments in one and the same API, is at least weird, if not a broken.

[uklotzde]

If it's the common opinion, that the method HidController::send_feature_report should have the Report ID at the begining while the nearly identical method HidController::send has it at the end, I will change it!
But my personal opinion is, that such an inconsistent order of arguments in one and the same API, is at least weird, if not a broken.

I agree with that opinion. Either change all signatures or mimic the old style, even if it is considered inappropriate. Consistency is key.

[Be-ing]

How about let's make this new function fit with the existing controller.send API, then in the new controller system we can make a separate HIDControllerJSProxy class with different function signatures? @Swiftb0y what do you think?

[Holzhaus]

Code LGTM, unfortunately I can't test this as I don't own an HID controller.

[JoergAtGithub]

@ywwg Hello Owen, can this be merged?

[Holzhaus]

Ping @ywwg

[JoergAtGithub]

What can I do, to get this PR merged?

[JoergAtGithub]

@ywwg Do you've any objections to merge this?

[uklotzde]

Ping @ywwg

[ywwg]

this looks straightforward. It would be nice if there was a way to add a test for this but we don't have any tests for hidcontroller :(

LGTM

[ywwg]

sorry for my lack of response, github notifies me about every single PR and doesn't highlight individual pings :/. Best to @ me on zulip to get my attention

[Holzhaus]

github notifies me about every single PR and doesn't highlight individual pings :/

Btw, GitHub does show if you've been mentioned at least once in the PR, but it is non-obvious:

It's probably still better to ping people on Zulip.

[JoergAtGithub]

Merge?

[uklotzde]

Safe to merge and after everyone approved the PR no reason for holding this back any longer. Thank your for contributing to Mixxx, Jörg. LGTM