-
-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SteelSeries Arctis 7. #16
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work.
I noticed a missing free in the implementation. Also the code style differs a bit (using memcpy vs memmove; using double parentheses in if statements), however this isn't really important.
src/devices/steelseries_arctis7.c
Outdated
// the range of the Arctis 7 seems to be from 0 to 0x12 (18) | ||
num = map(num, 0, 128, 0x00, 0x12); | ||
|
||
unsigned char *buf = calloc(31, 1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
buf is not getting free'd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch.
Regarding memcpy
vs. memmove
: I try to avoid memcpy
since its potential benefit (increased speed potentially through prefetching) outweigh the risk (not safe with overlapping regions). Especially in this case it won't make any difference, neither runtime-related nor behavioral.
|
||
if (num) | ||
{ | ||
memmove(buf, data_on, sizeof(data_on)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
memmove is usually used when there is overlapping memory, normally I would use memcpy, but it doesn't really matter much
Also I tested wether it still works with my Headset, there doesn't seem to be any problem and I also guess that there won't be with other ones. Otherwise the interface id's of the other headsets must be adapted. |
b834421
to
64e2f85
Compare
Updated the branch. Some more cleanup, less code duplication etc. |
Touches on Sapd#8, but doesn't fix it. Should be backwards-compatible if all device structures are nulled (trivially true for static variables like here) and enumerating the HID devices returns the default one that would be opened via hid_open().
Currently only supports setting (or disabling) the sidetone feature.
64e2f85
to
b6f6f4e
Compare
Err... I don't get why git sometimes changes more commits than would be needed, so threw in a quick branch rebase. |
Thank you, I merged it into master |
…tis7 Add support for SteelSeries Arctis 7.
This currently only supports setting (or disabling) the sidetone feature.
Sadly, this control station falls out of line by using Output Requests instead of Feature Requests, so the code is a tad different from all the other implementations.
Further, the request needs to be sent to a non-default interface, which touches on #8. Thus, I've implemented initial interface opening, which SHOULD be backwards compatible due to initializing the device structure statically (and thus nulling the memory block) and assuming that
hid_enumerate
returns the default interface as the first one - which would be whathid_open(vid, pid)
would normally open.I was not able to actually test this, though, so please go ahead and make sure it doesn't break your devices.