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