Add a UVC extension project for Unix and Windows#56
Conversation
pkhansen
left a comment
There was a problem hiding this comment.
I prefer this way of doing it as the sort of baseline for uvc control requests. I think there is room for more convenience, but that should be at a higher level anyway.
Tests are a-okay on mac
cceec5a to
7b94699
Compare
4986e0f to
7983a2f
Compare
There was a problem hiding this comment.
Pull request overview
This PR adds scaffolding for a UVC (USB Video Class) extension project, enabling device class-specific functionality through extension methods. The extension allows developers to interact with UVC devices using simplified APIs by importing using UsbDotNet.Extensions.ControlTransfer.Uvc.
Changes:
- Introduced
ControlRequestUvcenum defining UVC-specific control request codes - Added extension methods
ControlReadUvcandControlWriteUvcfor simplified UVC device communication - Created comprehensive test coverage for UVC control read/write operations
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| UsbDotNet.Extensions.Tests.csproj | Added project reference to UsbDotNet.Core to support test infrastructure |
| Given_a_video_class_USB_device_with_UVC.cs | Added test class with read/write tests for UVC brightness control |
| UsbDeviceExtension.cs | Implemented extension methods for UVC control transfers |
| ControlRequestUvc.cs | Defined enum of UVC control request codes with detailed documentation |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
7983a2f to
e411c06
Compare
2b3dd7b to
f967b1c
Compare
e411c06 to
de1b1db
Compare
9d98a82 to
89f3a5c
Compare
1f4e0ac to
89b37d1
Compare
and ControlWrite -> ControlWriteUvc
and ControUvcWrite -> ControlWriteUvc
and fix issues uncovered by tests
it was poorly structured and hard to read
type, and move it to the root of the UVC extension project
The entityId is completely redundant. According to the USB spec, having multiple nodes/units with the same GUID on a USB interface is not possible. Hence, we can always resolve the unit/node ID internally.
and fix issues uncovered by tests
for all "soft" errors. This aligns UvcControls error handling with other extensions like ControlRead, ControlWrite, ControlReadUvc and ControlWriteUvc.
Type names should not be plural.
Most of the calls will never throw that exception.
for slightly improved performance during concurrent read
and improve docs
89b37d1 to
48627c9
Compare
|
Rebased on main and resolved conflicts |
An updated version of #49, the difference is mainly that standard control request has also been moved to the extensions project.
Original PR description:
This is a suggested template for how we can do USB device class specific extensions. Let me know what you think.
The idea is that the integrator can get access to an extension, simply by adding e.g.
using LibUsbSharp.Extensions.Uvc;to their implementation. This pattern can be reused for future extensions and we can choose to put each (or very large) extensions in completely separate projects and thereby separate Nuget packages.I think this keeps a clear separation between the core project and extensions.
Adds a new UsbDotNet.Extensions.Uvc project providing cross-platform USB Video Class (UVC) control support, along with integration tests.
New addtions last 30 days:
Design decisions: