[Bug 867648] New: problems with CUPS and USB printers
https://bugzilla.novell.com/show_bug.cgi?id=867648 https://bugzilla.novell.com/show_bug.cgi?id=867648#c0 Summary: problems with CUPS and USB printers Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: Other OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Printing AssignedTo: jsmeix@suse.com ReportedBy: Ralf.Friedl@online.de QAContact: jsmeix@suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 I have several problems/suggestions with CUPS and USB printers. 1. In config-scripts/cups-common.m4:219 is this test: if test x$enable_libusb = xyes -o $uname != Darwin; then That means that if $uname != Darwin, --disable-libusb is ignored. This seems to assume that libusb is the preferred solution for all other systems. This is not true, I will come back to this later. Opensuse seems to build without libusb, so this is not an immediate problem, but it should be fixed so it is possible to rebuild CUPS while libusb is installed. 2. The USB backend used to be able to output to usb:/dev/lp0. This is no longer possible, although it is easy to fix. In backend/usb-unix.c:338 the lines errno = ENODEV; return (-1); have to be replaced with fd = open(uri + 4, O_RDWR | O_EXCL); return (fd); 3. With libusb, it is possible that one printer backend searching every 5 seconds for a missing printer interrupts all other USB backends every 5 seconds. These other print jobs then get restarted. The result is that the beginning of the print jobs is repeated until the paper runs out or someone brings the printer offline. So it is indeed a good idea to not use libusb by default. 4. The only problem with printing via kernel usblp is that most printers don't provide their serial number in the IEEE-1284 device id. So with multiple printers of the same model, libusb provides access to the serial number, but printing with libusb is not reliable. Printing with usblp doesn't give access to the serial number. I would like something like /dev/disk/by-id and /dev/disk/by-path to create reliable names for the printers and then use these device names for the CUPS USB backend. Reproducible: Always -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=867648 https://bugzilla.novell.com/show_bug.cgi?id=867648#c1 Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Platform|Other |All Found By|--- |Community User Resolution| |UPSTREAM Severity|Normal |Enhancement --- Comment #1 from Johannes Meixner <jsmeix@suse.com> 2014-03-11 12:21:43 CET --- We (i.e. openSUSE) distribute CUPS but we do not develop it. See "UPSTREAM" at https://bugzilla.novell.com/page.cgi?id=fields.html#status For CUPS development please contact CUPS upstream directly via http://www.cups.org/ so that there is a direct communication between you and the upstream authors. Note that because of bnc#735404 openSUSE has still a rather old CUPS version (1.5.4) but in recent CUPS 1.7.1 the "usb" backend is very different compared to CUPS 1.5.4. FYI: If the CUPS "usb" backend default behaviour does not work for you, you can make your own special backend as you need it, see http://en.opensuse.org/SDB:Using_Your_Own_Backends_to_Print_with_CUPS -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
If the CUPS "usb" backend ... I know that I can write a program or script from scratch instead of adding a
https://bugzilla.novell.com/show_bug.cgi?id=867648 https://bugzilla.novell.com/show_bug.cgi?id=867648#c2 --- Comment #2 from Ralf Friedl <Ralf.Friedl@online.de> 2014-03-11 12:09:29 UTC --- After reading bnc#735404, I don't think upstream (Apple) will be interested in improvements for Linux. In bnc#735404#3 you recommend to switch to libusb. I tried libusb, and in my case the results were bad, so I suggest to stay with usblp. It's not that printing with libusb "just works", it works just most of the time, or maybe in simpler setups. line to restore functionality that was intentionally removed. That doesn't mean that I want to do it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=867648 https://bugzilla.novell.com/show_bug.cgi?id=867648#c3 Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|problems with CUPS and USB |CUPS "usb" backend: |printers |problems in case of libusb --- Comment #3 from Johannes Meixner <jsmeix@suse.com> 2014-03-14 15:07:16 CET --- CUPS upstream is interested in improvements for Linux. Regardless that CUPS is owned by Apple it is still the Common Unix Printing System i.e. "the standards-based, open source printing system developed by Apple Inc. for OS X and other UNIX-like operating systems", see https://www.cups.org/ I really recommend to get in contact with CUPS upstream. Of course I don't know if CUPS upstream would go back to the traditional usblp kernel module because the switch to libusb was done intentionally. But when there are issues with libusb, I think you should at least report them to CUPS upstream so that the issues are at least registered at CUPS upstream. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=867648 https://bugzilla.novell.com/show_bug.cgi?id=867648#c4 --- Comment #4 from Ralf Friedl <Ralf.Friedl@online.de> 2014-03-19 18:31:54 UTC --- Just in case someone else has the same problem, here is what I did: I made the change mentioned above in backend/usb-unix.c:338 to reenable printing to usb:/dev/* devices. I created a file /etc/udev/rules.d/70-persistent-usblp.rules with this content: KERNEL!="lp*", GOTO="persistent_usblp_end" # import ID_BUS, ID_MODEL*, ID_REVISION, ID_SERIAL*, ID_TYPE, ID_USB*, ID_VENDOR* IMPORT{builtin}="usb_id" ENV{ID_SERIAL}=="?*", SYMLINK+="usb/lp/by-id/$env{ID_SERIAL}", SYMLINK+="usb/lp/by-id/$env{ID_VENDOR}-$env{ID_MODEL}-$env{ID_SERIAL_SHORT}" # import ID_PATH, ID_PATH_TAG IMPORT{builtin}="path_id" ENV{ID_PATH}=="?*", SYMLINK+="usb/lp/by-path/$env{ID_PATH}", SYMLINK+="usb/lp/by-path/$env{ID_PATH_TAG}" ACTION=="add|remove", RUN+="/usr/local/sbin/udev-configure-printer.sh" LABEL="persistent_usblp_end" -----EOF /usr/local/sbin/udev-configure-printer.sh is a simple script to start or stop the print queue corresponding to the found printer. I know that I have the symlinks double at the moment, I will probable remove one of each pair. With these links and the change to backend/usb I can access the printers either as usb:/dev/usb/lp/by-id/VENODR-MODEL-SERIAL or usb:/dev/usb/lp/by-path/PCI*-usb-0:3.2:1.0 The second version is really useful because if a printer breaks, it is possible to replace it with a compatible model without any changes to the configuration. Just cable out of broken printer, cable into new printer, ready. It is even more efficient than before, because it is not necessary to search for the printer for each print job. And it is unlikely that a problem with one printer will effectively disable all the other printers. I have this now running for a few days without any complaints or errors in the log file. Regarding upstream, you know that they intentionally removed the ability to print to /dev URLs, that they prefer libusb and are probably not interested in an approach to address a printer by path. Even if they did fix printing with libusb, they would not fix 1.5. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com