Repository navigation
Fix LS-40 USB reads after a split image line - #68
Closed
codethinki wants to merge 1 commit into
Closed
codethinki wants to merge 1 commit into
codethinki wants to merge 1 commit into
Conversation
Author
|
if you dont like the coding style etc review and request changes, I'll fix it. |
Owner
|
Thanks, I'll take a look soon! |
Owner
|
fixed in 0.13 |
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
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.
Scanning a mounted slide on a Nikon Coolscan IV ED / LS-40 with WinUSB fails during host metering, after the first successful 128 KiB image READ. This was reported with NegPy 0.62 using nkscan 0.12 and reproduced with the standalone CLI:
read_data_intreats the first short USB transfer as the maximum size of every later transfer in that data phase. A SCSI READ can split an image line, so the first transfer of the next READ can be a partial line while later transfers contain full lines.In the reported trace, the metering pass has 1,722-byte RGB lines. A 131,072-byte READ ends 200 bytes into a line, leaving 1,522 bytes at the start of the next READ. The reader then limits subsequent buffers to 1,522 bytes.
transfer_inrounds that request to the endpoint's 64-byte packet size, allowing 1,536 bytes to arrive. Those extra bytes belong to the image, but the reader treats them as a stream synchronization failure.The fix asks each USB read for all bytes remaining in the command's data phase. Short transfers can therefore vary in length, and surplus bytes are treated as padding only beyond the end of that phase. The existing command deadline and zero-length termination still apply. The obsolete
Chunk::countpath is removed.Four tests cover the reported partial-line sequence with byte-for-byte payload preservation, final packet padding with the status phase left queued, zero-length termination, and propagation of a read error.
Validation:
cargo fmt --all --check.cargo clippy --locked --all-targets --all-features -- --deny warnings(PyO3 configured for the Python 3.13 stable ABI extension).cargo test --locked --features cli: 156 library tests, one CLI test, and one doctest passed. The two existing hardware tests remain ignored locally.AI assistance: OpenAI Codex produced the diagnosis, code, tests, and PR description. The reporter supplied the original scanner trace, tested the patched build on their scanner, and requested this submission after confirming the fix.