[Printing-architecture] Automatic printer setup with Printer Applications
till.kamppeter at gmail.com
Wed Feb 24 14:17:27 UTC 2021
On 24/02/2021 13:48, Solomon Peachy wrote:
> On Wed, Feb 24, 2021 at 12:25:48PM +0100, Till Kamppeter wrote:
>> udev-configure-printer will need an interface at all Printer Applications
>> where it can send a device ID and the Printer Application answers back
>> whether it supports this printer (with driver name), and that without the
>> Printer Application talking to the physical printers.
> I wanted to add a comment here -- We need to think about what happens if
> multiple applications claim to support the printer, either because more
> than one genuinely does, or because of wildcard catch-all rules for
> "generic PCL" (or whatever) that could bind to any device exporting a
> USB Printer Class endpoint, much like the current CUPS backend.
For this we need support prioritization levels, like "generic" (CMD:
item match), "third-party" (independent driver, like Gutenprint matches
the model), "manufacturer" (manufacturer driver matches the model). The
Printer Application must tell udev-configure-printer with which level it
supports the printer.
> The CUPS backend supports a blacklist so it can exclude printers, but
> given that printer applications can't drop files outside their sandbox,
> a new mechanism would need to be devised.
You probably mean the USB quirks. This is to overcome hardware
> I don't know if there's any reasonable priority rules we could apply
> that would always yield the "correct" choice. Except perhaps to put
> "generic" options at the bottom, but even if those generic options are
> the only ones available, the odds are they won't actually function
> properly anyway.
> BTW, current (RHEL/Fedora) distro practice is to extract the complete
> list of supported printers at "printer driver packaging" time, and use
> that to figure out what package needs to be installed at runtime. IIRC
> this exclusively uses IEEE1284 IDs.
> And as a depressing data point, Gutenprint only has IEEE1284 IDs for
> about 15% of its supported models, and USB VID/PIDs for about 3%. So a
> mechanism to auto-match based on the Manufacturer & Model strings out of
> the USB or IEEE1284 descriptors would still be a good idea..
Here we also need to use make/model matching, independent whether we
have the make/model from a device ID or not.
More information about the Printing-architecture