udev-ish replacement for hal-cups-utils?

[Tim Waugh]

On Sun, 2009-07-19 at 19:58 +0200, Till Kamppeter wrote:
> Do not wonder why I talk about yesterday's GIT snapshot of 
> udev-configure-printer, but today's version (commit cca637e7 on the udev 
> branch) immediately segfaults in the "add" procedure, see more in the 
> end of this mail.

Oh, that's a shame.  You should be able to use gdb to find out what it's
up to -- just 'gdb --args udev/udev-configure-printer add /devices/...'
as root.

> It fixes the following problems:
> 
> Hunk in line 150:
> 
> When parsing device IDs, convert the manufacturer name "Hewlett-Packard" 
> to "HP" and "Lexmark International" to "Lexmark" using case-insensitive 
> matching. CUPS does this, too and so we have to do it to match against 
> device IDs from CUPS. Also device IDs obtained by CUPS' "usb" backend 
> and IDs from HPLIP's "hp"/"hpfax" backends can defer by the manufacturer 
> names in the device IDs which they report.

Actually we don't need to do this.  As I hinted (perhaps too softly,
sorry) in my last email we don't need to examine the device URI to find
matching devices because the CUPS-Get-Devices request returns a
device-id attribute which we can use to check against.

Theoretically we could just strcmp() the two Device IDs, but in practice
some vendors use Device IDs to store state information which can change
from retrieval to retrieval.  As a result we just compare MFG and MDL,
and SERN if it is available.

> Hunks in line 212 and 226:
> 
> Do really get the device ID from udev, for real testing and for testing 
> on my typical desktop configuration of 10 HP printers on the USB (and no 
> Epson). This method only reports device IDs if my modified udev rules 
> from my last posting are used and if the usblp kernel module id loaded.

Hmm, did you see my commits from today?  We use libusb to fetch the
Device ID.  It's no good relying on usblp -- the libusb-enabled CUPS usb
backend won't report any devices if usblp is loaded.

I would much rather have the udev-configure-printer hook dependent only
on the low-level device, so that there are fewer moving parts to go
wrong.

> Hunk in line 348:
> 
> Modified the comparing of device IDs. HPLIP often reports a device ID 
> with serial number when the "real" device ID (reported by udev or by the 
> CUPS "usb" backend) does not report the serial number. So we should 
> consider also as a match if one device ID has a serial number and the 
> other not. Only if the two IDs have different serial numbers we should 
> consider it as a mismatch.

This sounds like an HPLIP bug to me.  A Device ID is a Device ID.  Why
would they change what the device is reporting?

Quite honestly I'm fed up with adding in hacks here and there just for
the sake of HPLIP.

> Hunk in line 551:
> 
> Put the device URIs in quotes for the call of udev-configure-printer on 
> device removal. Some device IDs (for example of the DesignJet 130) 
> contain weird characters.

Thank you.  I'd forgotten URIs weren't necessarily shell safe... how
embarrassing. :-)

> URIs of the "usb" CUPS backend get principally not assigned due to the 
> following problem: udev seems to keep the usblp-based printer device 
> claimed throughout the whole udev procedure, so that other processes 
> like the callouts for example cannot access the devices. For finding 
> device URIs corresponding to the currently discovered device ID 
> udev-configure-printer makes a CUPS_GET_DEVICES IPP request and on such 
> a request CUPS does a live discovery of all printers by running all 
> backends without command line arguments. This finds nicely all printer 
> URIs except exactly the one "usb:/..." URI of the device currently under 
> consideration, probably because the device is claimed by udev and so the 
> CUPS "usb" backend cannot access it. So "usb:/..." URIs get never assigned.

Indeed.  This problem goes away if we just use libusb to fetch the
Device ID using the low-level device rule.

> This function is also used on a printer connection event, 
> so no CUPS_GET_DEVICES IPP request is needed. Note also that 
> CUPS_GET_DEVICES takes some seconds and so it is better to avoid it. 

It doesn't take very long at all if we limit the included schemes (which
we do).

> A more straightforward method would be to never trigger 
> udev-configure-printer on high-level devices but always on low-level 
> devices. This way the real connection/disconnection events are used. If 
> getting the device ID by libusb fails it should be checked whether there 
> is a corresponding high-level device to take the device ID from there.

Yes, I think this is needed.

> Another improvement which I recommend but I did not test yet (and it 
> should not break anything) is to make the comparing of device IDs near 
> line 348 completely case-insensitive (strcasecmp instead of strcmp). 
> CUPS backends report the IDs of HP printers sometimes with "hp" and 
> sometimes with "HP" for example.

But the device-id attributes will pass the case sensitivity through
unchanged.  Or are you talking about HPLIP brokenness again?

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/20090719/1aa38640/attachment.pgp