[Libusb-devel] Getting the serial number of the camera fails

[Bram Bouwens]

Using libusb v1.0.8.10306

My current goal is to figure out which USB camera is connected, so VID:PID:serial.
On Linux this is easy, but unfortunately I have a client using Windows.
The native Windows API to get to this it pretty much outside my comfort zone.

So: I'm trying libusb. Tried the binary from http://libusb-winusb-wip.googlecode.com/files/libusb_2010.09.21.7z
first, and now the current version from git://git.libusb.org/libusb-pbatard.git .
Building using cygwin doesn't show any problems, but then I try the example,

xusb.exe -d 046d:0807

and the result looks promising, but not completely what I hoped for, see attachment.
This is on an Acer laptop running Windows 7; I'm not sure if further details are relevant.

As a fall back I'm considering the old libusb-win32 but that seems to require additional
stuff to be installed which I'd rather avoid.

So, is there something I may have forgotten, or something I should try?

Cheers,

Bram Bouwens

[Xiaofan Chen]

Post by Bram Bouwens
My current goal is to figure out which USB camera is connected, so VID:PID:serial.

The current libusb-1.0 Windows backend should work with this, without
using any special driver. So you should not need to use libusb-win32.

Post by Bram Bouwens
On Linux this is easy, but unfortunately I have a client using Windows.
The native Windows API to get to this it pretty much outside my comfort zone.
Building using cygwin doesn't show any problems, but then I try the example,
 xusb.exe -d 046d:0807
and the result looks promising, but not completely what I hoped for, see attachment.
This is on an Acer laptop running Windows 7; I'm not sure if further details are relevant.

What do you mean by not completely what you hoped for? What is
the serial number of the real device (is it 2 or not)? You can use usbview for
this task.

Reading device descriptor:
length: 18
device class: 239
S/N: 2
VID:PID: 046D:0807
bcdDevice: 0009
iMan:iProd:iSer: 0:0:2
nb confs: 1

You can get usbview from FTDI or from Microsoft (WDK).
http://www.ftdichip.com/Support/Utilities.htm

[Bram Bouwens]

Post by Xiaofan Chen

Post by Bram Bouwens
My current goal is to figure out which USB camera is connected, so VID:PID:serial.

The current libusb-1.0 Windows backend should work with this, without
using any special driver. So you should not need to use libusb-win32.

That is what I expected...

Post by Xiaofan Chen

Post by Bram Bouwens
On Linux this is easy, but unfortunately I have a client using Windows.
The native Windows API to get to this it pretty much outside my comfort zone.
Building using cygwin doesn't show any problems, but then I try the example,
xusb.exe -d 046d:0807
and the result looks promising, but not completely what I hoped for, see attachment.
This is on an Acer laptop running Windows 7; I'm not sure if further details
are relevant.

What do you mean by not completely what you hoped for? What is
the serial number of the real device (is it 2 or not)? You can use usbview for
this task.
length: 18
device class: 239
S/N: 2
VID:PID: 046D:0807
bcdDevice: 0009
iMan:iProd:iSer: 0:0:2
nb confs: 1

This iSer is the iSerialNumber field, which is passed to a call like
libusb_get_string_descriptor_ascii(udev, iser, string, sizeof(string));
to get the actual string. And apparently this fails. The expected result
is 6529E270 .

Post by Xiaofan Chen
You can get usbview from FTDI or from Microsoft (WDK).
http://www.ftdichip.com/Support/Utilities.htm

I'll have a look there. But when I manage to read the number, the next step
will be to make a JNI interface to the program (which therefore will become
a DLL on Windows and a .so on Linux). For that task I don't feel comfortable
with the programming environment Microsoft provides.


Bram

[Xiaofan Chen]

Post by Bram Bouwens

Post by Xiaofan Chen
What do you mean by not completely what you hoped for? What is
the serial number of the real device (is it 2 or not)? You can use usbview for
this task.
            length: 18
      device class: 239
               S/N: 2
           VID:PID: 046D:0807
         bcdDevice: 0009
   iMan:iProd:iSer: 0:0:2
          nb confs: 1

