ADD: GetDescriptor

[NullYing]

use example:

https://github.com/OpenPrinting/ipp-usb/blob/2aa0ad4bdca06b1a9071d109da09e831e2f6d42b/usbio_libusb.go#L529

[zagrodzki]

would this functionality perhaps be satisfied by the ExtraDescriptors proposed in #127? I don't really want to add thin wrappers around libusb functionality in the code. My understanding is that IPP class descriptor is essentially an additional descriptor attached to the USB interface descriptor, something that libusb represents as "extra" part of the interface (see https://libusb.sourceforge.io/api-1.0/structlibusb__interface__descriptor.html). If that could work, then I prefer that approach over wrapping lower level libusb functions.

[NullYing]

I don't know which data I need from ExtraDescriptors. By encapsulating libusb_get_descriptor, I can clearly know that I need to get the data at position 0x21. Moreover, during USB communication, only the get_descriptor instruction at position 0x21 is sent. I believe GetStringDescriptor and GetDescriptor are interfaces of the same level. Whether to fetch all the ExtraDescriptors in one go should be left to the user's choice.

[zagrodzki]

It is not the same and not on the same level.

My understanding based on the USB spec is that generally USB supports retrieval of device descriptors, configuration descriptors and string descriptors (USB spec 2.0, section 9.4.3). According to that spec, the way to obtain class specific descriptors is to retrieve a configuration descriptor and find the correct descriptor that belongs to either configuration, interface or the endpoint specifically. IPP class descriptor belongs to the interface, by extension to the configuration descriptors. We handle these descriptors at enumeration time and they should be retrieved from the configuration.

I don't want gousb to be a wrapper for libusb, I want it to provide USB-related functions with a model that matches how USB works.

For what it's worth, I'm not even sure how what you're doing in the referenced code works - as far as I can tell, neither libusb nor the underlying usbi layer (as least for Linux) do anything special for the HID descriptor type (0x21 in your example code). That means it would be passed as-is to the OS host driver. I suspect Linux is doing some behind the scenes magic to convert this request into an actual descriptor data retrieved from the configuration, but that's not how USB works in general and I don't think it will be portable.

The documentation for the HID class (of which IPP is a subclass) states (HID spec 1.11, section 5.1) says that the HID descriptor is a part of the interface descriptor, so it should be accessed through the descriptor data of the interface, which we hold in the Interface struct.

If my understanding is not completely wrong, then what you want should be obtained through the interface descriptor. This is what the proposed ExtraDescriptors feature does - it includes specific class descriptors as header struct + payload binary data within the Interface struct.

[zagrodzki]

any thoughts? I'll be publishing a new release in ~2wks, it would be nice if we included support for the extra descriptors. If you agree with what I wrote, the best option would be to follow up on PR #127, which should satisfy your needs, but which needs some work before it can go in.

[NullYing]

No,thanks.I will focus on the new release