[haiku-gsoc] Re: Issues in the USB Stack
- From: Akshay Jaggi <akshay1994.leo@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 6 Aug 2014 11:04:44 +0530
Hi!
On 06-Aug-2014, at 3:18 am, Jérôme Duval <jerome.duval@xxxxxxxxx> wrote:
> Hi Akshay!
>
> I think we don't really want too many users of such an API, which is
> the reason it stayed private until now. This lets us modify it when we
> need without too much thinking. Is having a copy of the header in
> Libusb OK?
This is what I am doing right now.
> The USB stack doesn't use the device address, and is only there to be
> used by bus drivers.
> Not sure why this is required by libusb, it's only informative, right?
I greped for device_address in libusb code. Yes, its basically for information
purposes only, though it might be used by some programs to take device input
from user (for example libusb/examples/fxload.c). But then again, they also
have the usual method of vid:pid.
Just to satisfy the requirement, I can add the integers in path of device file
descriptor, and store that value here.
> This IOCTL only handles usb_generic_descriptor. You should probably
Don’t we have B_USB_RAW_COMMAND_GET_GENERIC_DESCRIPTOR for generic descriptors?
> use B_USB_RAW_COMMAND_GET_CONFIGURATION_DESCRIPTOR instead, and patch
> it to use "total_length":
> * if the provided buffer is exactly the size of
> usb_configuration_descriptor, then just copy that length and return
> OK.
> * if the provided buffer is bigger but too small, then copy that
> length and return B_BUFFER_OVERFLOW.
> The USBKit can eventually be extended later.
We do not get the size of the buffer in
B_USB_RAW_COMMAND_GET_CONFIGURATION_DESCRIPTOR. We have this information in
B_USB_RAW_COMMAND_GET_DESCRIPTOR.
> Bye,
> Jérôme
>
Regards
Akshay Jaggi
Other related posts:
