[Libusb-devel] LIBUSB_ERROR_NOT_FOUND

[Qui]

What does this error mean when I call libusb_set_configuration()?

"LIBUSB_ERROR_NOT_FOUND

Entity not found. "

[Pete Batard]

Post by Qui
What does this error mean when I call libusb_set_configuration()?
"LIBUSB_ERROR_NOT_FOUND
Entity not found. "

If you are using the Windows backend and your device is WinUSB, this
error can be returned if you didn't claim an interface first.
Can you post an excerpt from the code you use where you call
libusb_set_configuration?

Also note that on Windows, set_configuration is not expected to work,
because of the Windows OS restrictions (but we still attempt to send the
control request just in case).

Regards,

/Pete

[Qui]

Post by Pete Batard

Post by Qui
What does this error mean when I call libusb_set_configuration()?
"LIBUSB_ERROR_NOT_FOUND
Entity not found. "

If you are using the Windows backend and your device is WinUSB, this
error can be returned if you didn't claim an interface first.
Can you post an excerpt from the code you use where you call
libusb_set_configuration?
Also note that on Windows, set_configuration is not expected to work,
because of the Windows OS restrictions (but we still attempt to send the
control request just in case).
Regards,
/Pete
------------------------------------------------------------------------------

I found this on libusb online doc:

LIBUSB_ERROR_NOT_FOUND if the requested configuration does not exist

I wrote a program in python using pyusb that used to use libusb 0.1, so now I'm
testing to see if the program still runs with the latest snapshot of libusb 1.0
for windows. I'll do some more tracing to see what's wrong.

[Pete Batard]

This post might be inappropriate. Click to display it.

[Qui]

Post by Pete Batard
I just ran a test on my end to see what happened when issuing a
set_configuration before claim_interface, and I got the
LIBUSB_ERROR_NOT_FOUND code.
Now, independently of your issue, I believe we have an actual problem in
the Windows backend, so the following is addressed to the libusb
The libusb doc states "It is up to your application to ensure the
correct configuration is selected before you attempt to claim interfaces
and perform other operations" which conflicts with the current Windows
backend expectation (with autoclaim disabled) of having an interface
claimed to attempt to send a LIBUSB_REQUEST_SET_CONFIGURATION request.
This seems like this is the actual issue behind the set_configuration
problem we had with brltty earlier.
1. re-enabling autoclaim, and leaving the option set as default.
2. dropping the control request for set_configuration and returning
LIBUSB_ERROR_NOT_SUPPORTED.
Remember that the Windows USB API does not offer the possibility to send
a SET_CONFIGURATION request unless an interface has been initialized.
Now 1. has the advantage of enabling easy porting of Linux/OS-X libusb
code to Windows, with no or little modification of the libusb related
sections. It also allows devices that expect an actual set_configuration
request to actually receive it, even if Windows is unable to switch
configurations on the fly.
The drawback is that, when porting libusb code from Windows back to
other platforms, autoclaim would be missing, and the missing
claim_interface calls would need to be added.
2. has the advantage of not breaking the upcoming Windows->Linux libusb
code porting compatibility, and if we expect most of the existing code
ported to Windows to handle set_configuration error messages, things
should be OK. On the other hand, it means set_configuration messages
will never be seen by the device on Windows (at least the ones expected
to be sent by the application), and if those are used to
reset/reinitialize some device properties, this could mean trouble.
Do you guys have a view on this?
Regards,
/Pete
------------------------------------------------------------------------------

I stopped calling set_configuration and just make sure I claim the interface of
the device, so far so good...I stopped trying to create a method in pyusb that
uses libusb_get_string_descriptor_ascii

but instead use this method posted by someone from pyusb mailing list:

def getStringDescriptor(device, index):
"""
"""
response = device.ctrl_transfer(usb.util.ENDPOINT_IN,
usb.legacy.REQ_GET_DESCRIPTOR,
(usb.util.DESC_TYPE_STRING << 8) | index,
0, # language id
255) # length

# TODO: Refer to 'libusb_get_string_descriptor_ascii' for error handling

return response[2:].tostring().decode('utf-16')

So far the program is communicating with the device fine without too much
modifications moving from libusb 0.1

I just dropped in the libusb 1.0 DLL file in system32 and use it directly
without any problems yet.

[Xiaofan Chen]

Post by Pete Batard
1. re-enabling autoclaim, and leaving the option set as default.
2. dropping the control request for set_configuration and returning
LIBUSB_ERROR_NOT_SUPPORTED.
Remember that the Windows USB API does not offer the possibility to send
a SET_CONFIGURATION request unless an interface has been initialized.
Now 1. has the advantage of enabling easy porting of Linux/OS-X libusb
code to Windows, with no or little modification of the libusb related
sections. It also allows devices that expect an actual set_configuration
request to actually receive it, even if Windows is unable to switch
configurations on the fly.

Windows probably do not like dual configuration device. But it is
possible to switch configuration, at least if you use libusb-win32
device driver.

Post by Pete Batard
The drawback is that, when porting libusb code from Windows back to
other platforms, autoclaim would be missing, and the missing
claim_interface calls would need to be added.

Why? Just advertise that libusb_claim_interface() is necessary to
be called.

Post by Pete Batard
2. has the advantage of not breaking the upcoming Windows->Linux libusb
code porting compatibility,

It is just the internal behavior. If you tell the user that
libusb_claim_interface()
is necessary to be called, then it is the same.

Post by Pete Batard
and if we expect most of the existing code
ported to Windows to handle set_configuration error messages, things
should be OK. On the other hand, it means set_configuration messages
will never be seen by the device on Windows (at least the ones expected
to be sent by the application), and if those are used to
reset/reinitialize some device properties, this could mean trouble.
Do you guys have a view on this?

I vote for 1 -- re-enable autoclaim. As Alan mentioned in the other
thread, it is good to automatic claim the interface in the case of
control request.

2 is not very good for libusb0.sys backend (for the future).