Feature: usb.control.get_descriptor() does not have any option to get non-standard descriptors

[judahrand]

I am working with USB Hubs and am wanting to get usb hub's 'hub descriptor' as specified in the USB spec. I cannot just use:

usb.control.get_descriptor(hub, 1024, usb.DT_HUB, 0)

because the bmRequestType is hard coded to be generated with:

bmRequestType = usb.util.build_request_type(
                    util.CTRL_IN,
                    util.CTRL_TYPE_STANDARD,
                    util.CTRL_RECIPIENT_DEVICE)

The util.CTRL_TYPE_STANDARD is the problem here. I need to use util.CTRL_TYPE_CLASS. This seems like a feature which could be fairly easily added and I am happy to look at this myself if you think that it would be a good addition. However, I thought it would be good to start a discussion about how to deal with the issue before starting. Should there be an additional argument to determine which CTRL_TYPE to use?

For the moment my solution is to generate the bmRequestType myself and use

bmRequestType = usb.util.build_request_type(
                    usb.util.CTRL_IN,
                    usb.util.CTRL_TYPE_CLASS,
                    usb.util.CTRL_RECIPIENT_DEVICE)

wValue = usb.DT_HUB << 8

dev.ctrl_transfer(bmRequestType, usb.REQ_GET_DESCRIPTOR, wValue=wValue, wIndex=0, data_or_wLength=1024)

I'm sure that this issue probably spans across at least the rest of the descriptor functions in usb.control and possibly others too.

Any feedback or comments would be welcomed! I've really only just started using pyusb!

[mcuee]

Seems to be a valid request and we can add a additional entry in the pyusb/control.py file.

[judahrand]

When you say an additional entry do you mean an additional argument? Because looking at this (https://www.beyondlogic.org/usbnutshell/usb6.shtml) it seems like really CTRL_TYPE_STANDARD should not be hardcoded anywhere. get_status, get/set_configuration, get/set_interface, or clear/set_feature can all take Class or Vendor options, I believe.

If this is added as a keyword argument with a default value of CTRL_TYPE_STANDARD it should't result in a breaking change. This might also reflect the fact the Class and Vendor implementation are not mandatory according to the USB spec?

Anyway, this is just my thoughts having not looked or thought about this for about a year and a half!

[judahrand]

Please do let me know if you agree that this issue is more widespread than just descriptors in the control functions. Seems to be an easy fix for all but set_interface()

[jonasmalacofilho]

@jude188

Because looking at this (https://www.beyondlogic.org/usbnutshell/usb6.shtml) it seems like really CTRL_TYPE_STANDARD should not be hardcoded anywhere. get_status, get/set_configuration, get/set_interface, or clear/set_feature can all take Class or Vendor options, I believe.
[...]
Please do let me know if you agree that this issue is more widespread than just descriptors in the control functions.

Actually I don't agree, as these methods map to standard device requests.

While the spec states:

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.

, these additional requests may or may not match the names and descriptions of their standard counterparts.

[jonasmalacofilho]

Class-specific requests supported by hubs that "overload" standard requests:

• CLEAR_FEATURE: ClearHubFeature (recipient=Device); ClearPortFeature (recipient=Other)
• GET_DESCRIPTOR: GetHubDescriptor
• GET_ STATUS: GetHubStatus (recipient=Device); GetPortStatus (recipient=Other)
• SET_DESCRIPTOR: SetHubDescriptor
• SET_ FEATURE: SetHubFeature (recipient=Device); SetPortFeature (recipient=Other)

Other class-specific requests for hubs: ClearTTBuffer, ResetTT, GetTTState, StopTT.

The base USB 2.0 spec doesn't specify class-specific requests for other classes, though I'm sure other documents do.

Still, I think that as our methods map standard requests, we should at most implement standard + hub requests.

[jonasmalacofilho]

Note: the latest USB 3.2 spec has a different list of class-specific requests for hubs, lacking the transaction translator (TT) requests but also adding GetPortErrorCount and SetHubDepth. My first thought is can simply support the union of these, but maybe that's not safe and the hub type has to be checked/validated.

[mcuee]

I think we can implement only standard requests. The others are optional.

[mcuee]

@jonasmalacofilho Just wondering if you can take a look at this again. Thanks.

[jonasmalacofilho]

I think my position is still the same: we can implement the hub requests, but we should probably stop there. Other/custom requests should generally be implemented by the user; or, perhaps in the future, with methods specific for device classes of interest.

(The hub requests may share APIs with standard device requests in cases like SET_FEATURE).

[jonasmalacofilho]

@judahrand is this still something you're interesting in doing?