This iSer is the iSerialNumber field, which is passed to a call like
libusb_get_string_descriptor_ascii(udev, iser, string, sizeof(string));
to get the actual string. And apparently this fails. The expected result
is 6529E270 .

I see.

Post by Bram Bouwens

Post by Xiaofan Chen
You can get usbview from FTDI or from Microsoft (WDK).
http://www.ftdichip.com/Support/Utilities.htm

I'll have a look there. But when I manage to read the number, the next step
will be to make a JNI interface to the program (which therefore will become
a DLL on Windows and a .so on Linux). For that task I don't feel comfortable
with the programming environment Microsoft provides.

usbview is to read the USB descriptors. You can also use "lsusb -vvv"
under Linux and post the output about your device.

I think libusb-1.0 should work for you. I will try out this at my
end to see if the current libusb-1.0 Windows code works with
USB mass storage device.

[Xiaofan Chen]

Post by Xiaofan Chen
I think libusb-1.0 should work for you. I will try out this at my
end to see if the current libusb-1.0 Windows code works with
USB mass storage device.

Firstly I tried to use libusb-win32 filter (device filter in the
libusb-win32 svn test branch) and it works fine. There is
a Java wrapper for it. So you can take a look at it as well.

bus-0/\\.\libusb0-0002--0x0781-0x5151 0781/5151
- Manufacturer : SanDisk
- Product : Cruzer Micro
- Serial Number: 0000B8702360177D
wTotalLength: 32
bNumInterfaces: 1
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: 80h
MaxPower: 47
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 8
bInterfaceSubClass: 6
bInterfaceProtocol: 80
iInterface: 0
bEndpointAddress: 81h
bmAttributes: 02h
wMaxPacketSize: 512
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 02h
bmAttributes: 02h
wMaxPacketSize: 512
bInterval: 0
bRefresh: 0
bSynchAddress: 0


I will try out xusb later. Maybe it has a bug in terms of getting
the serial number judging from your debug log.

[Xiaofan Chen]

Post by Xiaofan Chen
I will try out xusb later. Maybe it has a bug in terms of getting
the serial number judging from your debug log.

Oops, I got worse result than you.

D:\work\libusb1\snapshots\libusb_2010.09.21\examples\bin32>xusb -d 0781:5151
Using libusb v1.0.8.10305

