[sane-devel] sp15c vs. avision backends

m. allan noah kitno455 at gmail.com
Fri Jan 11 02:27:08 UTC 2008

On 1/10/08, jazz_johnson at verizon.net <jazz_johnson at verizon.net> wrote:
> I decided to do some testing on the avision backend with the Fujitsu SP15C.
> The first major difference I've noticed,  is that the avision backend
> monopolizes the scanner so that only one program can use the scanner while
> that program is running, i.e. the first user who runs xsane will see the
> avision/sp15c backends listed, but after they select avision, if another user
> then runs xsane, that user won't see that scanner (neither the avision nor
> the sp15c backends will be listed).
> By contrast, one can run multiple xsane sessions with the sp15c backend. A
> user can even run xsane on one desktop and also execute batch scanning from a
> shell on another, which is very convenient. Imagine you have a pile of
> documents, most of which can be scanned from a batch shell script without
> user intervention, but interspersed throughout that pile are a handful of
> pages which require manual adjustments to gamma/brightness/contrast/color.
> It's convenient to keep xsane open on a desktop for interactively scanning
> these few documents, but to do the bulk of the scanning from a
> non-interactive shell script. And if other users also need to occasionally
> scan something to email or to fax, they can do so from their own xsane
> sessions without interrupting each other.

but only if they coordinate who's documents are on the scanner at that
moment. some backends now implement a locking feature to prevent
exactly this kind of access. it is made possible by the fact that
sp15c.c closes the file handle at the end of attach, and does not
re-open it til sane_start. this comment precedes the call to close: /*
Why? */. Concurrent access is why, i suppose :) With backends that
know how to read scanner sensors and buttons, this means a lot of
opening and closing...


"The truth is an offense, but not a sin"

More information about the sane-devel mailing list