6:22 p.m.
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.
1. 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.pat...
(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.)
2. 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.
3. 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
4. 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.
*/
5:30 a.m.
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.
*/
7:26 p.m.
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(a)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.
*/
8:02 p.m.
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(a)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(a)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.
*/
6:39 a.m.
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.
*/
12:43 p.m.
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(a)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.
*/
12:51 p.m.
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:
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.
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).
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)
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
5:37 a.m.
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. ;-)
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.
See http://www.cups.org/str.php?L3552 in which HP's OID is suggested.
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)
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.
*/
8:08 p.m.
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(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:
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. ;-)
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.
See http://www.cups.org/str.php?L3552 in which HP's OID is suggested.
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)
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.
*/
4:14 p.m.
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(a)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.
*/
7:42 a.m.
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.
*/
6:33 a.m.
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.
*/
1:19 p.m.
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(a)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.
*/
1:47 p.m.
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
6:47 a.m.
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.
*/
7:35 p.m.
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(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:
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.
*/
12:13 p.m.
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.
*/
6:25 a.m.
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
11:54 a.m.
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(a)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
3:52 a.m.
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.
*/
4:44 p.m.
New subject: 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:
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.
*/
3:55 a.m.
New subject: Construct 1284DeviceID with CMD filed from mDNS record?
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.
*/
4930
days inactive
5112
days old
system-config-printer-devel@lists.fedorahosted.org
21 comments
3 participants
participants (3)
-
George Liu -
Till Kamppeter -
Tim Waugh