Hello, On Feb 22 11:29 m. allan noah wrote (shortened): > > 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.
I forgot to mention that we do some guessing which models actually require firmware upload and if yes we show a message to the user. As we cannot distribute firmware it would not help to know the syntax how to specify firmware upload in <backend>.conf simply because we cannot provide the firmware. I.e. in case of required firmware upload the user must set up his device manually. Firmware upload is a good example of missing information in the *.desc files: a) As far as I know all scanners which use the backend gt68xx and the related backend artec_eplus48u require a firmware upload, I read "man sane-gt68xx" and "man sane-artec_eplus48u" and http://www.meier-geinitz.de/sane/gt68xx-backend/ but I cannot be sure because there might be scanners which use those backends but have built-in firmware. b) As far as I know all USB scanners (but not the SCSI scanners) which use the backend snapscan require firmware upload according to "man sane-snapscan" and http://snapscan.sourceforge.net/ but again I cannot be sure because there might be SCSI scanners without built-in firmware or USB scanners with built-in firmware. c) There might be other scanners which require firmware upload but when it is not mentioned in "man sane-<backend>" I would miss such models. If the location of the firmware on the manufacturer CD is fixed and known then the location should be in the *.desc file so that a config tool could get the firmware from there. If the manufacturer provides firmware explicitely under a free license for download then the URL should be in the *.desc file so that a config tool could download the firmware. > 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. Of course. At the moment the problem for a scanner config tool is that the backends do their stuff somehow "secretly". Therefore all a scanner config tool can do is to activate the backend in dll.conf and hope for the best. > > 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.). > > you could write a sane backend that did this, but you would need > one for every different network transmission proto. As the manufacturers of such devices should do it, it is perfectly o.k. when each kind of network-scanner needs a matching backend. It is the same as for the different kind of desktop scanners. To set up many network-scanners in a business environment there would be a scanner-server with a saned running and the user workstations would only run the net meta-backend. It is very similar to printing. Even security (of saned) is not such a big problem. When the users must have physical hardware access, you must be in a trusted environment (internal network). Kind Regards, Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5 Mail: jsm...@suse.de 90409 Nuernberg, Germany WWW: http://www.suse.de/
