SANE2 was: Re: [sane-devel] Infrared channel

Till Kamppeter till.kamppeter@gmx.net
Wed, 23 Feb 2005 15:14:45 +0100


I think, the best is if the backend can spit out this data. Then there 
can never happen that the database and the actually installed backends 
differ from each other.

Having *.desc files, PPDs and the Foomatic database is mostly because 
the drivers itself cannot output this information. In addition, printer 
drivers can have many different architectures: GhostScript built-in, 
filter on bitmap output of GhostScript, IJS driver, CUPS driver, 
PPD-only (PostScript printer). Foomatic builds a unique interface around 
that and so all printers get PostScript printers, with PPD file and 
getting PostScript as input.

In SANE one has at least only one driver architecture, the SANE 
backends. So it would not be very difficult to include appropriate 
querying functions into the SANE2 API.

The syntax of this output should be

- Easily machine-readable, but also human-readable (like PPD, xml, ...)
- Extendable format
- Not based on too complicated standard (PPD specs have > 160 pages)
- Contain all needed info for each supported model (list of models
   must be queriable, too):
   o The scanner model name naturally (human- and machine-readable)
   o Possible connection types
   o Needed kernel modules
   o Needed external software/configuration (like HPLIP for "hpaio"
     backend)
   o Has backend to run as root (for example for direct user-mode access
     to the parallel port)
   o Scanner auto-detection info: USB vendor/product, device name
     returned by SCSI query, ...
   o If scanner setup cannot be done fully automatically, info about
     what manual steps/parameter settings are needed
   o Info whether serial number is queryable (to allow more than one
     of the same model on the same machine)
   o Firmware or other files needed?
   o ICC profiles supported?
   o Options which can be set by the user, including default settings,
     possible choices/ranges, String and password input options must be
     possible, too (PPDs do not support this). All dependent on the
     scanner model.
   o How well is this model supported?

(Please add what I have forgotten).

In addition to provide all needed info to scanner setup and utilities 
and scanning frontends, one could also have the SANE libs on the SANE 
project web server and generate the "Supported Devices" pages on the 
fly. A cron job could rebuild the SANE libs from CVS regularly.

By the way, in Mandrakelinux I let scannerdrake use a database generated 
from the *.desc files and one additional file manually created by me. 
This additional file contains for each backend which lines have to be in 
the config file, dependent on the connection type (SCSI, USB, parallel). 
  The line prototypes contain placeholders where things like USB IDs, 
firmware filenames, ... have to be inserted. Scannerdrake inserts these 
lines when it found the appropriate scanner model (or when the user has 
selected it from the device list) and inserts the appropriate data for 
the placeholders. For the firmware a file dialog shows up and the 
specified file gets copied into /user/share/sane/firmware, then the path 
and name inserted into the backend's config file. On startup 
scannerdrake calls "sane-find-scanner" and then "scanimage -L". It 
compares the output and tries to configure all scanners found by 
"sane-find-scanner" but missing in "scanimage -L". After each 
configuration of a scanner Scannerdrake runs "scanimage -L" to build the 
list of available scanners in the main window. For parallel scanners 
saned is set up to run as root and share to localhost and the "net" 
backend to poll from localhost, so that normal users can use "root-only" 
scanners. scannerdrake has also the possibility to set up network 
scanner sharing via saned/"net" backend.

In Mandrakelinux 10.2 I have added some functionality: Needed kernel 
modules are loaded and added to the modules to be loaded at boot time, 
user is warned if a scanner requires editing the backend's config file, 
and in the list of scanner models unsupported scanners will get a big 
"(UNSUPPORTED)" (some users complained at us that they bought a scanner 
listed bt scannerdrake and when connecting it and clicking on the entry, 
scannerdrake told that the scanner is not supported).

    Till

