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. */
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
