[haiku-commits] Re: r42812 - in haiku/trunk: headers/os/device src/add-ons/kernel/drivers/bus/usb src/kits/device

  • From: Philippe Houdoin <philippe.houdoin@xxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Sun, 9 Oct 2011 19:44:56 +0200

Hi Michael,

> Could you please expain what you are trying to solve?

Well, libusb requires to be able to return the *whole* descriptor, and
applications using this API expect to find the whole one.
Because they parse it themselves, something libusb don't really wrap.

> The configuration descriptor is supposed to only consist of interface 
> descriptors that
> then contain endpoint and generic descriptors.
> All of those can be
> enumerated via the corresponding BUSBConfiguration/BUSBInterface members
> (BUSBInterface::OtherDescriptorAt() would be for enumerating generic
> descriptors). This is also true for non-active configuration/interface
> descriptors.

But, alas, descriptors order could mater.
As I found out. Initially, I did exactly what you suggest here:
rebuild the whole configuration descriptor by iterating them via USB
Kit API.
Unfortunatly, the USB2 companion descriptors then where either placed
before or after endpoint descriptors, depending on when I was
appending it along all other interface generic descriptors. But these
specific descriptors must follow right after the endpoint descriptor!

With some more work, I could theorically find a way to place theses in
the right place, but
1) it will only works if the order in which
BUSBInterface::GenericDescriptorAt() is the same than in the
configuration descriptor, which may not be warranted in the future
2) new descriptors in the future may needs too to appear in a specific
order, which will break again the rebuild process, and
3) from kernelland anyone can retrieve from USB stack this full
descriptor as transmitted by device, so I failed to see why userland
can't either, something which will fix my needs and avoid 1) and 2)
points.

The issue is mostly about not breaking USBKit ABI, which is why I
asked for proofreading.

> Please keep the pointer style consistent with the rest of the file.
> Especially when it's obvious as in this case where the next pointer is
> just a few lines up.

Oops, my bad.
I'll fix it. Thanks.

>>       B_USB_RAW_COMMAND_GET_ALT_INTERFACE_COUNT,
>>       B_USB_RAW_COMMAND_GET_ACTIVE_ALT_INTERFACE_INDEX,
>> +     B_USB_RAW_COMMAND_GET_CONFIGURATION_DESCRIPTOR_ETC,
>
> Adding that there will break the old-USBKit <-> usb_raw interface,

Are you sure?

IIRC, the _ETC opcodes were added already for Haiku and were not
present in BeOS's USBKit.h
I've just add this one before the GET_INTERFACE_DESCRIPTOR_ETC and
GET_ENDPOINT_DESCRIPTOR_ETC opcodes to keep the logical configuration
/ interface / endpoint orders.

And it's still compatible with the
B_USB_RAW_COMMAND_GET_CONFIGURATION_DESCRIPTOR opcode except if I've
missed something.

> which up until now was still compatible (i.e. stuff built with USBKit.a
> under BeOS would work due to the fixed ioctl interface against
> usb_raw).

I'll try to find BeOS USBKit headers to check, but my impression was
that it break the existing opcodes, just add another one.

Bye,
Philippe.

Other related posts: