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

[Johannes Meixner]

Hello,

On Feb 23 15:14 Till Kamppeter wrote (shortened):
> 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.

Yes, this would be best.


> In SANE one has at least only one driver architecture, the SANE backends.

... and funny required daemons like PTAL/HPLIP and what else may
occur in the future (in particular for proprietary backends).


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

Don't get confused by the length of the PPD spec.
The spec of the plain PPD syntax is small.
Most in Adobe's PPD spec is description about very printer
specific stuff (which keywords should be used and so on ...).
I am only talking about using the plain PPD syntax.

I think if a new syntax was created, the semantic would be
the same as in the PPD syntax because I think we need all
what is possible with the PPD syntax:
- options (main keywords), choices (option keywords), defaults
- option groups and sub-groups
- user-interface options <-> admin-only options
- constraints
- translation strings
and additionally
- choices for arbitrary user input which matches a regexp
I.e. we could start with the PPD syntax and enhance it.

Because PPD syntax allows adding arbitrary keywords, I think
this is a sufficient extendable format.
But we must agree upon standard main keywords and option keywords
(just like in Adobe's PPD spec).


> - Contain all needed info for each supported model (list of models
>   must be queriable, too):
[...]
> (Please add what I have forgotten).

 o The backend name must also be in a scanner PPD.
   Or should this be just one choice of a "driver" option?

For printing there are almost no PPDs which include different
drivers because of too many constraints. (Only drivers with same
driver optins like "ljet4, lj4dith" are in one PPD.)


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

And you must verify each entry in this additional file for each new
SANE version whether it is still valid :-(
Otherwise it may happen you enter obsolete stuff.

Examples:

In the old Yast scanner setup we set the SCSI device in
<backend>.conf but I detected that at least the hp backend
perfectly autodetects SCSI scanners.
Having a SCSI device like /dev/sg0 in <backend>.conf may cause
problems because the generic SCSI device nodes are assigned in
arbitrary order to the SCSI devices (all USB storage devices
are SCSI devices and get a generic SCSI device node).
If a backend does not do autodetection when the SCSI device
is set in <backend>.conf, the scanner may work or not depending
how many USB storage devices have been connected during
scanner setup and are now connected when using the scanner.

In epkowa.conf there is (or was) by default the line
usb /dev/usb/scanner0
which causes that it doesn't work out of the box with libusb.
Since I changed it in the Suse iscan package to
usb
it works out of the box with libusb because epkowa
autodetects its USB scanners.

As a result I do no longer like to change the defaults in
<backend>.conf because I assume when a backend detects a model
it knows best which settings it must use for this model.
As I do not have all scanner models to verify such settings
(in fact I only have a few models) I think it is safer to rely
on the automatisms in the backend than setting possible wrong
values in <backend>.conf.


Kind Regards
Johannes Meixner
-- 
SUSE LINUX Products GmbH, Maxfeldstrasse 5      Mail: jsmeix@suse.de
90409 Nuernberg, Germany                    WWW: http://www.suse.de/