Ticket #1 (closed enhancement: fixed)

Opened 6 years ago

Last modified 6 years ago

Detect USB printers and set up queues for them also without the usblp kernel module

Reported by: tillk Owned by: twaugh
Priority: major Component: CUPS backend
Version: Keywords:
Cc: Blocked By:


HPLIP and beginning from version 1.4 also CUPS are turning away from the USB printer support via the usblp kernel module and switch(ed) to using libusb. It seems that for modern printers with ink level readout, multi-function stuff (like scanning), and so a character device like usblp is inadequate.

As libusb-based backends like HPLIP uncouple the printer device from the usblp module, there is no reliable detection of connecting and disconnecting printers via the usblp kernel module any more. Especially the first access to a printer with a libusb-based backend can uncouple the printer from usblp and make hal_lpadmin stop the printer because it is assumed that the printer got turned off.

So the best is to detect printers on a lower level, so that the usblp module has no influence. And this can be done without problem. The new CUPS usb backend checks the interface class whether it is 7 (USB_CLASS_PRINTER, /usr/include/usb.h) to determine whether a USB device is a printer. See


With HAL one can do this, too. See the output of "lshal". It has the following sections for a USB printer (here HP LaserJet? P3005):

udi = '/org/freedesktop/Hal/devices/usb_device_3f0_7317_CNK2N34563' udi = '/org/freedesktop/Hal/devices/usb_device_3f0_7317_CNK2N34563_if0' udi = '/org/freedesktop/Hal/devices/usb_device_3f0_7317_CNK2N34563_if0_printer_noserial'

The last section comes from the usblp kernel module and does not appear when one blacklists the module (line "blacklist usblp" in /etc/modprobe.d/blacklist). This section is currently used to trigger the call of hal_lpadmin for auto setup of a print queue.

Without usblp only the first two sections appear and they provide already enough info to determine whether a plugged USB device is a printer. We simply check the section for the interface (the second one, with "_ifX" at the end) and look for the interface class. If it is 7, we have a printer:

usb.interface.class = 7 (0x7) (int)

Only thing missing here is that in these two setions there are no elements of the device ID (make, model, description, command set). So we must poll the device ID from the device by accessing it via bus and device numbers (usb.bus_number and usb.linux.device_number in the interface section). The poll itself can be done via IOCTLs, see


or the following small C program


or the following Perl code


So my suggestion is to replase the usblp based triggering of the hal_lpadmin script by a triggering based on interface class 7. Probably only the files systemv/10-hal_lpadmin.fdi and systemv/hal_lpadmin need to be changed. The former for the triggering and the latter for polling the device ID.


no-usblp.patch (15.4 KB) - added by tillk 6 years ago.
This patch implements this feature request. It makes hal_lpadmin working independent of the presence of usblp

Change History

comment:1 Changed 6 years ago by tillk

  • Owner changed from somebody to twaugh

Changed 6 years ago by tillk

This patch implements this feature request. It makes hal_lpadmin working independent of the presence of usblp

comment:2 Changed 6 years ago by tillk

  • Status changed from new to closed
  • Resolution set to fixed

Committed attached patch into the GIT repository.

Note: See TracTickets for help on using tickets.