udev-ish replacement for hal-cups-utils?

[Tim Waugh]

On Mon, 2009-07-20 at 17:59 +0200, Till Kamppeter wrote:
> I have looked into the source code of the CUPS USB backends (usblp 
> version and libusb version) and they really report the original, 
> unmodified device ID.
> 
> I could report this to the HPLIP people telling that they should let 
> their backends report the unmodified device ID, but it can lead to
> 
> 1. One cannot connect two printers of the same model any more, as the 
> original device ID has no serial number

Please take a look at the current udev branch (d08eb47).

For the specific case where the device does not provide its own SERN
field in the Device ID, there are two possible cases we now allow for:

1. Adding a SERN field to the Device ID, consisting of the USB serial
number.  On reflection this does make some amount of sense.  This is
what the HPLIP backend does.

2. Including the USB device ID in the device URI.  This is what the CUPS
usb backend does when compiled with libusb support.

On Tue, 2009-07-21 at 02:03 +0200, Till Kamppeter wrote:
> 1. Bug in removal procedure, looks like that the program was only tested 
> on a system with only one printer. Here is the fix:

Thanks, applied.

> 2. "Incorrect line in /var/run/udev-configure-printer/usb-uris:" warnings
> 
> The warnings were triggered by blank lines in 
> /var/run/udev-configure-printer/usb-uris and in addition, every line has 
> one extra character in the end.

I think that should be fixed with a difference change I checked in to
use '\n' as a token delimiter as well as '\t'.

> 3. HPLIP broken device IDs

As I mentioned in my last email, I think this should work now in a way
that's fair to all manufacturers.

> 4. HPLIP Fax queues (not tested yet)
> 
> Fax URIs of HPLIP do not have the device ID of the actual printer so 
> that they get associated with the Fax PPD files.  The easiest to get
> Fax queues enabled and disabled (and also created if no fax queue is
> there) is probably that when an "hp:/..." URI is added to the matching
> URIs to automatically add also the "hpfax:/..." URI with "..." being
> the same as in the "hp:/..." URI. Unfortunately, this is again an ugly
> HPLIP exception.

Yes, I see.  There's basically no "right" way to do this then. :-( I
think the only option we have here is to look for 'fax' in either the
CUPS device URI scheme or the device-id MDL field.

Assuming fax machines will always be part of a multi-function device
that also prints, let's do this when adding a queue:

When two CUPS devices, one of which matches the Device ID of the device,
are identical except for the scheme part, and the remaining URI has a
scheme ending with 'fax', set up a queue for the *fax URI as well.

> Note that I have always connected or disconnected only one printer at
> a time. As there is one file to store the matching URIs for all
> printers I can imagine that the file can get completely messed up when
> several printers get connected or disconnected at the same time, for
> example by plugging a USB hub with several printers on it. This
> problem should also get addressed.

I've added locking now.  Thanks for pointing it out.

Tim.
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/devkit-devel/attachments/20090721/84d871a0/attachment.pgp