-
Notifications
You must be signed in to change notification settings - Fork 30
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
Port capture backend from rusb
to nusb
#89
Merged
Merged
Conversation
This file contains 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
martinling
force-pushed
the
nusb
branch
2 times, most recently
from
February 8, 2024 00:24
c18ed05
to
b287158
Compare
I just tried this out and I find it gets out of sync on capture start quite often, and gets stuck displaying malformed packets. |
Currently, if errors occur during capture, the capture thread sends them to the decoder thread, via the same channel used for packets. This allows errors to be caught in the decoder thread and shown immediately to the user, even when the the stop button has not yet been pressed, and therefore the capture thread not yet joined. This is unnecessarily complicated though, and can currently lead to some errors being shown twice (where both sent to the decoder thread and returned in the capture thread), or not being shown (where returned in the capture thread, but not sent to the decoder thread). Instead, let's just pass a handler function to LunaHandle::start(), which will be called by the capture thread as it ends. If an error occured, it is then signalled to the user immediately, without the decoder thread needing to be involved. When joining the capture thread, it is still necessary to check if the thread panicked, but any normal error will already have been handled. We can use the existing display_error() function, which already takes care of accessing the UI from whichever thread it is called from.
Rather than the capture thread sending individual packets to the decoder thread, send the contents of entire USB transfers, and do the work of picking out individual packets in the decoder thread.
We need to end up with a new Vec for each transfer anyway, in order to send it to the decoder thread. But we can save a copy by capturing directly into that new Vec, rather than copying from an existing buffer.
@miek I think I've fixed the issues with this now. |
miek
approved these changes
May 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR rewrites the capture backend to use nusb instead of rusb.
Using
nusb
has the following advantages for us overrusb
:libusb
C library:nusb
uses OS APIs directly.libusb
.This PR includes the first usage of
async
in Packetry. I have tried to bring in a minimum of baggage with this:block_on
function.oneshot
channel, to signal the capture task to stop.select_biased
macro andFutureExt::fuse
method.The latter two crates are already in our dependency tree as they are used by the
gio
andglib
crates.Tested on Linux with Cynthion r1.4.