Construct 1284DeviceID with CMD filed from mDNS record?

Tim, During printer discovery, more likely than not, 1284DeviceID is discovered using dnssd protocol. Is it possible to construct 1284DeviceID with CMD field from mDNS record? Thanks George -----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Thursday, May 06, 2010 4:47 AM To: George Liu Cc: system-config-printer-devel(a)lists.fedorahosted.org; Till Kamppeter; Bin Li Subject: RE: Tagging PPD package with DeviceID. On Wed, 2010-05-05 at 11:19 -0700, George Liu wrote: So, what I'm talking about here is the way that the fields in an IEEE 1284 Device ID string map to fields in an mDNS record. The only mDNS record fields we can definitely rely upon to be compared with equivalent fields in an IEEE 1284 Device ID string are those who names begin "usb_". For example: usb_MFG <-> MFG usb_MDL <-> MDL Any other fields are just informational. For example, there may be a "product" field in the mDNS record. Great, that might be a model name, possibly including the manufacturer's name at the beginning. But that doesn't tell us anything definitely about what the IEEE 1284 Device ID MFG and MDL fields are. We're left in the world of guessing and fuzzy matching. It is only when there are usb_MFG and usb_MDL fields (or equivalent, e.g. usb_MANUFACTURER) that we can say "this is what the IEEE 1284 Device ID fields are". As it turns out, I can tell from the output of 'lpinfo -l -v' that you gave that there was no usb_MFG or usb_MDL field in the mDNS record. I can tell because there is no trailing ";" terminating the MDL field. This is a typo in the CUPS dnssd backend. :-) (In Fedora 13 I have modified the CUPS dnssd backend since F-13 Beta so that it adds a special field "FZY" to aid with debugging this sort of thing. If I see that "FZY:1;" I know the ID is fabricated. On the other hand, if I see "FZY:0;" I know it's from usb_* fields.) By coincidence, yes, and because there are few possible variations on the name. If it were an HP printer, for example, the MFG field might be "Hewlett-Packard" or "HP" or "HEWLETT-PACKARD" etc. Different manufacturers choose to put different sorts of thing in the MDL field as well. In this instance, the MDL field does not include the manufacturer's name; other vendors choose to include it. Some put a more generic string describing the series of models; some go to the other extreme and include the various optional bits for a particular model (does it have bluetooth, etc). Simply getting "the manufacturer's name" and "the model name" is not sufficient to compare with an IEEE 1284 Device ID, which is effectively an arbitrary string that cannot be guessed ahead of time. The MFG (or MANUFACTURER) and MDL (or MODEL) fields. Currently system-config-printer uses these mechanisms for installing things * PackageKit (driver packages, distribution-provided and 3rd-party) * Jockey (driver packages, 3rd-party) * OpenPrinting web query (driver PPDs only, 3rd party) I hope to phase out the OpenPrinting web query mechanism in favour of PackageKit once all the pieces are in place. Similarly with Jockey, if possible. Thanks for the output of check-device-ids.py: Hopefully some of these provide Device IDs on some private SNMP OID. For this one there is currently no driver available in Fedora 13. For this one, foomatic-db has two PPDs that ought to carry that Device ID but don't. I've filed bugzilla bugs to track the missing IDs for both the Aficio MP C3500 and for the Aficio SP C420DN: https://bugzilla.redhat.com/show_bug.cgi?id=589527 https://bugzilla.redhat.com/show_bug.cgi?id=589533 I'll go ahead and add the right attributes to the PPDs upstream in foomatic-db, then rebuild the Fedora packages with them so they pick up the Device IDs. Tim. */