Opening device...
libusb:debug [libusb_get_device_list]
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 255 session_id 255
libusb:debug [usb_enumerate_hub] allocating new device for session 255
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB20#4&7056C45&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 2 session_id 2
libusb:debug [usb_enumerate_hub] allocating new device for session 2
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 39 bytes)
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 1 session_id 1
libusb:debug [usb_enumerate_hub] allocating new device for session 1
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 55 bytes)
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 3 session_id 3
libusb:debug [usb_enumerate_hub] allocating new device for session 3
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 0 devaddr 5 session_id 5
libusb:debug [usb_enumerate_hub] allocating new device for session 5
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 255 session_id 511
libusb:debug [usb_enumerate_hub] allocating new device for session 511
libusb:debug [initialize_device] active config: 1
libusb:debug [usb_enumerate_hub] 8 ports Hub:
\\.\USB#ROOT_HUB#4&278C294E&0#{F18A0E88-C30C-11D0-8815-00A0C906BED8}
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 1 session_id 257
libusb:debug [usb_enumerate_hub] allocating new device for session 257
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 2 session_id 258
libusb:debug [usb_enumerate_hub] allocating new device for session 258
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 34 bytes)
libusb:debug [usb_enumerate_hub] busnum 1 devaddr 4 session_id 260
libusb:debug [usb_enumerate_hub] allocating new device for session 260
libusb:debug [initialize_device] active config: 1
libusb:debug [cache_config_descriptors] cached config descriptor 0
(bConfigurationValue=1, 32 bytes)
libusb:debug [discovered_devs_append] need to increase capacity
libusb:debug [set_device_paths] path (0:1):
\\.\USB#VID_0403&PID_CFF8#53T9XDR4#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): USBCCGP
libusb:debug [set_device_paths] matched driver name against Composite API
libusb:warning [set_composite_device] interface_path[0]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] interface_path[1]: unhandled API
- interface will be disabled
libusb:warning [set_composite_device] composite device: no interfaces were found
libusb:debug [set_device_paths] path (1:2):
\\.\USB#VID_046D&PID_C054#5&207B166D&0&4#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): HIDUSB
libusb:debug [set_device_paths] matched driver name against HID API
libusb:debug [set_hid_device] interface_path[0]:
\\.\HID#VID_046D&PID_C054#6&A6CCB04&0&0000#{4D1E55B2-F16F-11CF-88CB-001111000030}
libusb:debug [set_device_paths] path (0:2):
\\.\USB#VID_04D8&PID_9009#JIT093596758#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): NCBULK
libusb:debug [set_device_paths] path (1:1):
\\.\USB#VID_058F&PID_9360#2004888#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): USBSTOR
libusb:debug [set_device_paths] path (0:5):
\\.\USB#VID_0781&PID_5151#0000B8702360177D#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): USBSTOR
libusb:debug [set_device_paths] upper filter driver(s): LIBUSB0
libusb:debug [set_device_paths] path (0:3):
\\.\USB#VID_0781&PID_5530#0165731395136589#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): USBSTOR
libusb:debug [set_device_paths] path (1:4):
\\.\USB#VID_FFFF&PID_0005#DEADC0DE#{A5DCBF10-6530-11D2-901F-00C04FB951ED}
libusb:debug [set_device_paths] driver(s): LIBUSB0
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_get_device_descriptor]
libusb:debug [libusb_open] open 0.5
libusb:debug [unsupported_open] unsupported API call for 'open'
(unrecognized device driver)
libusb:debug [libusb_unref_device] destroy device 0.255
libusb:debug [libusb_unref_device] destroy device 0.2
libusb:debug [libusb_unref_device] destroy device 0.1
libusb:debug [libusb_unref_device] destroy device 0.3
libusb:debug [libusb_unref_device] destroy device 0.5
libusb:debug [libusb_unref_device] destroy device 1.255
libusb:debug [libusb_unref_device] destroy device 1.1
libusb:debug [libusb_unref_device] destroy device 1.2
libusb:debug [libusb_unref_device] destroy device 1.4
Failed.
libusb:debug [libusb_exit]
libusb:debug [libusb_exit] destroying default context

[Xiaofan Chen]

Post by Xiaofan Chen

Post by Xiaofan Chen
I will try out xusb later. Maybe it has a bug in terms of getting
the serial number judging from your debug log.

Oops, I got worse result than you.

On the other hand, the current xusb code has the claiming
interface codes before getting the string descriptors. I think
this is related to your problem.

What if you try to remove the claiming interface code?

/* comment out the following codes or move them after the string
descriptor reading codes
for (iface = 0; iface < nb_ifaces; iface++)
{
printf("\nClaiming interface %d...\n", iface);
r = libusb_claim_interface(handle, iface);
#ifdef OS_LINUX
if ((r != LIBUSB_SUCCESS) && (iface == 0)) {
// Maybe we need to detach the driver
perr(" Failed. Trying to detach driver...\n");
libusb_detach_kernel_driver(handle, iface);
iface_detached = iface;
printf(" Claiming interface again...\n");
r = libusb_claim_interface(handle, iface);
}
#endif
if (r != LIBUSB_SUCCESS) {
perr(" Failed.\n");
}
}

*/
printf("\nReading string descriptors:\n");
for (i=0; i<3; i++) {
if (string_index[i] == 0) {
continue;
}
if (libusb_get_string_descriptor_ascii(handle, string_index[i],
string, 128) >= 0) {
printf(" String (0x%02X): \"%s\"\n", string_index[i], string);
}
}

[Xiaofan Chen]

Post by Xiaofan Chen
On the other hand, the current xusb code has the claiming
interface codes before getting the string descriptors. I think
this is related to your problem.
What if you try to remove the claiming interface code?
/* comment out the following codes or move them after the string
descriptor reading codes */

