Tagging PPD package with DeviceID.
by George Liu
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.
*/
13 years, 6 months
New Printer dialog as a D-Bus session service
by Tim Waugh
On the code-reorg branch I've now separated the NewPrinterGUI class from
all its dependencies on the main GUI class. This allows the New Printer
dialog to run in its own right, like this:
python newprinter.py
This instantiates the GObject, then runs the main loop until it gets
either of the "dialog-canceled" or "printer-added" signals.
This is not so useful in itself (other than that the code is hopefully a
lot easier to maintain now), but now that part is done it is possible to
have a D-Bus session service that provides a New Printer dialog. This
*is* useful.
For example:
* the applet could use this when a connected printer had no matching
drivers and the 'Search for driver' button in the pop-up is clicked
* the GTK+ print dialog could choose to have an "Add New..." button,
connecting straight to this dialog
I plan to do the same with the Printer Properties dialog.
The code is very simple at the moment, and there is no configuration
file for starting the session service automatically (but that would be
easy to write).
To test it out right now, do this:
python newprinter.py --service
(to instantiate the session service)
and this:
python newprinter.py --client
(to use the service)
The interface is very simple at the moment and WILL CHANGE:
Interface org.fedoraproject.Config.Printing has one method:
STRING NewPrinterDialog()
This returns the D-Bus path of a NewPrinterDialog object. That object
implements the org.fedoraproject.Config.Printing.NewPrinterDialog
interface, which has one method and two signals:
NewPrinter (INT xid)
signal: DialogCanceled()
signal: PrinterAdded(STRING name)
Tim.
*/
14 years
Two new feature branches
by Tim Waugh
I've just pushed two feature branches to the repository. They won't be
merged into master just yet. As master is the feed branch for Fedora
13, and Fedora 13 is in string freeze, that freeze applies to master at
the moment which means I can't add or modify any translatable strings.
I'll create a new 1.2.x branch soon and switch Fedora 13 to it.
In the mean time, I've pushed some feature branches for post-1.2.x:
* no-printers
This branch adds some text and buttons instead of the icon view when
there are no printers to display. If the CUPS server is not running,
and we're trying to connect to the local machine, it gives the
opportunity to start the CUPS service using the D-Bus service
"org.fedoraproject.Config.Services".
* code-reorg
The code is a bit of a mess, so the aim of this branch is to clean it
up. I've gobject-ified the IPP monitor so that it emits signals instead
of doing its own callbacks. The NewPrinterGUI class has been split out
into its own file, but it isn't a particularly clean split: it still
wants to call methods in the main GUI class.
I'd like to make the NewPrinterGUI class into a proper gobject, using
signals to communicate things to the main GUI class.
Then the PrinterPropertiesDialog can be split out similarly.
Tim.
*/
14 years
DNS-SD
by Tim Waugh
I've checked in some changes on 1.1.x and master that slightly change
how we handle devices discovered by the dnssd backend. Now, the device
names are resolved to addresses.
I'm hoping this means that if a device can be discovered by DNS-SD and
by SNMP, we'll be able to spot that the two URIs are for the same
physical device.
Does anyone have access to a printer that is both DNS-SD-aware and
SNMP-aware in order to test that out?
Alternatively, does anyone have access to a printer that is just
DNS-SD-aware, to make sure there are no regressions?
Thanks,
Tim.
*/
14 years
testing
by Jiri Popelka
Hi everybody ;-)
14 years
