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

m. allan noah anoah@pfeiffer.edu
Tue, 22 Feb 2005 11:29:59 -0500 (EST)


> On Feb 22 09:16 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
>

unfortunately, this can be difficult to deal with, since what each model 
needs can vary drastically. cheaper models that require firmware to be 
loaded come to mind, and some models do crazy things like change usb ID or 
name after the firmware is loaded.

>
>> 4. better integration with hotplug and multiple scanners of the
>> same type active at the same time.
>
> This is a related problem.
>
> In many cases the autodetected model string does not match to
> the model name in the *.desc file.
>
> Therefore it is normally not possible to determine the matching
> backend from the autodetected model string.
>
> I think we should discuss about an enhanced *.desc file format
> to specify autodetected model strings and model dependent
> parameter settings in <backend>.conf
>
> 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.
>

ok, i have played with ppd only a little, but it does seem to work. the 
problem comes with new scanners, or re-badged scanners. the current system 
of loading every backend in turn, and letting them use a back-end specific 
way to determine if they support the scanner gives us more flexibility 
than a ppd file for each know model.

no, that said, i notice that quite a few backends just string compair to 
determine this info, so the ppd file would be no different, except that 
the 'string' is not always in the usb descriptor or scsi inq request...

>
>> anything i missed?
>
> Is there any special stuff needed to support big and fat
> printer/scanner/copiers in the network?
>
> In contrast to the small directly connected desktop scanners
> such big and fat network-scanners can do the scanning (almost)
> on their own.
> I.e. the user can go to the printer/scanner/copier and do
> the scan only by using the buttons and the display which
> is integrated in the device.
>
> All what such a network-scanner needs is a recipient
> to which it can send the data of the scanned image.
> Some of those device may even have a built-in disk
> to store the images and the user could scan many images
> and later the user would like to download the images from
> the printer/scanner/copier to his workstation.
>
> At the moment the recipient is normally a mail account
> to which the printer/scanner/copier sends the image.
>
> But it would be nicer if the image download could be done
> via a SANE backend and/or if the printer/scanner/copier
> could use this backend as recipient for the image data.
>
> I would like when the manufacturers of such devices could make
> SANE backends easily - i.e. the SANE frontend must support
> to connect to a network-scanner (e.g. specify the IP address
> and the port etc.).
> I think it doesn't work to tell the manufacturers they should
> implement a "saned" which runs in their network-scanners
> because I think they won't change the firmware.
>
>
> Kind Regards
> Johannes Meixner
>

you could write a sane backend that did this, but you would need one for 
every different network transmission proto.

allan

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