Okay, somehow this is not really working as the method to get
the string descriptor is through control transfer and the current
Windows backend codes need to use the real WinUSB
or HID driver to carry out the control transfer.

I am not so sure about the way out for you if you stick to
use libusb-1.0. Supposedly you can do it. But the current
implementation seems not possible.

/** \ingroup desc
* Retrieve a descriptor from a device.
* This is a convenience function which formulates the appropriate control
* message to retrieve the descriptor. The string returned is Unicode, as
* detailed in the USB specifications.
*
* \param dev a device handle
* \param desc_index the index of the descriptor to retrieve
* \param langid the language ID for the string descriptor
* \param data output buffer for descriptor
* \param length size of data buffer
* \returns number of bytes returned in data, or LIBUSB_ERROR code on failure
* \see libusb_get_string_descriptor_ascii()
*/
static inline int libusb_get_string_descriptor(libusb_device_handle *dev,
uint8_t desc_index, uint16_t langid, unsigned char *data, int length)
{
return libusb_control_transfer(dev, LIBUSB_ENDPOINT_IN,
LIBUSB_REQUEST_GET_DESCRIPTOR, (LIBUSB_DT_STRING << 8) | desc_index,
langid, data, (uint16_t) length, 1000);
}

int LIBUSB_CALL libusb_get_string_descriptor_ascii(libusb_device_handle *dev,
uint8_t desc_index, unsigned char *data, int length);

[Xiaofan Chen]

I tried that. It doesn't help. It's the libusb_get_string_descriptor_ascii
that returns the error
"libusb:error [composite_submit_control_transfer] no libusb supported
interfaces to complete request" message.

Yes you are right.

Interesting enough, I also have a Cruzer (0781:5204) which produces almost
nothing in xusb,
.... so: not a serial number, but the relevant function now does return
string values.
So the problem must be in some deeper code,  I think.

The current Windows backend support HID and WinUSB. So if the
device is using HID driver or WinUSB driver, you are fine.

Please also refer to my other reply. If your device is using other driver,
like USB mass storage device, then the control transfer will fail since
it can not claim the interface.

I am not so sure if we can use other methods to get the strings
other than control transfer. My feeling is that it should be possible.
Pete or other can probably give you a better answer. But then the
change is related to the libusb core.

BTW: I can confirm that libusb-win32 does work, but I really prefer to stay
in user land as the systems involved are in a not easily reachable
production environment already.

I can understand this. You probably do not want to use the device driver.
Then you will have to use the filter driver which is not really recommended
to be deployed to end users.

[Bram Bouwens]

Post by Xiaofan Chen

I tried that. It doesn't help. It's the libusb_get_string_descriptor_ascii
that returns the error
"libusb:error [composite_submit_control_transfer] no libusb supported
interfaces to complete request" message.

Yes you are right.

Interesting enough, I also have a Cruzer (0781:5204) which produces almost
nothing in xusb,
.... so: not a serial number, but the relevant function now does return
string values.
So the problem must be in some deeper code, I think.

The current Windows backend support HID and WinUSB. So if the
device is using HID driver or WinUSB driver, you are fine.
Please also refer to my other reply. If your device is using other driver,
like USB mass storage device, then the control transfer will fail since
it can not claim the interface.

Well, I can't say what driver a Logitech webcam would use. For Linux it
uses uvc
but for Windows ... Maybe I could get useful information out of
libusb-win32 if
I knew better what I'm looking for.

Post by Xiaofan Chen
I am not so sure if we can use other methods to get the strings
other than control transfer. My feeling is that it should be possible.
Pete or other can probably give you a better answer. But then the
change is related to the libusb core.

BTW: I can confirm that libusb-win32 does work, but I really prefer to stay
in user land as the systems involved are in a not easily reachable
production environment already.

I can understand this. You probably do not want to use the device driver.
Then you will have to use the filter driver which is not really recommended
to be deployed to end users.

Indeed. My feeling is that the libusb solution is the best bet. Finding
an experienced
Windows hacker to make a "native" solution could also work, to me it
just looks too
intimidating.


Bram

[Pete Batard]

Post by Xiaofan Chen

