All of lore.kernel.org
 help / color / mirror / Atom feed
From: Till Kamppeter <till.kamppeter@gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: "printing-architecture@lists.linux-foundation.org"
	<printing-architecture@lists.linux-foundation.org>,
	Gutenprint Mailing List <gimp-print-devel@lists.sourceforge.net>
Subject: Re: [Printing-architecture] RFC: Patch for (libusb-based) USB backend for quirks files
Date: Thu, 18 Jul 2013 23:06:06 +0200	[thread overview]
Message-ID: <51E858BE.8090009@gmail.com> (raw)
In-Reply-To: <9CB486A0-27B4-4A4C-8017-05A9DD56C978@apple.com>

On 07/18/2013 09:05 PM, Michael Sweet wrote:
> Till,
> 
> On 2013-07-18, at 1:51 PM, Till Kamppeter <till.kamppeter@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.

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

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

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

>> This could
>> assure correct automated printer setup in all situations. In addition,
>> it must be assured that when one and the same printer is discovered by
>> various backends that these discoveries can be assigned to that one printer.
> 
> We had a bug tracking this on cups.org, but it got closed without resolution because this turned out to be impossible in the general case.
> 
>> To conform with the files system hierarchy standard your patch needs a
>> small modification: Quirk files need to be searched in two directories,
>> once the one you are already using, /usr/share/cups/usb/, for the quirk
>> files of CUPS itself and of other packages, like Gutenprint, and second,
>> something in /etc/, like /etc/cups/backend/usb/, for rules defined by
>> the local user or admin.
> 
> I really don't want to add more directories, particularly for something that will be an extremely uncommon situation for ordinary users to be dealing with.  Any local changes that *do* get made will presumably end up getting pushed upstream into CUPS proper or into the corresponding driver packages.
> 
> And if there are any people out there still NFS-mounting a read-only /usr filesystem, they'll just need to serve up the same local USB quirks to all users...
> 
> So let's not make this any more complicated than it needs to be.  The primary purpose here is to enable Gutenprint and others to blacklist USB printers that need special love to work and not to enable customization/configuration by the user.

OK, the quirk rules are really not for being configured by end users.
And for temporarily adding rules following the instructions of a
developer in a bug report it is no problem to put the file with them
into /usr/share/cups/usb/.

   Till


  reply	other threads:[~2013-07-18 21:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-17 16:02 [Printing-architecture] RFC: Patch for (libusb-based) USB backend for quirks files Michael Sweet
2013-07-18 17:51 ` Till Kamppeter
2013-07-18 19:05   ` Michael Sweet
2013-07-18 21:06     ` Till Kamppeter [this message]
2013-07-18 23:44       ` Michael Sweet
     [not found] ` <20130801145448.GA10904@shaftnet.org>
2013-08-01 14:57   ` [Printing-architecture] [Gimp-print-devel] " Michael Sweet
     [not found]     ` <20130803011708.GA4773@shaftnet.org>
2013-08-05 14:48       ` Michael Sweet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51E858BE.8090009@gmail.com \
    --to=till.kamppeter@gmail.com \
    --cc=gimp-print-devel@lists.sourceforge.net \
    --cc=msweet@apple.com \
    --cc=printing-architecture@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.