Ken Moffat wrote:
>  I'm intending to change the cups page in the book, to remove the
>
> Note which says:
> | There is a conflict between the Cups libusb backend and the usblp
> | kernel driver. If you want to use Cups with libusb, do not enable
> | USB Printer support in your kernel.
>
>  But since most people don't read blfs-dev, I'm asking here first -
> in case there are any different opinions.  Sorry for the length of
> thii
>
>  I (occasionally) use an Epson Stylus Photo R360.  Until October I
> had _always_ used the kernel usblp driver - as a module - instead of
> libusb.  I can vaguely remember that Greg KH reported an "unable to
> print" problem on lkml several years ago, and that the usblp driver
> appeared to have come into conflict with libusb (presumably, libusb
> had changed).  I guess that is what eventually triggered the Note.
>
>  In October, I was building _everything_ to test make-4.0.  On my
> second such build (all the things I couldn't conveniently fit into
> the main build), I tried adding libusb (strictly, it is now called
> libusbx and produces libusb-1.0.pc, libusb.pc comes from
> libusb-compat) and dropping the kernel usblp printer.  I was pleased
> that printing still worked, because this will allow me to reinstate
> colord - libusb is. or at least was, a recommended dependency - and
> will let me install usbutils (lsusb might be useful for debugging
> kernel problems).
>
>  But earlier this month I wanted to check my ink levels whilst I
> happened to be using that system.  To do that I use escputil from
> gutenprint, but it needs /dev/usb/lpX (i.e. you can only run it on
> the machine the printer is connected to) and that device is provided
> for the kernel usb printer driver.  If CONFIG_USB_PRINTER is turned
> off, /dev/usb/lpX will not be created by whichever flavour of udev
> is being used.  So, a build "by the book" does not let me check my
> ink levels. :-(
>
>  So, first I tried what had been recommended in the past in other
> distros - build usblp as a module, and perhaps try to modprobe it to
> check the ink levels, and then rmmod it before printing.  I built it
> as a module with 3.13.0: it gets installed as soon as I connect the
> printer, ink levels are reported, and I am able to print _without_
> removing the module.
>
>  Testing with usblp built-in has taken a little longer (only this
> one system has libusbx, no newer released kernels to test), but
> tonight I've built it into 3.12.9 and confirmed that both escputil
> and printing still work.
>
>  I assume that changes in libusb, perhaps as part of the move to
> libusbx, solved the original problem.  But printing on BLFS has
> always given problems for some people - often because different
> printers are just _different_ - so before I drop the note from
> the book I'll give everyone a chance to express any concerns.
>
>  Additional notes:
>
> 1. Escputil probably only works on non-multifunction Epson stylus
> printers.
>
> 2. I don't have any printers of other brands on which to test this.

There is a feature to unbind a driver from a device. AFAIK libusb does exactly 
that: detach the printer from the usblp kernel driver, runs the transfers 
to/from the printer and then attach the kernel printer driver with the 
printer device again (should be visible in the kernel logs if that happens) 
[1].
But this works only if you try to access the printer via libusb from userspace 
from time to time. I think running a daemon doing so, will never attach the 
printer device to the kernel printer driver again.

jbe

[1] from libusb.h:
int libusb_detach_kernel_driver(libusb_device_handle *dev, int interface);
int libusb_attach_kernel_driver(libusb_device_handle *dev, int interface);
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to