Conversation
mhlas7
marked this pull request as ready for review
September 3, 2026 03:41
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
reset_all_decks()clears a deck left in a state where writes fail, but its product id list had drifted behindStreamDeck.ProductIDs. Mini Discord, Mini MK2, Neo, Plus XL, Studio and XL V2 were never reset.On those models a wedged deck stayed wedged across restarts: the app opened the device, the first feature report returned
-1, and startup aborted with aTransportErrorevery time until the device was reset by hand.Coverage
ProductIDsdefines 18 constants but 17 distinct values, sinceUSB_PID_STREAMDECK_MK2_MODULEandUSB_PID_STREAMDECK_MK2_V2are both0x00b9.One caveat
Of the six ids added,
udev.rulestags only Mini MK2 (0x0090), Neo (0x009a) and XL V2 (0x008f) foruaccess. On Mini Discord (0x00b3), Plus XL (0x00c6) and Studio (0x00aa) thedevice.reset()can still fail on permissions and be caught by the existing handler, so those three need a udev rule before the reset takes effect. I left that out here since it is a separate concern — happy to fold it in or do a follow-up, whichever you prefer.For what it's worth the two lists were already inconsistent in both directions: the module ids (
0x00b8,0x00b9,0x00ba) are in the reset list with no udev rules either.