Support HID++ error data and non-long errors

[mrubli2]

This fixes a bug that we previously talked about in #12 (comment) and adds a small feature to allow client applications to read the error bytes that HID++ errors can contain (quite helpful to retrieve details about the errors for certain HID++ functions).

The two commits are unrelated, so they could be separated if desired.

[cvuchener]

It feels like this should be a standard algorithm. But I don't know which one. The best I can come up with is:

auto begin = _data.begin() + 6;
auto end = std::find_if(std::make_reverse_iterator(_data.end()), std::make_reverse_iterator(begin), [](int v){return v != 0;}).base();    // Look for the last non-zero byte
error_data->assign(begin, end);

But it is not really readable. I guess your version is fine.

[mrubli2]

I remember starting off searching for a standard algorithm solution and ended up deciding that the loop was a lot more readable. 😄

[cvuchener]

OK, this looks good but I have one question. On what does the presence and the format of the extra data depends? Is it the protocol version? Or the function being called? (the underlying question being: who should be responsible for parsing the data?)

[mrubli2]

Sorry for the delay! The extra data depends purely on the function. Most functions don't give any extra data but some might, in which case the feature code needs to decode it.

I can't share the full spec for that feature just yet but here's an excerpt from an upcoming feature that should help illustrate how functions might specify the error behavior:

This function may return standard HID++ 2.0 error codes.

In order to assist with debugging additional error data may optionally be included in the error response’s data bytes. Such information appears in the form of short non-zero-terminated ASCII strings. In the case of short reports the additional error data may be truncated to a single byte.

Possible errors include:

NOT_ALLOWED if levels are not supported for this control.

INVALID_ARGUMENT with "T" if the level type (linear or non-linear) implied by the linear flag is not supported.

INVALID_ARGUMENT with "D" if the payload data is too short.

INVALID_ARGUMENT with "MMR" if the conditions on the control’s min, max, or res restrictions are violated.

In this case the extra error data not only shows up nicely in the USB analyzer but the client code can turn it into a more meaningful message.