Re: [Libusbx-devel] [libusbx] Report error for bogus string descriptors (#156)

2013-11-05 Thread Peter Wu
@LudovicRousseau UTF-16 as presented by the USB spec (`_utf16` then). Checking for validity will require a library such as iconv, so I am not sure if it is a good idea to add deeper validation. If support for validation will be added anyway, then UTF-8 would be nice. Who is using UTF-16 anyway e

Re: [Libusbx-devel] [libusbx] Report error for bogus string descriptors (#156)

2013-11-05 Thread Peter Wu
> In this particular case, I would argue that the most flexible response > is for the library to return exactly what it got, unless the user has > requested interpretation (that is, the _ascii version). In that case, > we can be free to reject bad data. What about adding a `_unicode` version the

Re: [Libusbx-devel] [libusbx] Report error for bogus string descriptors (#156)

2013-11-04 Thread Peter Wu
When I read the documentation, I thought that the only difference between the libusb_get_string_descriptor and _ascii function was that the former returned UTF-16. I was surprised when I discovered that it was actually such a thin wrapper. The documentation says: > number of bytes returned in d

Re: [Libusbx-devel] [libusbx] Report error for bogus string descriptors (#156)

2013-11-04 Thread Peter Wu
It would be nicier if this libusb_get_string_descriptor function can be moved into the library instead of keeping it in the library. That would make newer library versions backwards incompatible, but it allows for updating the implementation without having to recompile programs. Thoughts? (This

[Libusbx-devel] [libusbx] Report error for bogus string descriptors (#156)

2013-11-04 Thread Peter Wu
This Ralink device returns bogus values for some string descriptors (iSerial, iInterface). The bDescriptorType and everything following that changes every time, but at least the first byte stays consistently 0. The USB 2.0 spec (9.6.7 String) does not define the behavior for bLengths 0 and 1, so le

Re: [Libusbx-devel] [libusbx] lsusb order got changed (#131)

2013-08-14 Thread Peter Wu
libusbx probably won't fix this, I just reported it such that this gotcha is at least documented. The USB devices were never removed after booting up and the USB bus numbers would always stay the same (unlike the device numbers). That assumption broke with 1.0.16, but at least I have a workarou

[Libusbx-devel] [libusbx] lsusb order got changed (#131)

2013-08-14 Thread Peter Wu
After upgrading libusbx from 1.0.15 to 1.0.16 I noticed that one of my scripts broke because the output of lsusb (from usbutils 007) got changed. I bisected it to commit 6853291 which added hotplug support to the Linux backend. For now I am using `sort` to get some of devices sorted by bus numbe