I tried that. It doesn't help. It's the libusb_get_string_descriptor_ascii
that returns the error
"libusb:error [composite_submit_control_transfer] no libusb supported
interfaces to complete request" message.

Yes you are right.

Sorry to jump late in the game. Indeed, the only way for the Windows
backend to issue a control transfer with a composite device is if that
composite device has an interface with a driver that can issue transfers
(currently only HID or WinUSB).

If you get a report of no supported drivers being found during
enumeration, control transfers will not be possible. There might exist a
way to talk to a composite devices directly, using the usbccgp driver,
but we don't have anything like that in the code right now.

Regards,

/Pete

[Peter Stuge]

Post by Pete Batard
If you get a report of no supported drivers being found during
enumeration, control transfers will not be possible.

The assumption before Windows support was that an open device handle
would actually always allow a control transfer to endpoint 0. This
fits the USB spec well.

Should we maybe fail sooner on Windows than we do now when that isn't
possible?


//Peter

[Pete Batard]

Post by Peter Stuge
Should we maybe fail sooner on Windows than we do now when that isn't
possible?

I'll have to see how we can do that in new enum, as this failure would
occur in enum, and that's the part of the code I'm redoing right now.

I'll look into it.

Regards,

/Pete

[Bram Bouwens]

Post by Pete Batard

Post by Xiaofan Chen

I tried that. It doesn't help. It's the libusb_get_string_descriptor_ascii
that returns the error
"libusb:error [composite_submit_control_transfer] no libusb supported
interfaces to complete request" message.

Yes you are right.

Sorry to jump late in the game. Indeed, the only way for the Windows
backend to issue a control transfer with a composite device is if that
composite device has an interface with a driver that can issue transfers
(currently only HID or WinUSB).

So if I understand this correctly, it will be

#49: Support libusb0.sys in the Windows backend

that will provide the functionality that I want. But that will also
require installing this .sys into Windows, like on libusb-win32?
In turn requiring a signature? The most viable option I guess then.

Post by Pete Batard
If you get a report of no supported drivers being found during
enumeration, control transfers will not be possible. There might exist a
way to talk to a composite devices directly, using the usbccgp driver,
but we don't have anything like that in the code right now.

I have some doubts that I'd get that working myself in the foreseeable
future :D

Post by Pete Batard
Regards,
/Pete

Regards, Bram

[Pete Batard]

Post by Bram Bouwens
So if I understand this correctly, it will be
#49: Support libusb0.sys in the Windows backend
that will provide the functionality that I want.

Not really. Just like WinUSB, libusb0.sys would be installed for the
interfaces, unless you install the driver in place of the composite
parent driver, but in that case your whole composite device can only be
accessed by libusb, so in effect, this is as if you set each interface
to use WinUSB.

The use of libusb0.sys will be exactly similar to use the use of WinUSB
that we have in libusb right now. libusb0.sys offers greater control
over some USB properties than WinUSB, but the process to access a device
with libusb0.sys will still the same, and this won't change access to
devices with multiple interfaces.

If you want to give it a try, you can use the Zadig driver installer
application (if you set it to list hubs and composite parents) to
replace the driver for your composite device with WinUSB, and that will
allow you to issue control transfer. But as indicated, then you can only
use your device with a libusb (or WinUSB) application.

Post by Bram Bouwens
But that will also
require installing this .sys into Windows, like on libusb-win32?
In turn requiring a signature?

There's no need to worry about signature for either the current
libusb0.sys or WinUSB. All these drivers are signed.

Regards,

/Pete

[Bram Bouwens]

Post by Pete Batard

Post by Bram Bouwens
So if I understand this correctly, it will be
#49: Support libusb0.sys in the Windows backend
that will provide the functionality that I want.

Not really. Just like WinUSB, libusb0.sys would be installed for the
interfaces, unless you install the driver in place of the composite
parent driver, but in that case your whole composite device can only be
accessed by libusb, so in effect, this is as if you set each interface
to use WinUSB.

Oh, a misconception from my side then. My impression was that using
a libusb0.sys was the reason why the equivalent request worked fine
on libusb-win32. But I guess that was wrong.

