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

m. allan noah anoah@pfeiffer.edu
Wed, 23 Feb 2005 10:05:52 -0500 (EST)


On Wed, 23 Feb 2005, Till Kamppeter wrote:

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

unfortunately, scanners often work in a fashion similar to printers, the 
model may not have existed at the time the backend was compiled, but it 
will still work with the backend. if our users have the option of going to 
an online db and getting a ppd made for their new scanner, and drop it in 
on their existing backend, then i think the idea is ok. the online db 
would need to be able to say things like "requires sane version xxx" so 
that users wont try to use a new ppd on an ancient version of a backend.

or did you have in mind that the backend would output the ppd when it 
finds the scanner the first time?

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

so this would give us a base directory full of ppd files, one for each 
backend/scanner combination. would this directory be a part of your 
vendor's sane .rpm/.deb?

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

your desc file format would need 2.4 and 2.6 linux kernel modules, as well 
as possibly the same for the bsd's.

allan

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

-- 
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera