Opened 20 years ago

Closed 20 years ago

#863 closed defect (fixed)

usblp entries in udev configuration files

Reported by: alexander@… Owned by: Matthew Burgess
Priority: high Milestone:
Component: Book Version: CVS
Severity: major Keywords:
Cc:

Description

1) /etc/udev/permissions.d/00-lfs.permissions mentions both usblp* and usb/lp* nodes, although only usb/lp* are created by default

2) CUPS in BLFS uses usblp* and therefore it is tricky to configure it to use a USB printer via the web interface.

Change History (8)

comment:1 by Matthew Burgess, 20 years ago

A question then: What is the correct (or at least the more generally better accepted) method of referring to a USB printer. Is it usb/lp* or usblp*. I thought it was the former, but of course would be willing to be proved wrong. I have a _personal_ preference for seeing all USB devices listed under /dev/usb/* but that shouldn't influence anything really - it just seems logical to me.

I have set up my USB printer at /dev/usb/lp0 following the hint at http://www.linuxfromscratch.org/hints/downloads/files/hpdeskjet.txt. This gives explicit instructions on how to get add such a device to CUPS:

lpadmin -p HP_Deskjet -m HP-DeskJet_*-hpijs.ppd -v usb:/dev/usb/lp0 -E

Following that, then, it is clear that CUPS *does* support devices under /dev/usb/*, but perhaps it is simply the web interfaces "Add Printer" (or similar) feature that is buggy in this regard?

Either way I think that 1) can be handled by simply removing /dev/usblp* from the permissions file (or are they required by something else, _not_ due to upstream being unable to handle /dev/usb/lp* entries) and 2) Can be handled by reporting any failures of CUPS upstream.

Cheers,

Matt.

comment:2 by alexander@…, 20 years ago

As for (1): I agree that we can remove usblp from the permissions file, and that will be the correct solution (because /dev/usblp0 will never exist).

As for (2): you are right, CUPS can use /dev/usb/lp*. And one can add it using the lpadmin command. The bug is that one cannot easily configure the printer using the web interface without turning it on first if /dev is not static. It's a CUPS bug.

# With the printer turned on: [root in /usr/lib/cups/backend]# ./usb direct usb://EPSON/Stylus%20C84 "EPSON Stylus C84" "USB Printer #1" direct usb:/dev/usb/lp1 "Unknown" "USB Printer #2" <snip>

# With the printer turned off [root in /usr/lib/cups/backend]# ./usb direct usb:/dev/usblp0 "Unknown" "USB Printer #1" direct usb:/dev/usblp1 "Unknown" "USB Printer #2" <snip>

comment:3 by Matthew Burgess, 20 years ago

I'm not sure I agree there is a bug (in CUPS). I mean, how are you supposed to configure a device that isn't present? Yes, it may be physically present in front of you, but it may not have *both* the USB cable and the power cable connected (or switched on). This then begs the question: Why do you want to configure a non-existent device? As soon as the printer has both a USB cable and power running to it, then the device will be created and CUPS will be able to configure it. Up until that point, the printer may as well be smashed to simtherines for all CUPS cares.

comment:4 by alexander@…, 20 years ago

My boss says:

Tomorrow I will buy such-and-such printer, please configure it now, just to make me sure that it has some formal support.

Also, I must reconfigure printer when I update gimp-print. I know that it will work, and I prefer to avoid making extra noise if the printer is currently off.

comment:5 by Matthew Burgess, 20 years ago

Owner: changed from lfs-book@… to Matthew Burgess

Well, I'm not going to go into the ins and outs of your bosses hardware purchasing process, nor your aversion to a split second of noise as the printers' cartridges / heads align themselves.

I'll deal with point 1) tonight and leave the benefits (or otherwise) of point 2) for the CUPS mailing list.

comment:6 by Matthew Burgess, 20 years ago

Status: newassigned

comment:7 by Matthew Burgess, 20 years ago

Alex,

I can't see anything in http://downloads.linuxfromscratch.org/udev-config-1.rules that would be creating duplicate devices. Can you confirm this is a real bug with the book's instructions please, and if so point me to what's causing it as I thought all device naming was configured via the .rules file.

Cheers,

Matt.

comment:8 by alexander@…, 20 years ago

Resolution: fixed
Status: assignedclosed

You misunderstood the bug :)

There was nothing in the rules file that was causing /dev/usblp0 to be created. However, the permissions for this nonexistent device were specified in the http://downloads.linuxfromscratch.org/udev-config-1.permissions file, and these ghost permissions for a device that will never exist were the reason for opening a bug. Now we have http://downloads.linuxfromscratch.org/udev-config-2.permissions and it has the /dev/usblp0 ghost removed, so part (1) of the bug is fixed. As for part (2), it really belongs to BLFS and has a very low priority.

Note: See TracTickets for help on using tickets.