[Printing-architecture] RFC: Patch for (libusb-based) USB backend for quirks files

Michael Sweet msweet at apple.com
Thu Jul 18 23:44:26 UTC 2013


On 2013-07-18, at 5:06 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> On 07/18/2013 09:05 PM, Michael Sweet wrote:
>> Till,
>> On 2013-07-18, at 1:51 PM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
>>> ...
>>> What I would like to see is the possibility to have quirk rules (or at
>>> least blacklisting) also for other backends.
>> Such as?
> There printers claiming to support IPP but they do not work with the
> "ipp" backend. If one would blacklist them for the IPP backend, they
> would automatically get used with the "socket" or "lpd" backend.

Not sure how we would do that automatically; unless you are using Bonjour to find the printers, there is no way for the IPP or SNMP backends to know whether they can redirect to LPD or socket.  And for Bonjour the priority in the TXT record can already be used to prefer LPD or socket (most older printers with buggy IPP stacks do anyways)

>>> Also the prossibility to
>>> prioritize backends via a directory of files would be great.
>> The problem with priorities are:
>> 1. How do you identify identical devices?
> For USB by the device ID and the serial number, for network by
> determining the printer's IP address. We assume that in production
> environments no printer is connected by network and by USB at the same time.

In order to get the printer's IP addresses (yes, multiple ones) you need to resolve it. For Bonjour that means waking the printer up (or all printers, in the case of discovery). For obvious reasons I (and all of Apple) is against that kind of solution.

>> 2. Whose priority wins? (the user's priority, the manufacturer's priority, the developer's priority, the system's priority, the site's priority?)
> Default would be the degree of sophistication (or usefulness?) of the
> backends: IPP > Socket > LPD. Ech backend gets a priority index, for
> example 300 for IPP, 200 for Socket, and 100 for LPD. Quirk rule files
> could for given printer models blacklist them for a backend or change
> the priority index for a backend. Third-party backends could place
> themselves in the default priority order by having their own priority index.

Really, I don't want to encourage more network backends for special protocols that vendors think they need.  I'd much rather see any special backends (should they actually be needed) report special device IDs that can be used to match them to their corresponding driver.  And printers that need to use special protocols should not advertise support for any of the standard protocols since they obviously don't work.

> Quirk rules could also activate workarounds for incompatible printers in
> the IPP backend.

Um, no.  I'm quite done adding workarounds for broken IPP implementations.  Every workaround makes it harder to maintain the backend, and in 1.6 I did a sweep and removed all but a couple of the most common and least costly to support.

Moreover, most printers that support IPP also support firmware upgrades, so we can't have a simple quirks file approach to workaround bugs anyways - you'd need to know the firmware name/version (sometimes available via SNMP, hopefully available in the near future over IPP) as well as the make-and-model information.  The same can't be said for USB printers which is why I am OK with the quirks list.

Michael Sweet, Senior Printing System Engineer, PWG Chair

More information about the Printing-architecture mailing list