Johannes Meixner wrote:
> Hello all,
> 
> hello Till,
> I don't know if you followed the "Infrared channel" thread.
> Now I include you explicitely because I think we have come
> to a point where I would like to have you informed.
> 
> I don't know who is the scanner-stuff maintainer at Red Hat.
> 
> The "Infrared channel" thread has changed to a discussion
> about how to enhance the scanner description data which
> is at the moment stored in *.desc source files.
> 
> 
> On Feb 22 12:10 m. allan noah wrote (shortened):
> 
>>>>>i would like to see a few things done in the sane2 standard:
>>>>>3. more consistent config file interface for all backends
>>>>
>>>>I would appreciate this very much.
>>>>
>>>>At the moment all what the Suse scanner config tool does is:
>>>>a) show a list of model names made from the *.desc files
>>>>b) let the user select a model from this list
>>>>c) activate the matching backend in dll.conf
>>>>
>>>>At the moment it is simply ignored when particular models require
>>>>special settings in <backend>.conf
>>>>
>>>>I think we should discuss about an enhanced *.desc file format
>>>>to specify autodetected model strings and model dependent
>>>>parameter settings in <backend>.conf
> 
> 
> Summary for Till:
> 
> I made a proposal to use PPD syntax for scanner description data
> and there is the question whether scanner description data should
> be in seperated files or whether each backend should be called
> in a special mode and then the backend would spit out the
> scanner description data.
> ------------------------------------------------------------------
> [yesterday:]
> For printer setup this problem is already solved by the so called
> "PPD files" which describe printer model specific settings.
> Perhaps it is possible to "misuse" the PPD file syntax for scanner
> setup as well.
> The advantage would be that the PPD file syntax is an established
> standard wich is proved to work o.k.
> 
> [today:]
> Regardless whether we use *.desc files, PPD files, XML files,
> or the backend spits out the data:
> We must agree on one data format for scanner description.
> This data format should be extensible.
> I like the general idea of the PPD syntax.
> I assume manufacturers may like the PPD syntax too because
> manufacturers know how to create PPD files for printers
> and if they can use their existing tools also for scanners,
> I assume they would be happy.
> -----------------------------------------------------------------
> 
> 
>>ok, so here is what i have been working on for the fujitsu backend conf file.
>>i have situations where 2 of the same model of scanner may be connected to one
>>machine, or where the order of insertion of two scanners may be different, so
>>it is difficult to tell which one is where. there are also situations where
>>the scanner is new but similar to an existing model, so being able to tell the
>>backend to treat it as such is nice.
>>
>>so what i have been trying to do is something more like either the syntax of
>>samba's config (with [sections] followed by key=value pairs) or a simple grid
>>with '*' for the missing items (like crontab)
>>
>>ie:
>>
>># /etc/sane/fujitsu.conf
>># global section:
>>default=main_scanner
>>
>>[main_scanner]
>>connection=usb
>>vid=1234
>>pid=5678
>>SN=12345670001
>>fw_file='/etc/fw/blah.bin'
>>vid2=9090
>>pid2=a556
>>SN2=123412341234
>>
>>[sec_scanner]
>>connection=scsi
>>name='Mega Scanner 3000'
>>acts_like='Mega Scanner 2700'
>>
>>this gives a permanent 'name' to a particular scanner, so that if you have
>>more than one scanner on the computer, you dont have to guess which to use.
>>when the user asks for 'fujitsu', you could use the 'default', and go lookup
>>that vid/pid/SN on the usb bus, and upload the firmware, then look for the
>>changed vid/pid/sn
>>
>>if they say 'fujitsu:sec_scanner' then we scan the scsi bus for that name, but
>>after we find it, pretend its a different model.
>>
>>i suppose, if you even went so far, you could make just one of these files,
>>instead of one for each backend, with the sections imported from external text
>>files. this is a big reason i like the ppd or external desc files over the
>>backend having a special mode: you could give someone a ppd that makes their
>>new scanner work with an older backend easily (disable some options, etc)
> 
> 
> Good point!
> 
> The more I think about it the more I like to copy the way
> how it is done for printers - i.e.:
> For each scanner use a PPD file (instead of one <backend>.conf).
> Of course each backend can provide a generic PPD file which
> can be used like <backend>.conf now.
> 
> I think external files and backend special mode do not exclude
> each other:
> The backend in special mode could spit out the PPD files
> (according to internal data of the backend)
> or the PPD files are provided seperated.
> 
> The point is what is used as scanner config file.
> I think there should be one PPD file for each scanner as config file.
> 
> Why do I think PPD files are the right way:
> It is simply the fact that for printers various problems are
> already sloved by using PPDs and why re-invent the wheel?
> 
> Examples of solved problems by using PPDs:
> - Several exactly same models.
> - Several almost same models, e.g. one with ADF, one without
>   (like one printer with duplex unit, one without).
> - Options and choices with one choice being the default/(fallback).
> - Constraints to exclude choices which cannot work together
>   (e.g. for printers: print on transparencies and use duplex mode).
> - Options and choices available for end-user selection (OpenUI/CloseUI)
>   versus options and choices only to be changed by the admin.
> - Option groups and sub-groups (for a nicer user interface).
> - Translation strings (show options and choices in user's language).
> 
> Of course I know that the PPD spec. needs some enhancements:
> - At the moment only fixed lists of choices are possible.
>   Arbitrary user input (which mtches a regexp) should be possible.
> - At the moment only one translation string for one language
>   is possible (i.e. each language requires another PPD).
>   Multiple translation strings for various languages
>   should be possible in the same PPD.
> 
> The above enhancements are needed for printers and there
> are several ideas how to solve them (e.g. as far as I know the
> next major CUPS version defines a 100% PPD spec compliant way
> for multiple translation strings in the same PPD).
> 
> 
> For the future it might become even crucial to use PPDs
> for printers and for scanners:
> This way all-in-one devices (printer/scanner/copier/fax) could
> be supported by one single user frontend.
> - Option groups and sub-groups in the PPD would seperate the
>   options in the user frontend.
> - Options which are meaningless for one function are simply
>   ignored (e.g. you can print without any problem using
>   "lp -d <queue> -o nonsense=doesnotexist <file>").
> Of course not everything is already solved:
> - Fax support requires arbitrary user input to specify the
>   fax number of the recipient.
> 
> 
> Kind Regards
> Johannes Meixner