-
Notifications
You must be signed in to change notification settings - Fork 290
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Refactors HID connections to support busy response (#699)
* Refactors HID connections to support busy response The main intended difference is that OpenSK now responds with ERR_CHANNEL_BUSY when it receives a packet while waiting for touch in in a CTAP2 command. To support this more elegantly, we changed `HidConnection` to have a `send` and `recv` instead of `send_and_maybe_recv` for a cleaner API. This also resolves an older TODO to respond to incoming channels on the other USB endpoint. It doesn't process the incoming traffic correctly, but unblock the host at least, and tells it to come back later. We still only allow one active channel at the same time. We now don't need the `TRANSMIT_AND_RECEIVE` syscall anymore. I didn't remove it from the Tock pack for simplicity, but cleaned up libtock-drivers. The Env API changes from having one connection per endpoint, to having one send function that takes an endpoint, and a receive function that receives on all endpoints at the same time. The `HidConnection` already received on all endpoints before, which was inconsistent with the existance of, e.g., `VendorHidConnection` being able to receive on the main endpoint. Since we now have a cleaner send and receive API, we use this in `src/main.rs` and simplify it a bit, while making it more consistent with other calls to the HID API. I found an additional inaccuracy in our implementation while refactoring: We want to send keepalives every 100 ms. To do so, we first wait for a button callback for 100 ms. Then we send the keepalive and check if a cancel packet appeared. What should have happened instead is that we listen for HID packets and button presses at the same time during these 100 ms. If nothing happens that stops the loop, we send the keepalive. The old implementation would, in some implementations, wait 200 ms for each keepalive: First 100 for touch, then 100 for `send_and_maybe_receive`. The new implementation can loop faster in case there is a lot of unrelated HID traffic. To make the touch timeout last 30 seconds, we introduce an extra timer and loop until time is up. This might still make us blink the LEDs too fast, but that is already the case in the main loop, and generally would need a bigger refactoring. The only simple workaround to make the LEDs slightly more precise is to wait for touch and packets until it is time to flip the LEDs, and if we return too early within some thresholds, wait again. If we care enough, we can fix that in a later PR. Not sure how to make the test work that I removed in ctap/mod.rs. I'd need to advance the time while the loop is running. Setting a user presence function that advances time seems hard with the Rust borrowing rules. * Refactors status and error codes There are a few small logic fixes hidden in this comit: - We always call `check_complete`, even if we received a cancel. - We only accept Cancel packets from the active channel. - Send timeouts now return `Ctap2StatusCode::CTAP1_ERR_TIMEOUT`. * Stable blinking pattern Before, if the device gets a CTAP2 UP request and another channel sends packets, the blinking pattern would have sped up. The patch for the Tock USB implementation fixes a panic after a timeout in send. * Better TestClock API
- Loading branch information
1 parent
a68fae7
commit b562a79
Showing
13 changed files
with
317 additions
and
426 deletions.
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
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
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
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
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
Oops, something went wrong.