Even with the latest cups 1.4.1, my printer (Lexmark Optra M412 connected via USB) regularly hangs while or after prining the first job. At best, power cycling (or disconnecting and reconnecting) the printer and restarting cupsd helps (however, the hanging job is lost), at worst, a reboot is needed. Although the cups 1.4.1 release notes say that this problem is fixed, it is not. The problem also occurs in other distributions (see e.g. archlinux 15998). Debian has developed a patch for it in its cups 1.4.1-4 package (see their bugs 546558, 545288, 545453): cups (1.4.1-4) unstable; urgency=low [ Till Kamppeter ] * debian/patches/usb-backend-both-usblp-and-libusb.dpatch: Make the USB backend supporting both printer access via libusb and via the usblp kernel module. Make it also printing via libusb if the URI for the queue was generated via usblp and vice versa. This should solve most USB printing problems which occured on the transition to CUPS 1.4.x (LP: #420015, LP: #436495; Closes: #546558, #545288, #545453). [ Martin Pitt ] * debian/rules: Make the USB backend run as root again, udev rules do not cover all printers. (LP: #420015) * Drop debian/blacklist-cups.conf, and remove it on upgrade. With Till's fix from above this is not necessary any more. -- Martin Pitt <mpitt@debian.org> Wed, 30 Sep 2009 15:17:53 +0200 Could we *please* have an ebuild including these patches? Being able to use the old and proven usblp would really help a lot!
Actually, the solution is much simpler: I don't need both backends (usblp and libusb). The old usblp backend (which is still automatically built and used if cups is configured with "--disable-libusb") is all I need, it works perfectly fine for me. Hence, just a small modification to the ebuild is necessary to fix all my problems: Introduce an USE flag "usblp" (or "oldusb") (or "libusb" or "newusb" if you want to have it the other way round) which switches between the configure options "--enable-libusb" and "--disable-libusb".
I seem to be running into similar problems here with my Canon Pixma MP150 and HP DJ6122 - both usb connected. The printers were configured some time ago, when there was still cups-1.3.x and usblp. After the cups upgrade to 1.4.1 and after removing the usblp kernel module they just stopped working, no error ever appeared in any log file. But neiter rebooting nor restarting the printer solved the problem. So I downgraded to 1.3. Some time and some world emerges later I tried 1.4.1 again (assuming that the problem was rather in some other part of the printing chain), and it magically worked again ... until the upgrade to 1.4.2. Which left me with downgrading to 1.3 again. I am very much under the impression that the raw usb device access method of cups is far from stable at the moment.
Recompiling cups with "--disable-libusb" then modprobe usblp was the solution for me
--disable-libusb is the solution. But I don't want to hack the ebuild every time. As noted earlier, could we *please* have an USE flag for --disable-libusb?!
Ups, just noticed that the USE flag already is in cups-1.4.3.ebuild, and it is called "usb". So emerging cups with USE="-usb" gives 1.3.x USB behaviour (works for me...).
same problem http://bugs.gentoo.org/show_bug.cgi?id=323931
Nope(In reply to comment #6) > same problem > > http://bugs.gentoo.org/show_bug.cgi?id=323931 > @Francisco Javier That is different bug. This one is about properly detected and configured printer, but cups hanging after first print job. Also this problem exists when using net-print/splix (Open drivers for Samsung SPL printers) on Samsung ML-1510, with cups utilizing libusb.
(In reply to comment #7) > Also this problem exists when using net-print/splix (Open drivers for Samsung > SPL printers) on Samsung ML-1510, with cups utilizing libusb. Maciej, while I'm testing this could you report this issue on splix package? It should depend on cups[-usb] I think.
We're not going to provide the debian patch but follow upstream cups. Please try cups-1.5.
