RE: Tagging PPD package with DeviceID.

The problem is CUPS only fabricate deviceID using dnssd protocol, not for snmp. For Ricoh, only printers with Postscript option supports dnssd, I have added Ricoh's OID in the CUPS defect you filed, I'll see whether CUPS is open to include more vendor specific deviceIdOids. George -----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Thursday, May 06, 2010 3:37 AM To: George Liu Cc: Till Kamppeter; system-config-printer-devel(a)lists.fedorahosted.org; Bin Li Subject: RE: Tagging PPD package with DeviceID. George, Bear in mind that there are two distinct mechanisms here: ==> 1. Using PackageKit to automatically install driver packages This is entirely based on IEEE 1284 Device IDs. Without an ID, it just won't work. Users have to install packages manually, or else hope they are already installed. This is the current situation, pre-Fedora 13. 2. Matching an attached printer to a set of installed drivers If we have IEEE 1284 Device IDs from the printer and from all the drivers, this is easy and straight-forward. In system-config-printer, we try a "best effort" approach in the absence of Device IDs. We actually go to great lengths to do this: very much of the cupshelpers.ppds is concerned with this sort of "fuzzy matching". It is unreliable by its very nature. <== Also note that some of the terminology here can be confusing, so I'll use the phrases "driver package" and "driver". A single "driver package" usually provides many "drivers". A "driver package" in Fedora corresponds to an RPM. A "driver" corresponds to a single PPD and is particular to a printer model and page description language. So, with that in mind, in response: On Wed, 2010-05-05 at 10:43 -0700, George Liu wrote: So with the printers that do not expose their IEEE 1284 Device IDs via any network interface: do they have other physical interfaces such as USB or parallel port, and do they expose IEEE 1284 Device IDs in that case? This is what makes it problematic to relax the rules for automatic package installation. The whole point of Device IDs was that they are sufficient to identify the printer. If we can only get at the Device ID on some interfaces, then we have to "make up" an ID for others -- and this means either 1. Having a static look-up table to map the device-make-and-model to the actual Device ID for each particular method of determining the device-make-and-model (e.g. SNMP might give different results to mDNS) or 2. Having multiple IEEE 1284 Device IDs for the device, one that is "real", and one (or several) "made up" As CUPS can only tell us one ID per PPD, this means having separate PPDs for each "made up" ID. We have to know ahead of time what the Device IDs will be, so we can tag the driver package with them. Now you are confusing the automatic installation of driver packages with the matching of printers to drivers. These are two separate steps. Furthermore, the CUPS web interface offers *much less* than the system-config-printer interface does when it comes to matching drivers to an attached printer. It is extremely primitive in the way it does this: it simply extracts the first word from the device URI and *assumes* that it is the name of the manufacturer (it's just a URI -- that first word could be *anything*). That's it. It doesn't try to match the device-make-and-model to the ppd-make-and-model. It doesn't even try to match the IEEE 1284 Device ID. Delegating the entire process to the user doesn't really count as a matching mechanism IMHO. ;-) See http://www.cups.org/str.php?L3552 in which HP's OID is suggested. If there is no way to get a Device ID from the printer the CUPS backend ought to fabricate one (the dnssd backend already does this, for example), and you can fabricate a Device ID to put in your PPDs. Then when your PPDs are packaged, the package will get tagged with your fabricated Device IDs. You'll have to cross your fingers that they match the ones CUPS makes up, and that the mechanism used by CUPS for fabricating Device IDs doesn't change, or else the automatic driver package installation will fail to find a package to install: but that's the price to pay for such a fragile system. Note that if the packages are already installed on a given system, you get to use the "fuzzy matching" that's already present in system-config-printer. I won't be I'm afraid. Tim. */