[cups-devel] Hacking USB uris to make them more predictableMichael Sweet

msweet at apple.com
Wed Feb 22 12:56:12 PST 2017


Justin,

The issue is that a significant portion of the USB printers do not report a serial number (or rather, they report the same serial number for all printers...) so unless you can guarantee a single printer of a given make/model you are screwed.

Traditionally we have added an interface identifier to the device URI when we can't get the serial number; that works as long as you don't move the printers to a different port and don't use a USB hub (which introduces a level of randomness...)


> On Feb 22, 2017, at 2:39 PM, Justin Carlson <foozle at gmail.com> wrote:
> 
> So I'm working with cups to handle USB printing in a managed system, and,
> for reasons that probably aren't particularly interesting to this list, I'd
> like to be able to directly query a USB printer and reliably determine the
> URI that cups is going to use to refer to that device, preferably without
> having to call out to any CUPS binaries/libraries.
> 
> Having dug through the code a bit, the number of hacks/workarounds/fuzzy
> matching stuff that is currently done during URI generation to cope with
> weirdness and inconsistencies in the ieee1284 fields makes me deeply
> uncomfortable -- it seems like matching those special cases and munges
> would end up extremely fragile.
> 
> However, URI generation for USB devices seems to be extremely well
> localized -- AFAICT it's just in make_device_uri() in backend/usb-libusb.c.
> 
> 
> So I'm thinking, at least for our system, of patching CUPS to use a
> completely different USB URI scheme that ignores the ieee1284 fields
> altogether in favor of using things in the USB device descriptor --
> probably something like usb://{vendor_id}/{product_id}?serial={serial}.
> 
> These URIs are not really user-visible in my use case, so I'm just
> concerned about having a reliable reference to a given printer.
> 
> Is this a terrible idea for some reason that I'm not seeing?  Are there
> subtle dependencies on the existing URI scheme of which I may not be
> aware?  Happy to get any feedback at all on this.
> 
> Thanks,
> -J
> _______________________________________________
> cups-devel mailing list
> cups-devel at cups.org
> https://lists.cups.org/mailman/listinfo/cups-devel

_________________________________________________________
Michael Sweet, Senior Printing System Engineer



More information about the cups-devel mailing list