Tim,
Do you think you can loosen up the requirement for 1284DeviceID string a bit, so PackageKit could be used for a wider array of devices?
Although Port Monitor MIB has been 4-5 years old, it has not been adopted by all printer manufactures. Most Ricoh devices do not support it. Combined with the seven brands we have, Ricoh has 23.1% copier market share in the US in 2009. http://www.ricoh-usa.com/about/press/releases.asp?id=620 I believe Ricoh has similar market share in Europe and Japan as well.
I believe packageKit can still work for devices without port monitor mib support.
CUPS still can use hrDeviceDesc mib to get manufacture name and model name. ("make-and-model" ipp attribute.). With that attribute, one can simply construct 1284deviceID as "MFG:make;MDL:model".
If def "examine_file (self, path):" can put in this extra bit of logic (if no 1284DeviceID, construct one using Manufacturer and ModelName", it will be able to tag the PPD package correctly. (Alternatively, if openprinting.org is to create the PPD package, Till could deploy the similar logic)
Then, the next question become how do s-c-p matches a device to a PPD file. Can you elaborate on this session? ----------------------------------------------------------------------- If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible. -----------------------------------------------------------------------
George
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Wednesday, April 28, 2010 9:19 AM To: George Liu Cc: Till Kamppeter; Bin Li Subject: RE: [Printing-summit] OpenPrinting Summit 2010 - Assigned the Sessions to Hours
Hi George,
You might like to subscribe to the new system-config-printer-devel mailing list: https://fedorahosted.org/mailman/listinfo/system-config-printer-devel
That's the sort of thing we can discuss there.
On Tue, 2010-04-27 at 13:16 -0700, George Liu wrote:
Ricoh liked the idea you had for using PackageKit to download/update driver very much. We would like to update our PPD file (currently we don't put 1284DeviceID in them), and test out the Ricoh PPD package with System-Config-Printer (scp).
Can you guide me through the process? I have a couple questions that I want to clarify.
- How exactly does scp aquires 1284DeviceID? Which CUPS API does it
use?
Here is the full cycle:
First, you add the 1284DeviceID attributes to your PPD files.
Then you get those PPD files into an RPM source package. One way to do that would be to add/update them in foomatic-db. I periodically pull a new foomatic-db snapshot from openprinting.org into the Fedora 'foomatic-db' package.
Next, the binary RPM is built on Fedora 13. At the very end of this process, Fedora 13's version of rpm will run a special 'provides' script, /usr/lib/rpm/postscriptdriver.prov, will get run on each of the PPD-providing files to be packaged up in the RPM. You can see that script here: http://cvs.fedoraproject.org/viewvc/devel/rpm/rpm-4.8.0-psdriver-deps.patch?...
(as well as the changes we made to rpm to get it to identify which files provide PPDs)
The provides script is written in Python. Here's the bit that extracts the IEEE 1284 Device ID from a simple PPD file:
class PPDDriver(Driver): ... def examine_file (self, path): try: ppd = cups.PPD (path) except RuntimeError, e: # Not a PPD file. Perhaps it's a drv file. drv = DrvDriver (path) self.ids += drv.list () return
attr = ppd.findAttr ('1284DeviceID') while attr: self.ids += attr.value attr = ppd.findNextAttr ('1284DeviceID')
i.e. it uses the CUPS PPD API from libcups (via pycups).
That provides script tells rpm what tags to attach to the binary RPM package.
When that binary RPM is made available as an update to Fedora, it will be in a yum repository. The repository contains some comparatively small files containing all of the 'Provides:' tags from the packages in the repository, along with which package provides each. In this way, PackageKit running on a Fedora installation is able to download this file, examine it, and decide which packages it would need to download in order to satisfy a given 'Requires:' requirement.
So, the next thing is that a user comes along with their printer, and they plug it into their Fedora installation (or set up a network queue for it, if it's a network printer).
If it's a USB printer, the system-config-printer-udev program collects the IEEE 1284 Device ID from the kernel, asks CUPS for a list of local devices (with IDs) and tries to match the printer against one of the available CUPS devices.
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
When it has got a Device ID, system-config-printer asks PackageKit to install all drivers providing it. (In fact, it asks the PackageKit session daemon to do it, which in turn asks the PackageKit system daemon.)
- How does scp handles the case for printers without Port Monotor MIB
support?
If a network printer does not report its IEEE 1284 Device ID in a way that the CUPS backends can collect, system-config-printer won't get a Device ID for it and so won't be able to ask PackageKit to install any drivers.
- I got scp source from git fedora repository. Which file should I
look at?
The implementation of the automatic printer driver download feature spans several packages actually, so for testing it out, by *far* the easiest way to do it is to download and install Fedora 13 Beta and set up a queue for the printer.
If you're interested in the implementation, it takes quite a bit of following:
rpm (see the link above)
system-config-printer: ppdsloader.py contains a class that fetches a list of PPDs from CUPS given an IEEE 1284 Device ID. First it asks both Jockey and PackageKit if they'd like to install any relevant drivers. This is used in system-config-printer.py when a queue is set up. installdriver.py contains a D-Bus system service that runs in the user's session, and simply forwards the udev hook's D-Bus request on to the PackageKit session daemon. That way, the user gets to accept/decline package installation. See udev/udev-add-printer for the client part of it.
gnome-packagekit: src/gpk-dbus-task.c (gpk_dbus_task_install_printer_drivers): this handles the actual PackageKit transactions and user interactions
PackageKit: new enum type for postscriptdriver, as well as special handling in the yum backend
- What are the stesp needed to setup development environment for scp?
When I run "make" under pycups directory, it tells me "unable to open /usr/lib/python2.6/config/Makefile"
I haven't had any other reports of pycups failing to build. What system are you trying that on?
The development environment is quite simple. You don't even have to install anything if you just want to run the main application:
Check out pycups and system-config-printer
# If you don't have pycups installed already: cd pycups make ln -sf ../pycups/cups.so ../system-config-printer cd ..
cd system-config-printer make run-applet # for the applet make run # for the main app
But as I said, if you're wanting to try out the automatic printer driver installation you need more than just the system-config-printer changes. Really you need Fedora 13 Beta.
Tim. */
On Thu, 2010-04-29 at 16:22 -0700, George Liu wrote:
Although Port Monitor MIB has been 4-5 years old, it has not been adopted by all printer manufactures. Most Ricoh devices do not support it. Combined with the seven brands we have, Ricoh has 23.1% copier market share in the US in 2009. http://www.ricoh-usa.com/about/press/releases.asp?id=620 I believe Ricoh has similar market share in Europe and Japan as well.
But all these printers do actually have IEEE 1284 Device IDs, don't they? They surely just use other means for providing them. Perhaps there is a different SNMP OID that must be used to query them?
There is precedent in the CUPS SNMP backend for using OIDs outside the Printer MIB, so I expect this is something that could be worked around in CUPS.
Then, the next question become how do s-c-p matches a device to a PPD file. Can you elaborate on this session?
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
We basically do the equivalent of this inside system-config-printer: lpinfo --include-schemes=dnssd,snmp -l -v
Of course we don't actually run that command, instead it is done with an IPP request (via the CupsPkHelper D-Bus mechanism when possible). But the effect is the same: cupsd receives the IPP request, asks its backends to look for devices, and reports the results back.
The snmp backend tries several different OIDs, including the relevant ones from the Printer MIB, to determine the IEEE 1284 Device ID of each printer it gets a response from.
Tim. */
Tim,
I installed Fedora 13 Beta and tried out System-Config-Printer. It's able to find the Ricoh network printers, but unable to find a PPD file.
"lpinfo --include-schemes=dnssd,snmp -l -v" found the following printers. None of the printers support 1284DeviceID MIB. * One with Bonjour support, (I guess CUPS retrieves device-id using Bonjour), * Another without Bonjour support, and CUPS found it using SNMP.
"Search for a printer driver to download" does not return any drivers.
------------------------------------------------------------------------------------- Device: uri = dnssd://RICOH%20Aficio%20MP%20C3500._pdl-datastream._tcp.local/ class = network info = RICOH Aficio MP C3500 make-and-model = RICOH RICOH Aficio MP C3500 device-id = MFG:RICOH;MDL:Aficio MP C3500 location =
Device: uri = socket://172.30.4.243 class = network info = RICOH Aficio MP 2550 make-and-model = RICOH Aficio MP 2550 device-id = location =
-------------------------------------------------------------------------------------
I then tried to build pycups and system-config-printer (Thanks for the instruction).
I run the build version, and it gave me some log messages.
Got PPDs No ID match for device socket://172.30.4.243:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP 2550</model> <description>RICOH Aficio MP 2550</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
Got PPDs No ID match for device socket://172.30.4.173:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP C3500</model> <description>RICOH Aficio MP C3500</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
<manufacturer> and <model> tag for both printers are correct. There's no <deviceid> tag for either of them. Is it right?
Thanks George
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Fri 4/30/2010 3:30 AM To: George Liu Cc: system-config-printer-devel@lists.fedorahosted.org; Till Kamppeter; Bin Li Subject: Re: Tagging PPD package with DeviceID.
On Thu, 2010-04-29 at 16:22 -0700, George Liu wrote:
Although Port Monitor MIB has been 4-5 years old, it has not been adopted by all printer manufactures. Most Ricoh devices do not support it. Combined with the seven brands we have, Ricoh has 23.1% copier market share in the US in 2009. http://www.ricoh-usa.com/about/press/releases.asp?id=620 I believe Ricoh has similar market share in Europe and Japan as well.
But all these printers do actually have IEEE 1284 Device IDs, don't they? They surely just use other means for providing them. Perhaps there is a different SNMP OID that must be used to query them?
There is precedent in the CUPS SNMP backend for using OIDs outside the Printer MIB, so I expect this is something that could be worked around in CUPS.
Then, the next question become how do s-c-p matches a device to a PPD file. Can you elaborate on this session?
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
We basically do the equivalent of this inside system-config-printer: lpinfo --include-schemes=dnssd,snmp -l -v
Of course we don't actually run that command, instead it is done with an IPP request (via the CupsPkHelper D-Bus mechanism when possible). But the effect is the same: cupsd receives the IPP request, asks its backends to look for devices, and reports the results back.
The snmp backend tries several different OIDs, including the relevant ones from the Printer MIB, to determine the IEEE 1284 Device ID of each printer it gets a response from.
Tim. */
Till,
I'm planning to update all Ricoh PPD files (1393 of them) to include "*1284DeviceID". This is part of the effort to make them work with PackageKit.
What should I do to make you able to generate/tag PPD package? I'll put in <ieee1284> tag in each printer.xml file?
Will the PPD package not depending on LSB? How do I specify that the package has dependency on foomatic-rip? There's no fedora package for foomatic-rip?
Which part in the driver.xml file will become package description? <Comment>? <ShortDescription>?
Tim,
If printer does not support 1284DeviceID mib, do you think you can flex s-c-p a bit so it could "generate" deviceID based on make-and-model IPP attribute? I really like to see this part to be enhanced in RHEL6 and Fedora.
Thanks George
-----Original Message----- From: George Liu Sent: Tuesday, May 04, 2010 5:26 PM To: Tim Waugh Cc: system-config-printer-devel@lists.fedorahosted.org; Till Kamppeter; Bin Li Subject: RE: Tagging PPD package with DeviceID.
Tim,
I installed Fedora 13 Beta and tried out System-Config-Printer. It's able to find the Ricoh network printers, but unable to find a PPD file.
"lpinfo --include-schemes=dnssd,snmp -l -v" found the following printers. None of the printers support 1284DeviceID MIB. * One with Bonjour support, (I guess CUPS retrieves device-id using Bonjour), * Another without Bonjour support, and CUPS found it using SNMP.
"Search for a printer driver to download" does not return any drivers.
------------------------------------------------------------------------ ------------- Device: uri = dnssd://RICOH%20Aficio%20MP%20C3500._pdl-datastream._tcp.local/ class = network info = RICOH Aficio MP C3500 make-and-model = RICOH RICOH Aficio MP C3500 device-id = MFG:RICOH;MDL:Aficio MP C3500 location =
Device: uri = socket://172.30.4.243 class = network info = RICOH Aficio MP 2550 make-and-model = RICOH Aficio MP 2550 device-id = location =
------------------------------------------------------------------------ -------------
I then tried to build pycups and system-config-printer (Thanks for the instruction).
I run the build version, and it gave me some log messages.
Got PPDs No ID match for device socket://172.30.4.243:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP 2550</model> <description>RICOH Aficio MP 2550</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
Got PPDs No ID match for device socket://172.30.4.173:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP C3500</model> <description>RICOH Aficio MP C3500</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
<manufacturer> and <model> tag for both printers are correct. There's no <deviceid> tag for either of them. Is it right?
Thanks George
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Fri 4/30/2010 3:30 AM To: George Liu Cc: system-config-printer-devel@lists.fedorahosted.org; Till Kamppeter; Bin Li Subject: Re: Tagging PPD package with DeviceID.
On Thu, 2010-04-29 at 16:22 -0700, George Liu wrote:
Although Port Monitor MIB has been 4-5 years old, it has not been adopted by all printer manufactures. Most Ricoh devices do not support it. Combined with the seven brands we have, Ricoh has 23.1% copier market share in the US in 2009. http://www.ricoh-usa.com/about/press/releases.asp?id=620 I believe Ricoh has similar market share in Europe and Japan as well.
But all these printers do actually have IEEE 1284 Device IDs, don't they? They surely just use other means for providing them. Perhaps there is a different SNMP OID that must be used to query them?
There is precedent in the CUPS SNMP backend for using OIDs outside the Printer MIB, so I expect this is something that could be worked around in CUPS.
Then, the next question become how do s-c-p matches a device to a PPD file. Can you elaborate on this session?
-----------------------------------------------------------------------
If it's a network printer, we use the Device ID that CUPS gives us: to choose a network printer, we ask CUPS for a list of devices from schemes 'dnssd' and 'snmp', and each of those backends reports Device IDs for the network devices they discover, when possible.
-----------------------------------------------------------------------
We basically do the equivalent of this inside system-config-printer: lpinfo --include-schemes=dnssd,snmp -l -v
Of course we don't actually run that command, instead it is done with an IPP request (via the CupsPkHelper D-Bus mechanism when possible). But the effect is the same: cupsd receives the IPP request, asks its backends to look for devices, and reports the results back.
The snmp backend tries several different OIDs, including the relevant ones from the Printer MIB, to determine the IEEE 1284 Device ID of each printer it gets a response from.
Tim. */
On Tue, 2010-05-04 at 18:02 -0700, George Liu wrote:
If printer does not support 1284DeviceID mib, do you think you can flex s-c-p a bit so it could "generate" deviceID based on make-and-model IPP attribute?
As I've mentioned before, I would like to investigate first whether it really is not possible to obtain the real IEEE 1284 Device ID from the device. Printers have been given IEEE 1284 Device IDs for much, much longer than the Printer MIB standard has been around.
Are you saying that Ricoh network printers don't expose their Device IDs at all, via any interface?
Tim. */
Tim,
Unfortunately, not all Ricoh printers supports 1284DeviceID in MIB. Newer laser models, do through private MIB, older laser models and Ink based printers do not expose it through MIB. Different product families (printers using different controllers) may use different MIB also. Ricoh has made quite a few acquisitions in the past...
I'd like to suggest making s-c-p more or less aligned with CUPS mechanism of matching drivers. If user can find a matching driver using CUPS web interface, he/she might expect S-C-P only to do better.
I'd like to propose the following:
1. I'll see whether I can put in Ricoh DeviceIdOID in CUPS. Currently, in cups.1.4.x, only Lexmark is having a special deviceIdOID. 2. Do you think it's possible to build a fall-back mechanism in s-c-p if CUPS cannot find "device-id"? (It's much easier to change PPD file or software than requiring printer firmware change)
Are you planning to go to Red Hat Summit in Boston this June?
Thanks George
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Wednesday, May 05, 2010 4:39 AM To: George Liu Cc: Till Kamppeter; system-config-printer-devel@lists.fedorahosted.org; Bin Li Subject: RE: Tagging PPD package with DeviceID.
On Tue, 2010-05-04 at 18:02 -0700, George Liu wrote:
If printer does not support 1284DeviceID mib, do you think you can flex s-c-p a bit so it could "generate" deviceID based on make-and-model IPP attribute?
As I've mentioned before, I would like to investigate first whether it really is not possible to obtain the real IEEE 1284 Device ID from the device. Printers have been given IEEE 1284 Device IDs for much, much longer than the Printer MIB standard has been around.
Are you saying that Ricoh network printers don't expose their Device IDs at all, via any interface?
Tim. */
On 05/05/2010 07:43 PM, George Liu wrote:
I'd like to suggest making s-c-p more or less aligned with CUPS mechanism of matching drivers. If user can find a matching driver using CUPS web interface, he/she might expect S-C-P only to do better.
s-c-p is better than CUPS in printer/driver matching, I have added a lot of mechanisms which are not available in CUPS.
I'd like to propose the following:
- I'll see whether I can put in Ricoh DeviceIdOID in CUPS. Currently, in cups.1.4.x, only Lexmark is having a special deviceIdOID.
Yes, all known manufacturer/model-specific exceptions should get added, as this is easier to update than updating printer firmware. But independent of this, new printers should adopt the standards (especially IPP Everywhere to be ready for printing from mobile devices).
- Do you think it's possible to build a fall-back mechanism in s-c-p if CUPS cannot find "device-id"? (It's much easier to change PPD file or software than requiring printer firmware change)
I have already implemented such a fallback mechanism which uses the make-and-model string if device-id is empty. Note that I did not yet upstreamize all Ubuntu patches. They are intended to go upstream but I did not find the time yet to actually do it. So check the Ubuntu Lucid version of s-c-p.
Till
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:
Newer laser models, do through private MIB, older laser models and Ink based printers do not expose it through MIB.
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.
I'd like to suggest making s-c-p more or less aligned with CUPS mechanism of matching drivers. If user can find a matching driver using CUPS web interface, he/she might expect S-C-P only to do better.
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. ;-)
- I'll see whether I can put in Ricoh DeviceIdOID in CUPS. Currently,
in cups.1.4.x, only Lexmark is having a special deviceIdOID.
See http://www.cups.org/str.php?L3552 in which HP's OID is suggested.
- Do you think it's possible to build a fall-back mechanism in s-c-p
if CUPS cannot find "device-id"? (It's much easier to change PPD file or software than requiring printer firmware change)
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.
Are you planning to go to Red Hat Summit in Boston this June?
I won't be I'm afraid.
Tim. */
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.
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@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:
Newer laser models, do through private MIB, older laser models and Ink based printers do not expose it through MIB.
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.
I'd like to suggest making s-c-p more or less aligned with CUPS mechanism of matching drivers. If user can find a matching driver using CUPS web interface, he/she might expect S-C-P only to do better.
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. ;-)
- I'll see whether I can put in Ricoh DeviceIdOID in CUPS. Currently,
in cups.1.4.x, only Lexmark is having a special deviceIdOID.
See http://www.cups.org/str.php?L3552 in which HP's OID is suggested.
- Do you think it's possible to build a fall-back mechanism in s-c-p
if CUPS cannot find "device-id"? (It's much easier to change PPD file or software than requiring printer firmware change)
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.
Are you planning to go to Red Hat Summit in Boston this June?
I won't be I'm afraid.
Tim. */
For printers that supports 1284DeviceID MIB, should the whole string like " MFG:RICOH;MDL:Aficio SP C420DN;CMD:PJL,RCS,PCL,PCLXL,POSTSCRIPT,POSTSCRIPT,PCL,PCLXL;" be put into PPD file?
How about if firewall is enabled, and there's no snmp or bonjour dnssd discovery? (which is the default setting in Fedora) How will user find the package?
George
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Wednesday, May 05, 2010 4:39 AM To: George Liu Cc: Till Kamppeter; system-config-printer-devel@lists.fedorahosted.org; Bin Li Subject: RE: Tagging PPD package with DeviceID.
On Tue, 2010-05-04 at 18:02 -0700, George Liu wrote:
If printer does not support 1284DeviceID mib, do you think you can flex s-c-p a bit so it could "generate" deviceID based on make-and-model IPP attribute?
As I've mentioned before, I would like to investigate first whether it really is not possible to obtain the real IEEE 1284 Device ID from the device. Printers have been given IEEE 1284 Device IDs for much, much longer than the Printer MIB standard has been around.
Are you saying that Ricoh network printers don't expose their Device IDs at all, via any interface?
Tim. */
On Wed, 2010-05-05 at 14:14 -0700, George Liu wrote:
For printers that supports 1284DeviceID MIB, should the whole string like " MFG:RICOH;MDL:Aficio SP C420DN;CMD:PJL,RCS,PCL,PCLXL,POSTSCRIPT,POSTSCRIPT,PCL,PCLXL;" be put into PPD file?
Yes, or if you like you can just put the MFG and MDL fields:
MFG:RICOH;MDL:Aficio SP C420DN;
For automatic driver package installation only the MFG and MDL fields are required.
How about if firewall is enabled, and there's no snmp or bonjour dnssd discovery? (which is the default setting in Fedora) How will user find the package?
Like this: http://cyberelk.net/tim/2010/04/15/firewall-adjustments/
Tim. */
Hi George,
On Tue, 2010-05-04 at 17:26 -0700, George Liu wrote:
I installed Fedora 13 Beta and tried out System-Config-Printer.
"lpinfo --include-schemes=dnssd,snmp -l -v" found the following printers. None of the printers support 1284DeviceID MIB.
- One with Bonjour support, (I guess CUPS retrieves device-id using
Bonjour),
Device: uri = dnssd://RICOH%20Aficio%20MP% 20C3500._pdl-datastream._tcp.local/ class = network info = RICOH Aficio MP C3500 make-and-model = RICOH RICOH Aficio MP C3500 device-id = MFG:RICOH;MDL:Aficio MP C3500 location =
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.
- Another without Bonjour support, and CUPS found it using SNMP.
Device: uri = socket://172.30.4.243 class = network info = RICOH Aficio MP 2550 make-and-model = RICOH Aficio MP 2550 device-id = location =
I think this is our best chance for getting an IEEE 1284 Device ID. As you noted, neither this nor the other printer support the Printer MID.
But do they advertise their IEEE 1284 Device IDs via SNMP on another OID?
"Search for a printer driver to download" does not return any drivers.
George, that's something different. That goes directly to openprinting.org, and isn't to do with "automatic printer driver download".
I then tried to build pycups and system-config-printer (Thanks for the instruction). I run the build version, and it gave me some log messages. Got PPDs No ID match for device socket://172.30.4.243:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP 2550</model> <description>RICOH Aficio MP 2550</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
Got PPDs No ID match for device socket://172.30.4.173:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP C3500</model> <description>RICOH Aficio MP C3500</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
<manufacturer> and <model> tag for both printers are correct. There's no <deviceid> tag for either of them. Is it right?
Those are XML versions of attempted Device ID look-ups. It's written confusingly (fixed in git). Without the full '--debug' output it's hard to say exactly what's going on.
Here's what I'd like you to do:
1. Apply the updates (click the star in the GNOME panel's notification area, or run 'yum update'). After doing this, 'rpm -q cups' should say cups-1.4.3-6.fc13.$arch.
2. Disable the firewall (su -c '/sbin/service iptables stop')
3. In the system-config-printer git repository you checked out, run:
./check-device-ids.py
Show me the output.
Thanks, Tim. */
My comments starts with "GL>"
-----Original Message----- From: Tim Waugh [mailto:twaugh@redhat.com] Sent: Wed 5/5/2010 4:33 AM To: George Liu Cc: system-config-printer-devel@lists.fedorahosted.org; Till Kamppeter; Bin Li Subject: RE: Tagging PPD package with DeviceID.
Hi George,
On Tue, 2010-05-04 at 17:26 -0700, George Liu wrote:
I installed Fedora 13 Beta and tried out System-Config-Printer.
"lpinfo --include-schemes=dnssd,snmp -l -v" found the following printers. None of the printers support 1284DeviceID MIB.
- One with Bonjour support, (I guess CUPS retrieves device-id using
Bonjour),
Device: uri = dnssd://RICOH%20Aficio%20MP% 20C3500._pdl-datastream._tcp.local/ class = network info = RICOH Aficio MP C3500 make-and-model = RICOH RICOH Aficio MP C3500 device-id = MFG:RICOH;MDL:Aficio MP C3500 location =
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? 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? When building PPD package, which part of the 1284DeviceID string is supposed to be used to tag the package?
- Another without Bonjour support, and CUPS found it using SNMP.
Device: uri = socket://172.30.4.243 class = network info = RICOH Aficio MP 2550 make-and-model = RICOH Aficio MP 2550 device-id = location =
I think this is our best chance for getting an IEEE 1284 Device ID. As you noted, neither this nor the other printer support the Printer MID.
But do they advertise their IEEE 1284 Device IDs via SNMP on another OID?
"Search for a printer driver to download" does not return any drivers.
George, that's something different. That goes directly to openprinting.org, and isn't to do with "automatic printer driver download".
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?)
I then tried to build pycups and system-config-printer (Thanks for the instruction). I run the build version, and it gave me some log messages. Got PPDs No ID match for device socket://172.30.4.243:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP 2550</model> <description>RICOH Aficio MP 2550</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
Got PPDs No ID match for device socket://172.30.4.173:9100: <manufacturer>RICOH</manufacturer> <model>Aficio MP C3500</model> <description>RICOH Aficio MP C3500</description> <commandset></commandset> Using textonly.ppd (status: 3) Will fetch ppd? 0
<manufacturer> and <model> tag for both printers are correct. There's no <deviceid> tag for either of them. Is it right?
Those are XML versions of attempted Device ID look-ups. It's written confusingly (fixed in git). Without the full '--debug' output it's hard to say exactly what's going on.
Here's what I'd like you to do:
1. Apply the updates (click the star in the GNOME panel's notification area, or run 'yum update'). After doing this, 'rpm -q cups' should say cups-1.4.3-6.fc13.$arch.
2. Disable the firewall (su -c '/sbin/service iptables stop')
3. In the system-config-printer git repository you checked out, run:
./check-device-ids.py
Show me the output.
GL>
Skipping serial:/dev/ttyS1?baud=115200, insufficient data Sending SNMP request to 172.30.4.243 for device-id Skipping socket://172.30.4.243, insufficient data Skipping parallel:/dev/lp0, insufficient data Skipping lpd://172.30.4.228/, insufficient data Skipping serial:/dev/ttyS0?baud=115200, 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 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)
??? RICOH Aficio SP C420DN (socket): MFG:RICOH;MDL:Aficio SP C420DN;CMD:PJL,RCS,PCL,PCLXL,POSTSCRIPT,POSTSCRIPT,PCL,PCLXL; ? (No drivers)
The very latest Ricoh devices supports port monitor MIB (like SP C420DN shown here)
Thanks, Tim. */
On 05/05/2010 08:19 PM, George Liu wrote:
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?)
There are even three methods:
1. Requesting driver packages via device-ID-make-model tags in available packages via PackageKit (currently only used by Red Hat/Fedora)
2. Requesting driver packages through the database on the OpenPrinting web server via Jockey (currently only used on Ubuntu and perhaps also on Debian).
3. On the manual install page of the new printer wizard you cannot only choose make and model foir local drivers or use a locally available PPd file, but you can also let OpenPrinting be searched for your printer and a single PPD file for it be downloaded.
Till
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. */
Tim,
Thanks for the detailed explanation. If it's OK with you, Ricoh will update all 1300+ PPD files and add 1284DeviceID field. (We had a script to generate those PPD files) Is there a timeline by when you absolutely need it done? (Will the package be part of Fedora 13 DVD or just sit in the repository)? Our current plan is get it done in two weeks since you clarified exactly what we need to put in PPD files. (We'll put "MFG:xxx;MDL:xxx;")
(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.)
For the case of "fabricated" device ID done by dnssd, does Fedora 13 treat those as legitimate, and performs the same PackageKit matching algorithm?
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.
We still need that mechanism for devices that does not provide 1284DeviceID. Can you point me to the source code where it does the web query?
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. */
On Thu, 2010-05-06 at 17:35 -0700, George Liu wrote:
If it's OK with you, Ricoh will update all 1300+ PPD files and add 1284DeviceID field. (We had a script to generate those PPD files)
Yes, sure.
Is there a timeline by when you absolutely need it done? (Will the package be part of Fedora 13 DVD or just sit in the repository)? Our current plan is get it done in two weeks since you clarified exactly what we need to put in PPD files. (We'll put "MFG:xxx;MDL:xxx;")
No, there's no real hurry. It's already too late for a new foomatic-db package in Fedora 13 really, so it will be an update anyway at this point. Fedora 13 is already past final freeze: https://fedoraproject.org/wiki/Releases/13/Schedule
(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.)
For the case of "fabricated" device ID done by dnssd, does Fedora 13 treat those as legitimate, and performs the same PackageKit matching algorithm?
Yes. The "FZY" thing is just so I can see from bug reports whether we're dealing with real Device IDs or whether a CUPS backend has invented it.
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. We still need that mechanism for devices that does not provide 1284DeviceID. Can you point me to the source code where it does the web query?
I'm still not convinced that any other mechanism is required once:
1. CUPS backends invent Device IDs for devices that do not provide them but which do provide something akin to make-and-model
and
2. PPDs for affected printers include these invented IDs
For reference, though, the openprinting web query client is in cupshelpers/openprinting.py.
Tim. */
On 05/06/2010 01:47 PM, Tim Waugh wrote:
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.
I think the Jockey approach is still needed, as it allows to access OpenPrinting as one-stop location for querying driver availability. The OpenPrinting database can reference to drivers which are hosted at arbitrary locations. The PackageKit approach which is only based on in-package printer-driver-relation data would need a list of all driver host locations to find drivers. So if a manufacturer introduces a new driver repository, all distributions would need to add this repository to their lists.
Till
I think it's best if openprinting.org become the "trusted" repository for all printer driver packages. Fedora (and other distros) add openprinting.org as default printer driver repository. So there's no need to maintain different packages for each distribution.
-----Original Message----- From: Till Kamppeter [mailto:till.kamppeter@gmail.com] Sent: Fri 5/28/2010 4:25 AM To: Tim Waugh Cc: George Liu; system-config-printer-devel@lists.fedorahosted.org; Bin Li Subject: Re: Tagging PPD package with DeviceID.
On 05/06/2010 01:47 PM, Tim Waugh wrote:
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.
I think the Jockey approach is still needed, as it allows to access OpenPrinting as one-stop location for querying driver availability. The OpenPrinting database can reference to drivers which are hosted at arbitrary locations. The PackageKit approach which is only based on in-package printer-driver-relation data would need a list of all driver host locations to find drivers. So if a manufacturer introduces a new driver repository, all distributions would need to add this repository to their lists.
Till
On Fri, 2010-05-28 at 09:54 -0700, George Liu wrote:
I think it's best if openprinting.org become the "trusted" repository for all printer driver packages. Fedora (and other distros) add openprinting.org as default printer driver repository. So there's no need to maintain different packages for each distribution.
I can't really ever see that happening. It isn't the case for video drivers, or scanners, or webcams, or sound cards, or anything else you can think of, and there is a reason for that.
Fedora is about free software, and if there are drivers which are free software and should be made available to users of Fedora, they ought to be packaged for (and part of) Fedora by Fedora contributors.
Printer manufacturers who want to provide Linux drivers for their printers need only concern themselves with writing and maintaining the actual software, taking advice from the various stakeholders about how best to design it (e.g. CUPS raster driver, CUPS DDK etc).
Once written, the packaging of the drivers for each different distribution comes more or less for free: if there was a brand new free driver for new printers that was not already packaged, *I* would package it for Fedora, Till would package it for Ubuntu, etc etc.
As far as proprietary drivers go, being able to simply click on a link in a web page (to configure and enable a 3rd party repository -- e.g. like Adobe does for flash) and then plug in your printer to have the appropriate drivers installed is quite easy really.
If there were some central list of vendor repositories, perhaps that could be useful for directing the user to the right place.
But how many vendor repositories are there today?
Tim. */
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. */
On Wed, 2010-10-27 at 14:44 -0700, George Liu wrote:
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?
This is the specification: http://developer.apple.com/networking/bonjour/bonjourprinting.pdf
It looks like it should be possible to use the "pdl" field from the TXT record to construct a CMD field, yes. We just need to be able to convert from MIME type names to CMD field names, although there is not (yet) any standard for CMD field names.
Something like:
application/postscript -> POSTSCRIPT application/vnd.hp-PCL -> PCL
This would need to be done in the CUPS dnssd backend.
I've filed CUPS STR #3702 for this. Thanks for the suggestion. http://cups.org/str.php?L3702
Tim. */
system-config-printer-devel@lists.fedorahosted.org
-
George Liu -
Till Kamppeter -
Tim Waugh