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@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:
Unfortunately from the way this device-id is constructed I can tell that this device does not correctly advertise its IEEE 1284 Device ID over DNS-SD. Instead of using the 'usb_MFG' and 'usb_MDL' keys (which *must* correspond with the IEEE 1284 Device ID 'MFG' and 'MDL' fields when present), the printer is using either the 'product' or 'ty' field to specify the printer's entire make-and-model name. This is not an IEEE 1284 Device ID.
GL> Can you elaborate?
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.)
Here's a 1284DeviceID retrieved through Ricoh private MIB. "MFG:RICOH;CMD:PJL,RCS,PCL,PCLXL,POSTSCRIPT;MDL:Aficio MP C3500;STS:10072/10033,0;CLS:PRINTER;DES:RICOH Aficio MP C3500;" MFG field and MDL field matches, right?
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.
When building PPD package, which part of the 1284DeviceID string is supposed to be used to tag the package?
The MFG (or MANUFACTURER) and MDL (or MODEL) fields.
GL> I'm confused. Does s-c-p has two mechanisms to find a driver? Openprinting.org and Fedora repository (with package tagged with deviceiD?)
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:
Sending SNMP request to 172.30.4.243 for device-id Skipping socket://172.30.4.243, insufficient data Skipping lpd://172.30.4.228/, insufficient data Sending SNMP request to 172.30.4.14 for device-id Skipping socket://172.30.4.14, insufficient data Sending SNMP request to 172.30.4.156 for device-id Skipping socket://172.30.4.156, insufficient data Sending SNMP request to 172.30.4.173 for device-id Skipping socket://172.30.4.173, insufficient data Sending SNMP request to 172.30.4.207 for device-id Skipping socket://172.30.4.207, insufficient data Sending SNMP request to 172.30.4.48 for device-id Skipping socket://172.30.4.48, insufficient data
Hopefully some of these provide Device IDs on some private SNMP OID.
Installing relevant drivers using session service Fetching driver list ├── RICOH imagio MP C2800 (socket): MFG:RICOH;MDL:imagio MP C2800;CMD:PJL,RCS,R00; │ (No drivers)
For this one there is currently no driver available in Fedora 13.
├── RICOH Aficio SP C420DN (socket): MFG:RICOH;MDL:Aficio SP C420DN;CMD:PJL,RCS,PCL,PCLXL,POSTSCRIPT,POSTSCRIPT,PCL,PCLXL; │ (No drivers)
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. */