Introduce an allow_duplicates flag for common USB matching options#1770
Introduce an allow_duplicates flag for common USB matching options#1770jimklimov merged 3 commits intonetworkupstools:masterfrom
allow_duplicates flag for common USB matching options#1770Conversation
eee015a to
22ef8c2
Compare
driver.state tracking, and an allow_duplicates flag for common USB matching optionsallow_duplicates flag for common USB matching options
clepple
left a comment
There was a problem hiding this comment.
if it were up to me, I wouldn't want to take on the burden of user support for non-deterministic device matching. As much as we have tried for feature parity between the libusb-0.1 and 1.0 backends, this might be one of those cases where libusb-1.0 features would work better in the end. But I really don't have time to dig into this particular problem.
|
Well, as far and wide as I could, I've posted warnings about non-determinism into code and docs and PR messages, so there's that. At least it does allow users to handle situations not possible earlier. On a related although coincidental note, having a discussion with @efuss about matching some Qx devices that are identical for all visible USB parameters but are differentiated by vendor protocol details ("slave number"). To access those nuances a |
Closes: #1756
Initially also addressed #1767 (seen in "screenshots" below) but that change was offloaded to PR #1771
Also does minor codebase maintenance, and partially follows up from recent work in PRs:
May help in situations raised in issues such as:
Note that use of USB device matching by a unique combination of fields is much more preferable to
allow_duplicates(if possible).Example with use of the new feature (while the driver is running as another process):
Example without: