udev-ish replacement for hal-cups-utils?

[Tim Waugh]

On Fri, 2009-07-17 at 21:56 +0200, Till Kamppeter wrote:
> I have looked into udev-configure-printer.c and I see two problems (in 
> hal_lpadmin this works):
> 
> 1. One device can have more than one queue. Your program supports only 
> one queue per device according to the syntax of the "remove" call. If 
> there is actually more than one queue, the one which gets disabled is 
> probably chosen more or less randomly.
> 2. While the device is connected and turned on, additional queues can 
> get added manually (s-c-p, lpadmin, web interface, ...). These should 
> also get disabled on device connection.

I think these two points amount to the same thing unless I'm reading it
wrong.  I checked in some changes earlier today which I think address
that, at least for the usb://...-only case.  In particular take a look
at the function for_each_matching_queue().

Something I've thought of since then is about how to handle queues using
other backends such as hpfax: I think to handle this we need to pass a
*list* of device URIs to the "remove" command, instead of just one.

Asking it to do its own MFG/MDL/SERN matching won't work because by that
time the device is no longer around, so the CUPS-Get-Devices call won't
find any URIs that will match.

Hmm, I just realised that I'm doing things the hard way:
CUPS-Get-Devices can tell me the actual IEEE 1284 Device ID for each
device, so I can just compare the string with what came from
'.../ieee1284_id'.  I don't even need to parse it! (Although perhaps it
would be better to filter out unknown fields in case they are not fixed
strings.)

> For getting the device ID in "add" mode it must be able to 
> use both the usblp IOCTL and the libusb method (hal_lpadmin does this, 
> too).

We don't need to do any of this once the '/ieee1284_id' stuff works
properly though.

> In "remove" mode it must be checked whether the triggering device 
> is usblp or low-level USB, if it is usblp, it must be checked whether 
> the corresponding low-level USB device is still there and in that case 
> terminate without disabling the queue

I don't know that this is much of an issue really.  Once everyone is
using CUPS 1.4 with its libusb-based usb backend, who will still be
using usblp?

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/20090717/8c7892ca/attachment.pgp