Re: [libusb] Can't write to a control endpoint in libusb-1.0.16_RC10, when bulk transfer (printing) is going on in interface 0

[Hans de G. <hde...@re...>]

Hello Sanjay,

On 06/20/2013 08:24 AM, Kumar, Sanjay wrote:
> Hello All,
>
> I am working for HP Linux printer driver (HPLIP team ). Recently I found one issue in libusb-1.0.16RC release. I Can't write on a  control endpoint in libusb-1.0.16_RC10, when bulk transfer (printing) is going on in interface 0. I have created a ticket also regarding the same but I can’t see it in the active tickets.

I've a HP printer (PSC 1350) myself, so I've tried to reproduce
this, but I could not reproduce. Still I've a hunch of what is going on:


1) First of all, next time, and in your next mail, please include:
-Actual output of your test program, esp. the error code given by
the libusb_control_transfer would be useful, I bet it is LIBUSB_ERROR_BUSY
-lsusb -v output for the device in question
-relevant messages in dmesg if any


2) Your getdeviceID.c is buggy, my printer has a device-id length > 127 bytes
and bad things happen because of sign extension, and you use memcpy where you
should memmove, fixed version attached. Also if it fails to claim the interface
(which I think it does), the program should stop, continuing after that point is
useless.


3) Are you sure that interface 0 is the right interface? On my printer interface 0
is a vendor interface, where as interface 1 is the actual printerclass interface,
and the getvendorid call should be made on the printerclass interface. Note that
it seems to work fine on both interface with my printer, ie both a wIndex of
0 and of (1 << 8) work. Note that the requested lsusb -v info will tell for sure.


4) In case of using 1 << 8 the usblp driver must first be detached from interface 1,
since the linux kernel knows about the special wIndex usage for printerclasses, and
looks at the upper 8 bits to determine which interface the ctrl req will apply too,
and that must be claimed for the ctrl-req to be allowed (and thus the driver must be
detached).

5)

> 3) When printing is happening
>
> *libusb_kernel_driver_active()* returns 1 even after*libusb_detach_kernel_driver(hd, 0)* call is made. Please see the attached code also.

Ah yes, this is a bug, which also explains what is going on, recent libusb code does
not detach the kernel driver if it is usbfs, since then no other kernel driver is
attached, but another userspace app is using it, and we don't want to interfere
with that (detaching the kernel driver sometimes is a must, killing another userspace
apps access is not).

I've just pushed a bug-fix to libusbx git master fixing libusb_kernel_driver_active()
to properly return 0 when the device is in use from userspace by another app.


6) As said this also explains what is going on, when printing another userspace app has
the interface in question in use. I assume this is either something from cups, or
some other part of hplip, so you will need to either wait and retry, or implement
some proper locking; or ...


7) As said you seem to be operating on the wrong interface, which actually is a good thing,
because detaching the usblp kernel driver while printing will likely kill the print job
halfway through, not good.

Detach kernel drivers is something which you should not do without very good reasons in
general. In this case there is a better solution, there is a ieee1284_id file in sysfs
which contains the exact string you're looking for, and you can get that without needing
any special rights in usbfs, or without needing to detach the driver, ie when I turn
on my printer, dmesg contains:

[ 9643.182911] usblp 2-1.7:1.1: usblp0: USB Bidirectional printer dev 7 if 1 alt 0 proto 2 vid 0x03F0 pid 0x3B11

So 2-1.7:1.1 is the printer class interface of my printer, and now I can get the device-id by
a simple:

cat /sys/bus/usb/devices/2-1.7:1.1/ieee1284_id

You should seriously consider using this sysfs file, that seems a much better solution to
your problem, without the need to coordinate (detach / claim / lock) with any other users
of the printer.


8) Note that the libusbx and libusb projects are merging back together, and all development
is happening in libusbx git atm, you can find the latest code here:
https://github.com/libusbx/libusbx

I don't expect this to fix your problem, other then the libusb_kernel_driver_active()
returning 1 when the device is in use from userspace by another app bug.

Also as said, if I were you I would just abandon the whole libusb approach and use
sysfs instead.


Regards,

Hans