Post by Pete Batard
The use of libusb0.sys will be exactly similar to use the use of WinUSB
that we have in libusb right now. libusb0.sys offers greater control
over some USB properties than WinUSB, but the process to access a device
with libusb0.sys will still the same, and this won't change access to
devices with multiple interfaces.
If you want to give it a try, you can use the Zadig driver installer
application (if you set it to list hubs and composite parents) to
replace the driver for your composite device with WinUSB, and that will
allow you to issue control transfer. But as indicated, then you can only
use your device with a libusb (or WinUSB) application.

That sounds like it's not so obvious that receiving the images would
still work? I'm a little hesitant there ...

Regards,


Bram

[Peter Stuge]

My impression was that using a libusb0.sys was the reason why the
equivalent request worked fine on libusb-win32. But I guess that
was wrong.

You are correct, but besides libusb0.sys which is not yet supported
by libusb-1.0 it is also possible to use the WinUSB.sys driver from
Microsoft for libusb to work. WinUSB.sys is supported by libusb-1.0
and that works right now. #49 is about also adding support for the
libusb0.sys driver to libusb-1.0, so that libusb-1.0 will have all(?)
features of libusb-win32.

[Bram Bouwens]

Post by Xiaofan Chen

Post by Xiaofan Chen

Post by Xiaofan Chen
I will try out xusb later. Maybe it has a bug in terms of getting
the serial number judging from your debug log.

Oops, I got worse result than you.

On the other hand, the current xusb code has the claiming
interface codes before getting the string descriptors. I think
this is related to your problem.
What if you try to remove the claiming interface code?
/* comment out the following codes or move them after the string
descriptor reading codes
for (iface = 0; iface< nb_ifaces; iface++)
{
printf("\nClaiming interface %d...\n", iface);
r = libusb_claim_interface(handle, iface);
#ifdef OS_LINUX
if ((r != LIBUSB_SUCCESS)&& (iface == 0)) {
// Maybe we need to detach the driver
perr(" Failed. Trying to detach driver...\n");
libusb_detach_kernel_driver(handle, iface);
iface_detached = iface;
printf(" Claiming interface again...\n");
r = libusb_claim_interface(handle, iface);
}
#endif
if (r != LIBUSB_SUCCESS) {
perr(" Failed.\n");
}
}
*/
printf("\nReading string descriptors:\n");
for (i=0; i<3; i++) {
if (string_index[i] == 0) {
continue;
}
if (libusb_get_string_descriptor_ascii(handle, string_index[i],
string, 128)>= 0) {
printf(" String (0x%02X): \"%s\"\n", string_index[i], string);
}
}

I tried that. It doesn't help. It's the
libusb_get_string_descriptor_ascii that returns the
error "libusb:error [composite_submit_control_transfer] no libusb
supported interfaces to complete request"
message.

Interesting enough, I also have a Cruzer (0781:5204) which produces
almost nothing in xusb,
but otoh a Logitech keyboard:

Reading device descriptor:
length: 18
device class: 0
S/N: 0
VID:PID: 046D:C313
bcdDevice: 0100
iMan:iProd:iSer: 1:2:0
nb confs: 1

Reading configuration descriptors:
nb interfaces: 2
interface[0].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.01.01
endpoint[0].address: 81
max packet size: 0008
polling interval: 0A
interface[1].altsetting[0]: num endpoints = 1
Class.SubClass.Protocol: 03.00.00
endpoint[0].address: 82
max packet size: 0008
polling interval: 0A

Reading string descriptors:
String (0x01): "BTC"
String (0x02): "USB Multimedia Keyboard"

Reading HID Report Descriptors:

06 A0 FF 09 01 A1 01 09 01 15 00 25 FF 75 08 95
01 81 00 C0

Skipping Feature Report readout (None detected)

.... so: not a serial number, but the relevant function now does return
string values.
So the problem must be in some deeper code, I think.

BTW: I can confirm that libusb-win32 does work, but I really prefer to stay
in user land as the systems involved are in a not easily reachable
production
environment already.


Bram