HID Switch to force sending of duplicate data and cleanup of JS API functions

[JoergAtGithub]

I added a switch to force the sending of HID OutputReports with identical data, as needed by @Be-ing to support the S4 MK3 mapping: #4585 (comment)

After looking at the JavaScript API, I found out, that
Q_INVOKABLE void send(const QList<int>& data, unsigned int length = 0) override
is only there to comply with the inheritance of controller.c. But this function is practically useless. It doesn't send raw bytes as the siblings for MIDI and BULK, because this is a functionality, which the HID protocoll doesn't support. Instead it sends a OutputReport with hardcoded ReportID 0. I wonder, if this function was ever used anywhere.

Than there is
Q_INVOKABLE void send(const QList<int>& data, unsigned int length, unsigned int reportID)
which has already one unused argument (length).

Both send functions use QLIST as argument, while since #4521, the other functions of the JavaScript API use QByteArray.

I added a new API function with QByteArray
Q_INVOKABLE void sendOutputReport(unsigned int reportID, const QByteArray& dataArray, resendUnchangedReport = false)
and extended the old send function backward compatibility:
Q_INVOKABLE void send(const QList<int>& dataList, unsigned int length, unsigned int reportID, resendUnchangedReport = false)
Note: I found no way to make an overloaded function work, which support both QList or QByteArray. Independend of the type in JavaScript, always the same function was called.

Furthermore I noticed, that the comments describing these JavaScript API functions are no longer apply since #4521, I rewrote them (in Doxygen syntax). Especially the returned array of getInputReport became incompatible to the incommingdata function. And this compatibility was the only reason to prepend the reportId to the data array.

Now the HID API functions are:

Unchanged since 2.3:
Q_INVOKABLE void send(const QList<int>& dataList, unsigned int length = 0) override
IMHO this function makes no sense, but I kept it for backward compatibility

Extended since 2.3:
Q_INVOKABLE void send(const QList<int>& dataList, unsigned int length, quint8 reportID, bool resendUnchangedReport = false)
Added optional argument resendUnchangedReport - Note that the Length argument is unused and it uses QList

New in 2.4 and now unified in content and type of the data array:
Q_INVOKABLE void sendOutputReport(quint8 reportID, const QByteArray& dataArray, bool resendUnchangedReport = false)
Q_INVOKABLE QByteArray getInputReport(quint8 reportID)
Q_INVOKABLE void sendFeatureReport(quint8 reportID, const QByteArray& reportData)
Q_INVOKABLE QByteArray getFeatureReport(quint8 reportID)

This is now similar to the basic IO functions in all other HID APIs I know - as well in naming as in order of arguments

[Be-ing]

@JoergAtGithub could you take care of @uklotzde's review comments above?

I would prefer to not add yet another function to the API for this one niche use case.

[daschuer]

Does it make sense to adjust res/controllers/common-hid-packet-parser.js to the new API?

[JoergAtGithub]

Does it make sense to adjust res/controllers/common-hid-packet-parser.js to the new API?

In fact, this is what I had done for testing this PR. There is only one single line to change:

mixxx/res/controllers/common-hid-packet-parser.js

Line 694 in 2c3b119

controller.send(data, data.length, this.reportId);

this needs to be changed to:
controller.sendOutputReport(this.reportId, Uint8Array.from(data).buffer);

[daschuer]

In fact, this is what I had done for testing this PR. There is only one single line to change:

For my understanding this saves some CPU cycles due to the QByteArray, right? Would you mind to add this commit?

This PR looks good to me.

@uklotzde: Can we merge?

[JoergAtGithub]

For my understanding this saves some CPU cycles due to the QByteArray, right? Would you mind to add this commit?

I don't know, what's the more efficient implementation. I would prefer to do it in a follow-up PR for common-hid-packet-parser.js

[uklotzde]

Thank you for this follow-up PR. Reordering the parameters to reflect the order within the actual data make sense. Not touching the Q_INVOKABLE functions goes without saying.

The data is copied twice into QByteArray? I didn't check if this behavior is unchanged from before.

LGTM