Add sidetone status reading for Arctis Nova 7 Gen 2 - #560
Conversation
|
Thanks looks good so far, will do a more detailed review. However im not sure if it should be |
|
Thanks! Reusing the existing My preferred CLI behavior would be: That keeps the existing setter syntax compatible and avoids adding a separate public Internally I would keep the read capability separate, since some devices can set sidetone but cannot query it. Calling I can update the PR accordingly after your detailed review, or right away if this is the direction you prefer. |
Yes
Yes, sounds good keeping it separate. Feel free to implement, I will review next week. |
|
Implemented in 2144ea9. The CLI now uses |
|
Merged current master (af0ba47) to clear the CONFLICTING state — #549 and #550 both landed since this branched, and independently bumped |
…heck getSidetone() checked bytes_read < 4 before checking for an asynchronous 0xb0 status report, so a short 0xb0 report was treated as a fatal protocol error instead of being skipped like every other one. Move the 0xb0 check first - reading response[0] is safe once bytes_read > 0, since the buffer is zero-initialized and the read fills from index 0.
CAP_SIDETONE's help entry hardcoded "[LEVEL]" instead of calling
getValueHint(CAP_SIDETONE) like its sibling entries, so the
descriptor's own value_hint ("<0-128>") was stale and unused. Updated
the descriptor to "[LEVEL]" to match the option's actual optional-get-
or-set syntax, and pull it via getValueHint() at the call site.
|
Pushed two more fixes from the review: 1ca9872 — getSidetone() checked the response length before checking for an async 0xb0 status report, so a short 0xb0 report was treated as a fatal protocol error instead of being skipped like every other one. Swapped the order and added a regression test (confirmed it fails without the fix, passes with it). 0f046a5 — the -s help entry hardcoded "[LEVEL]" instead of pulling from getCapabilityDescriptor(CAP_SIDETONE) like its sibling options do. Updated the descriptor's value_hint to "[LEVEL]" (it was still the stale "<0-128>" from before this PR) and wired the help entry to getValueHint(). Same rendered output, just no longer a stale, unused source of truth. Full suite still green (2/2, all sidetone tests included) on top of the master merge from earlier. |
Changes made
Adds a generic read-only sidetone status capability and implements it for the verified SteelSeries Arctis Nova 7 Gen 2 (
1038:227e).Device protocol
00 20.20and reads sidetone from byte 2.0/1/2/3to HeadsetControl values0/43/85/128using an explicit table.b0) while waiting for the settings response.0x227e; other Nova 7 PIDs do not advertise the capability.00 09persistence command after setting sidetone only for PID0x227e.The protocol was captured from SteelSeries GG on Windows and is independently corroborated by the proposed Linux SteelSeries driver implementation:
https://patchew.org/linux/20260227235042.410062-1-srimanachanta%40gmail.com/20260227235042.410062-15-srimanachanta%40gmail.com/
Public interfaces
CAP_SIDETONE_STATUSheadsetcontrol -s/headsetcontrol --sidetonequeries; providingLEVELcontinues to set sidetoneHeadset::getSidetone()hsc_get_sidetone()CLI examples:
Example text output:
Example JSON field:
Tests
--sidetone-statusoption is not exposed.cmake --build build --parallel: passedcmake --build build --target check: 2/2 tests passedgit diff --check: passedReal hardware acceptance test on
1038:227e:The optional-value CLI behavior was also verified on the same device with both
-sand--sidetone.Closes #559
Checklist