[sane-devel] patch for sane-desc.c / new version

[Olaf Meeuwissen]

Dieter Jurzitza <dieter.jurzitza at t-online.de> writes:

> Hi folks,
> nothing lives so long as the change does. Tonight I received a report 
> regarding an Epson scanner promoting itself as "processor", hence I had to 
> modify my patch in order to process this correctly.

There's probably a few more but I don't have a list :-(

FWIW, the epkowa backend considers any EPSON SCSI device with a model
name that starts with one of the following (case insensitive) strings

  SCANNER
  ES
  Expression
  GT
  Perfection

Also, contrary to some remarks in other posts in this thread, new SCSI
scanners are still popping up occasionally.  Some of the not that old
EPSON business scanners (A3 models) have both SCSI and USB interfaces.
I believe these newer models all promote themselves as a "scanner" but
don't know for sure.

> All other deficiencies remained "as is". If this patch is taken for serious 
> as "acceptable" in any means please give me a note how to change.
>
> It is difficult for me to write independent of a distribution because I have 
> one as basis for my work - and I am lacking the in-depth knowledge of why and 
> how changes are applied and what impact those changes do have.

Use the source from CVS :-)

> Please be patient :-).
>
> Several hints came from Julien Blanche, I wonder if it would be a prerequisite 
> to integrate this into the desc files someone of the more experienced could 
> tell me _how_ to do this exactly.
>
> Moreover I have understood in the meantime that there is already a parser for 
> the .desc files in sane-desc.c, so the question would be how to create and 
> fill the SCSI-array (as I hardcoded in sane-desc.h) in the same way as it 
> happens for the USB-array. This would imply a decision how to include which  
> strings into the desc-files.
>
> Starting from hp.desc it would require three additonal entries:
> 1.)
> :processor (marking the device as processor, those are the devices that cause 
> issues)
> 2.)
> :scsimfg "HP" (how is the manufacturer promoted on the SCSI bus, this may 
> differ from the "normal" manufacturer's name,
> 3.)
> :scsimodel "C7670A" (how is the name promoted on the SCSI bus, this will 
> differ from the "normal" name as well).

For USB the syntax is

  :usbid "<vendorID>" "<productID>"

so I'd say something more in line with that might be a better idea.  I
don't really like the idea of _three_ additional entries.  How about

  :scsi ["<vendor-name>" ["<model-name>" ["<type>"]]]

where the line may only be present if SCSI is listed as an :interface
and is required for "processor"s.  All of the following arguments are
optional.  For <vendor-name> and <model-name> the default is whatever
the device advertises.  The default <type> is PROCESSOR.

An empty string corresponds to the default.  This conventions enables
specification of a <model-name> while keeping the <vendor-name> at the
default.

Other ideas are of course welcome.

> When parsing the file the parser would have to test for the "processor" entry, 
> then write it into the array - this time not static but dynamically 
> allocated, the further steps could remain as they are now.
>
> The naming convention just came to my head - nothing I would insist to use.

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2           FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962               Help support software freedom
                 http://www.fsf.org/jf?referrer=1962