Open henrikbrixandersen opened 1 month ago
Vendor requests targeting the device should be allowed in the address state.
I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.
Unable to use MSOSv2 descriptors with USB
device_next
.
MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.
If there are no objections in a few days, I will close it.
Vendor requests targeting the device should be allowed in the address state.
I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.
But you do agree that Windows USB enumeration sends a vendor request targeting the device using bMS_VendorCode
while the device is still in address
state?
Unable to use MSOSv2 descriptors with USB
device_next
.MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.
I will be looking forward to that. Is the draft available yet?
If there are no objections in a few days, I will close it.
Please do not close it. What I describe here is possible with the current USB device stack, but not possible with the device_next
stack. Not being able to support MSOSv2 descriptors in device_next
is not acceptable if this is to replace the existing stack in v4.0.0.
If you are already working on supporting this feature, you can link it to close this issue report.
Vendor requests targeting the device should be allowed in the address state.
I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.
There is also:
The USB Specification defines a series of standard requests that all devices must support. These are enumerated in Table 9-3. In addition, a device class may define additional requests. A device vendor may also define requests supported by the device.
My understanding is that "must respond to standard device requests" refers only to the absolute requirements, while "device vendor may also define requests supported by the device" is an option for vendor (MSOSv2 does rely on this). If the vendor does define device requests, then it should be allowed to respond to the vendor device requests at least when not configured (but I see no real reason of not supporting them in the not addressed state - it is up to vendor to define at what state the request is valid after all) because these are bound to device, not interface nor class.
Vendor requests targeting the device should be allowed in the address state.
I only know this statement from the specification: "USB devices must respond to standard device requests, even if the device has not yet been assigned an address or has not been configured." So I do not think there are any requirements to classify it as a bug. Obviously, values in the vendor request table (per class data) may only be used in configured state.
But you do agree that Windows USB enumeration sends a vendor request targeting the device using
bMS_VendorCode
while the device is still inaddress
state?
This is irrelevant, it is not a bug according to the specification.
Unable to use MSOSv2 descriptors with USB
device_next
.MSOSv2 is a bit tricky. I have a draft to support it and will finish it soon along with porting the WebUSB sample.
I will be looking forward to that. Is the draft available yet?
No.
If there are no objections in a few days, I will close it.
Please do not close it. What I describe here is possible with the current USB device stack, but not possible with the
device_next
stack. Not being able to support MSOSv2 descriptors indevice_next
is not acceptable if this is to replace the existing stack in v4.0.0.If you are already working on supporting this feature, you can link it to close this issue report.
Then please change it to "enhancement".
Describe the bug The design of the USB
device_next
stack prevents the use of MSOSv2 descriptors.The device-to-host vendor request targeting the device for the
bMS_VendorCode
is sent in theaddress
state, which causesusbd_config_get_current()
(called fromusbd_class_get_by_req()
to determine which class implementation to forward the vendor request to) to returnNULL
, as no configuration has been set yet.Expected behavior Vendor requests targeting the device should be allowed in the
address
state.Another possible solution could be to add a dedicated, application-level usbd callback for handling requests targeting the device. This would likely allow for a nicer application architecture.
Impact Unable to use MSOSv2 descriptors with USB
device_next
.Environment (please complete the following information):
Additional context Discord thread on this topic: https://discord.com/channels/720317445772017664/733037537982939236/1265216134970478685