My printer does not work with the new cupd-1.4 usb backend. I had the following issues: The new usb backend in cups-1.4 does not use the usblp kernel module anymore (actually it requires that it is not loaded) so I had to add that module to /etc/modprobe.d/blacklist.conf Next the udev rules for my printer (Canon PIXMA MP520) creates /dev/bus/usb/001/005 with the following permissions: crw-rw-r-- 1 root scanner 189, 5 Sep 16 10:08 005 (the permissions come from /etc/udev/rules.d/70-libsane.rules because my printer is one of these multi-function devices which also contains a scanner). However cups cannot access the device because the device belongs to the scanner group. However changing the group to lp and everything works fine. I don't know the best approach to fix the group issue since the device is both a scanner and a printer... Reproducible: Always Portage 2.1.6.13 (default/linux/amd64/2008.0, gcc-4.3.4, glibc-2.10.1-r0, 2.6.31-gentoo x86_64) ================================================================= System uname: Linux-2.6.31-gentoo-x86_64-Intel-R-_Atom-TM-_CPU_230_@_1.60GHz-with-gentoo-2.0.1 Timestamp of tree: Tue, 15 Sep 2009 20:45:02 +0000 app-shells/bash: 4.0_p33 dev-java/java-config: 1.3.7-r1, 2.1.9 dev-lang/python: 2.4.4-r15, 2.5.4-r2, 2.6.2-r1, 3.1.1 dev-python/pycrypto: 2.0.1-r8 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.4.3-r3 sys-apps/sandbox: 2.1 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=nocona -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo/ http://ftp.linux.ee/pub/gentoo/distfiles/ ftp://ftp.linux.ee/pub/gentoo/distfiles/ http://trumpetti.atm.tut.fi/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ " LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac acl alac amd64 apache apache2 berkdb bzip2 cairo cli cracklib crypt cups dbus domainkeys dri encode exiscan exiscan-acl ffmpeg firefox flac fortran gd gdbm gnome gocr gpm iconv imagemagick imap ipv6 isdnlog jpeg lame logrotate maildir mmx mp3 mp520 mpeg mudflap multilib mysql ncurses netpbm nls nntp nptl nptlonly objc ocrad ogg openmp pam pcre perl png pop3d ppds pppd python readline reflection scanner session spl sse sse2 ssl stream svg sysfs tcpd tordns unicode usb utf8 vhosts x264 xattr xml xorg xulrunner xvid zlib" ALSA_CARDS="intel_hda" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" SANE_BACKENDS="pixma" USERLAND="GNU" VIDEO_CARDS="i810" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Just added a link to the corresponding ubuntu bug.
Just another thing. I guess the printing howto should also be updated with the correct information regarding configuring ones kernel: http://www.gentoo.org/doc/en/printing-howto.xml#usb
CC'ing udev guys, apparently the udev rules issue has been fixed in upstream git with following commit: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=f61e72d8973cf9d889a4f1233150870085c0b3e1 Also attaching an updated blacklist.conf to prevent loading of the usblp module. Not quite sure about the sane stuff yet, since the rule loads afterwars, but lets first fix normal usb printers.
Created attachment 204317 [details, diff] blacklist-147.diff
*** Bug 285366 has been marked as a duplicate of this bug. ***
Well, the permission rule is fine as it is. Should we backport this to udev-145 or is it enough to have it when (to be released) udev-147 enters the tree? The blacklist is something I do not want to add to default udev. I think users should either not compile usblp when they do not need it or blacklist it themselves. So at first I think the cups ebuild should be more verbose about this issue. We still can add a disabled blacklist entry that the user needs to uncomment only. This can also be installed by the cups ebuild. But do not blacklist it by default.
(In reply to comment #6) > Well, the permission rule is fine as it is. > Should we backport this to udev-145 or is it enough to have it when (to be > released) udev-147 enters the tree? A backport would be great, since it affects quite a few ~testing users. > The blacklist is something I do not want to add to default udev. I think users > should either not compile usblp when they do not need it or blacklist it > themselves. > So at first I think the cups ebuild should be more verbose about this issue. I'll see what I can do about it, thanks for your suggestion. > We still can add a disabled blacklist entry that the user needs to uncomment > only. Would be fine by me. > This can also be installed by the cups ebuild. But do not blacklist it by > default. Is there any other ebuild around messing with the blacklist.conf already? If not I'd prefer to have the rule distributed by udev. On the other hand if it's installed by cups it could default to blacklist the module only for cups >=1.4. I'll try to show up on irc later this day, I'm sure we can figure something out. :)
(In reply to comment #7) > (In reply to comment #6) > > Well, the permission rule is fine as it is. > > Should we backport this to udev-145 or is it enough to have it when (to be > > released) udev-147 enters the tree? > > A backport would be great, since it affects quite a few ~testing users. will be in udev-146 then > > > We still can add a disabled blacklist entry that the user needs to uncomment > > only. > > Would be fine by me. > > > This can also be installed by the cups ebuild. But do not blacklist it by > > default. > > Is there any other ebuild around messing with the blacklist.conf already? If To clearify this: The filename "blacklist.conf" is arbitrary. You can place blacklist entries in any file matching /etc/modprobe.d/*.conf
Added disabled blacklist entry and libusb device node permissions to udev-146.
I have a kyocera FS-1020D printer. After emerging the new udev-146 and unloading usblp, the printer does still not work with cups-1.4
The issue with the permissions on the /dev/bus/usb/*/* device for the printer has not been fixed. My device file is stille owned by root:scanner with permissions crw-rw-r-- Hence cups cannot access it. For cups to be able to access it, the group lp should be able to access the device, since the cups deamon runs as group lp.
Hi, Same here with my Epson RX-500 (which is also a scanner, hence the problem). Anyway, and just for the record: regardless of this issue, I can still print with CUPS 1.x by using 'usblp' and manually changing the printer connection URI to "file:///dev/usblp0" in /etc/cups/printers.conf. The only drawback is that, as soon as I turns on the printer it re-detects it as a new instance of the same printer, but I just ignore it. The manually configured one keeps running fine.
Have to agree about the scanner/printer issues. My Epson DX9400F All-in-One printer is recognized as a scanner first, so the device is owned by root:scanner. Works like a charm for scanning, but it can't print. now if I change the ownership to root:lp, as you would expect, the printer works, but of course: no chance to scan anymore.... If I give access to all users, both work, but the whole security idea is compromised... I guess there is a need for some more sophisticated group merging stuff to be done for accessing printing/scanning peripherals. Maybe a special use flag should be introduced for the scanning backends, cups and udev, which allows to use a common "peripherals" group for devices and executables, in case such an all-in-one usb device is in use...
I had the same problem... turing 001 # ls -la total 0 drwxr-xr-x 2 root root 80 Oct 17 23:05 . drwxr-xr-x 7 root root 140 Oct 17 22:34 .. crw-rw-r-- 1 root usb 189, 0 Oct 17 22:34 001 crw-rw---- 1 root scanner 189, 41 Oct 17 23:05 042 After turing 001 # chmod 777 042 Now CUPS recognizes the printer... something must be done to solve this issue.
I have a slightly different angle. I disabled the usblp kernel module and my Canon iP4000 works fine with Cups-1.4.1, however I also use the Ink/libinklevel utilities to monitor the printer ink cartridges and these need the usblp kernel module. I contacted the libinklevel developer(Markus Heinz) to see if there was a workaround and he was very helpful providing the following A loaded usblp.ko module is a necessity for the operation of libinklevel. There are two options: 1. Compile cups with ./configure --enable-libusb=no Then you get the old cups usb backend which works with a loaded usblp.ko kernel module. 2. The Debian maintainers of cups have written a patch with makes cups work with the new libusb backend and a loaded usblp.ko module in parallel. This patch should be included in this file: http://ftp.de.debian.org/debian/pool/main/c/cups/cups_1.4.1-4.diff.gz I was not sure whether to file a new bug, but this one seems appropriate?
This bug is now nearly two months old. Why doesn'tthe cups ebuild at least check for this problem? I just updated cups and a few other packages and have to start digging to find out why I no longer have any print capability. At the _very_ least check for usblp , warn and link to this bug. Is there any objection to the debian patch in #15 seems the cleanest and most comprehensive solution here. Any chance that can get acted on?
blacklist trick was not sufficient. I had to upgrade to a previous 1.3.11 version.
(In reply to comment #16) > > This bug is now nearly two months old. Why doesn'tthe cups ebuild at least > check for this problem? I just updated cups and a few other packages and have > to start digging to find out why I no longer have any print capability. > > At the _very_ least check for usblp , warn and link to this bug. > > Is there any objection to the debian patch in #15 seems the cleanest and most > comprehensive solution here. Any chance that can get acted on? > Even if I agree with you (this should be solved anyway, either by CUPS/SANE/udev upstream or through Gentoo patching), I can perfectly print with CUPS 1.4 and usblp module loaded using the trick I posted in comment #12: http://bugs.gentoo.org/show_bug.cgi?id=285166#c12 I know it's a dirty trick, but at least I can both print and scan without issues. Regards
I think that perhaps cups-1.4 should be masked until this is solved. My solution was to put cups-1.4 in my package.mask file. I hope that this problem is solved soon, since after unloading usblp, my printer still did not work with cups-1.4
(In reply to comment #19) > I think that perhaps cups-1.4 should be masked until this is solved. > My solution was to put cups-1.4 in my package.mask file. > > I hope that this problem is solved soon, since after unloading usblp, my > printer still did not work with cups-1.4 > there is another solution, i found at cups bugzilla that you can still use usblp if you configure your CUPS with the "--disable-libusb" option. So maybe USE flag usblp should be added?
(In reply to comment #20) > (In reply to comment #19) > > I think that perhaps cups-1.4 should be masked until this is solved. > > My solution was to put cups-1.4 in my package.mask file. > > > > I hope that this problem is solved soon, since after unloading usblp, my > > printer still did not work with cups-1.4 > > > there is another solution, i found at cups bugzilla that you can still use > usblp if you configure your CUPS with the "--disable-libusb" option. So maybe > USE flag usblp should be added? > tryed to make own ebuild with libusb flag, but still doesn't work with usblp turned on, maybe i missed something, i would like others to try as well.
For getting my Kyocera 1020D to work with cups 1.4 it was not sufficient to deactivate the usblp module in the kernel config and then recompile the kernel. I also had to delete my printer from the cups config and install it again. people who say that it does not help to compile cups with --enable-libusb=no or toremove usblp from kernel may also try to delete their printer from the cups config and then re-install their device.
This bug is still present with cups 1.4.2-r1 and udev 151-r1. Can we hope for a solution which will not involve dirty workarounds?
This probably should be split into two separate bugs as it discusses two distinct issues: 1. Cups does not work with the usblp module loaded 2. For printer-scanner combo devices the group of the device is set to 'scanner' by udev so cups is not able to access it. Both lead to the same error message in cups though.
Created attachment 243053 [details, diff] one usb CUPS backend for both libusb-based and usblp-based access Latest patch for cups-1.4.4 realizing the "one usb CUPS backend for both libusb-based and usblp-based access" mentioned in previous comments. Source: http://www.cups.org/str.php?L3357
Created attachment 243055 [details] Updated ebuild for cups-1.4.4 to use the libusb/usblp patch
(In reply to comment #24) > 2. For printer-scanner combo devices the group of the device is set to > 'scanner' by udev so cups is not able to access it. > I started to see the printer after chmod 777 -R /dev/bus/usb, even though this is a printer, not a scanner. So it is in group ”usb”. So that one is not directly related to scanners.
(In reply to comment #26) > Created an attachment (id=243055) [details] > Updated ebuild for cups-1.4.4 to use the libusb/usblp patch > added the patch to cups-1.4.4-r2 ebuild (current) and works fine. now have usblp loaded and can use escputil to clean epson print head, also have side-effect that cleaning print head from cups web interface works: always died with 'pstoraster failed' before.
With regard to the "one usb CUPS backend for both libusb-based and usblp-based access" patch, I'm struggling to see just quite what this achieves. If usblp is *not* loaded, then CUPS will use libusb for comms. However if usblp *is* loaded, that will claim all the printers and libusb won't get a look in. So in effect, whilst CUPS will support both methods it's an either/or case (unless I'm missing something)..
As far as I can tell, this problem is still present with cups 1.4.5 and udev 151-r4. I'm recompiling my kernel now, since I seem to have had usblp built in rather than as a module, so there was no way to block it.
Comment #29: If usblp is *not* loaded, then CUPS will use libusb for comms. However if usblp *is* loaded, that will claim all the printers and libusb won't get a look in. jon bird, I can't help you there, but please read http://www.cups.org/str.php?L3357 for a description of the patch. If you already did that and based your conclusions on it, then sorry, *I* don't understand what's the problem. For me, it simply works where before it did not, and I have no idea what the patch does ;-) Maybe the author of the patch could provide you with an explanation and answers to your questions. ---------- Excerpt ---------- The attached patch make one "usb" backend out of the two. This new backend - Uses both access methods: libusb and the usblp kernel module - Discovers always all printers independent which ones are attached to the kernel module and which ones has to get accessed directly through libusb - Algorithms to generate the make and model part of the URIs are identical now for both access methods, serial number and interface is added to the URI if available - As an URI determined via libusb can have additional serial number and interface parts the URI matching for printing a file is made more tolerant now. URIs which only differ by the presence of an interface part or URIs with and without serial number are considered equal. So on a printer discovered through the usblp module one can print when the kernel module is detached or not loaded. This is especially important for print queues which were created with CUPS 1.3.x or older. They simply keep working now, even when unloading the kernel module. - Linux distributions will have the possibility to let the user work with or without usblp kernel module, without needing two different CUPS packages. ---------- Excerpt ----------
Thanks for this link, Small_Penguin. Now its clear that only one method can be selected once in compile time. I had reemerged cups whith USE="-usb" and kept my kernel with old config (with usblp). Cups works now.
(In reply to comment #24) > 2. For printer-scanner combo devices the group of the device is set to > 'scanner' by udev so cups is not able to access it. The problem is the scanner group itself: A printer-scanner combo device should stay with the lp group. Because any user who is in the lp group can scan just fine, but CUPS can't print on a device which is not part of the lp group. And imho you a right, this problematic should go in a new bug.
So how wrong is it to edit 70-libsane.rules to change the group from scanner to lp for my multifunction device? I also note that my device has a rule in both 70-libsane.rules and 55-hpmud.rules, which has GROUP="lp". Since the 70- file seems to take priority, would it also be appropriate or wrong to rename one of the files to change the order of evaluation?
*bump* What's the status on this? Will the libusb/usblp backend patch be included in the ebuild in portage? This bug here is from 2009?? http://www.cups.org/str.php?L3357: "The patch is already in use in the Debian and Ubuntu distributions for several months and there are no user complaints about it." (07:57 Apr 26, 2010)
(In reply to comment #35) > *bump* > > What's the status on this? Will the libusb/usblp backend patch be included in > the ebuild in portage? This bug here is from 2009?? > > http://www.cups.org/str.php?L3357: > "The patch is already in use in the Debian and Ubuntu distributions for several > months and there are no user complaints about it." (07:57 Apr 26, 2010) It won't. The patch hasn't beed included or accepted even for CUPS 1.5 and it also doesn't look like there's much activity on the upstream bug as the last comment is over a year old. We can't maintain such a huge patch ourselfs and upstream also won't care if there are any issues with it. Our policy is to follow upstream as close as possible. That means bugfixes yes, changes in functionality or completely new features no.
Comment on attachment 243053 [details, diff] one usb CUPS backend for both libusb-based and usblp-based access Debian patch not going anywhere
This bug report has become a big mess with a lot of different issues mixed, which is why I am closing it now. Cups-1.4 with libusb support will never go stable anyway. Please test the usb support of current cups-1.5, it should be better. If you still have problems, please file new bug reports, one per problem...
