Re: [Printing-architecture] Automatic printer setup with Printer Applications

[Till Kamppeter <till.kamppeter@gmail.com>]

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 
incompatibilities.

> 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.

    Till