Discussion:
[Libusb-devel] Can't write to a device
Brad Schick
2007-10-23 23:47:21 UTC
Permalink
I have a usbhid device that I am using libusb (actually pyusb) to
communicate with. The first problem I had was the device always being
busy when claiming an interface. I solved that by unbinding the kernel
usbhid driver with:

echo -n "2-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind

That at least lets me open the device and claim the interface from my
application. But when I try to do an interrupt_write to an endpoint I
get the following error.

usb.USBError: error submitting URB: No such file or directory

Another strange thing is that if I try to rebind the usbhid driver with:

echo -n "2-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind

I get the following error:

bash: echo: write error: No such device

But I can see that the device is still listed under
/sys/bus/usb/devices, and it is not bound to a driver.
tree 2-1\:1.0
2-1:1.0
|-- bAlternateSetting
|-- bInterfaceClass
|-- bInterfaceNumber
|-- bInterfaceProtocol
|-- bInterfaceSubClass
|-- bNumEndpoints
|-- bus -> ../../../../../../bus/usb
|-- ep_04 -> ../../../../../../class/usb_endpoint/usbdev2.3_ep04
|-- ep_83 -> ../../../../../../class/usb_endpoint/usbdev2.3_ep83
|-- modalias
|-- power
| |-- state
| `-- wakeup
|-- subsystem -> ../../../../../../bus/usb
|-- uevent
|-- usb_endpoint:usbdev2.3_ep04 ->
../../../../../../class/usb_endpoint/usbdev2.3_ep04
`-- usb_endpoint:usbdev2.3_ep83 ->
../../../../../../class/usb_endpoint/usbdev2.3_ep83


Any suggestions? I'm fairly new to usb development, so I'm not sure
where to get more info. I haven't found any logs with info or much by
searching the net. I am running Ubuntu 7.10 32bit, kernel
2.6.22-14-generic, libusb 0.1.12-7, python-pyusb 0.3.5-4.


Thanks,
-Brad
Tim Roberts
2007-10-23 23:57:50 UTC
Permalink
Post by Brad Schick
I have a usbhid device that I am using libusb (actually pyusb) to
communicate with. The first problem I had was the device always being
busy when claiming an interface. I solved that by unbinding the kernel
echo -n "2-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind
libusb has a call to do this: usb_detach_kernel_driver_np. I don't
know if pyusb exposes that.

Do you know there is a libhid designed specifically for talking to HID
devices? It has a Python binding.
Post by Brad Schick
That at least lets me open the device and claim the interface from my
application. But when I try to do an interrupt_write to an endpoint I
get the following error.
usb.USBError: error submitting URB: No such file or directory
What endpoint were you trying to write to? It should be endpoint 4,
based on your tree.
--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.
Brad Schick
2007-10-24 00:29:02 UTC
Permalink
This post might be inappropriate. Click to display it.
Tim Roberts
2007-10-24 19:22:14 UTC
Permalink
Post by Tim Roberts
What endpoint were you trying to write to? It should be endpoint 4,
based on your tree.
Yes, sending 8 bytes to EP4.
Also FYI, the device is an Atmel CPU running some sample HID firmware
from them. It works under window, but I'm not sure how well it's been
tested under Linux.
Shouldn't matter. USB is USB, no matter what's blowing on the other end
of the pipe. Or sucking, in the case of Windows. ;)
Post by Tim Roberts
In particular I am wondering if the device is getting into a bad state
somehow after the linux driver is unbound. It seems odd that I can't
simply unbind and bind it. Any feedback about how to get more data out
of linux and/or libusb? Beyond that, the next step is to start hacking
the firmware.
Binding and unbinding a driver shouldn't have any effect on the device.
The driver will read the report descriptors, but it shouldn't change any
state. However, I have occasionally had troubles rebinding the standard
driver after a talking to a device, so I wouldn't sweat about that yet.

So, you're still getting "no such file or directory" after unbinding the
HID driver? You're sending an interrupt request, right?
--
Tim Roberts, ***@probo.com
Providenza & Boekelheide, Inc.
Brad Schick
2007-10-24 21:11:21 UTC
Permalink
Post by Tim Roberts
Post by Tim Roberts
In particular I am wondering if the device is getting into a bad state
somehow after the linux driver is unbound. It seems odd that I can't
simply unbind and bind it. Any feedback about how to get more data out
of linux and/or libusb? Beyond that, the next step is to start hacking
the firmware.
Binding and unbinding a driver shouldn't have any effect on the device.
The driver will read the report descriptors, but it shouldn't change any
state. However, I have occasionally had troubles rebinding the standard
driver after a talking to a device, so I wouldn't sweat about that yet.
So, you're still getting "no such file or directory" after unbinding the
HID driver? You're sending an interrupt request, right?
Yes, and yes. Can anyone recommend a usb bus monitor that might help me
figure out what is going on? Also is there a way to prevent the kernel
from binding to the device in the first place, just to see what happens?

-Brad
Xiaofan Chen
2007-10-25 00:07:03 UTC
Permalink
Post by Brad Schick
I have a usbhid device that I am using libusb (actually pyusb) to
communicate with. The first problem I had was the device always being
busy when claiming an interface. I solved that by unbinding the kernel
echo -n "2-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind
That at least lets me open the device and claim the interface from my
application. But when I try to do an interrupt_write to an endpoint I
get the following error.
usb.USBError: error submitting URB: No such file or directory
echo -n "2-1:1.0" > /sys/bus/usb/drivers/usbhid/unbind
bash: echo: write error: No such device
But I can see that the device is still listed under
/sys/bus/usb/devices, and it is not bound to a driver.
Any suggestions? I'm fairly new to usb development, so I'm not sure
where to get more info. I haven't found any logs with info or much by
searching the net. I am running Ubuntu 7.10 32bit, kernel
2.6.22-14-generic, libusb 0.1.12-7, python-pyusb 0.3.5-4.
What does "lsusb -v" say?

And try to disable auto-suspend by recompiling the kernel. You
may have a firmware bug which does not handle suspend-resume
properly. This may or may not be your problem.

Loading...