[sane-devel] Re: Device locking, batch scan

Emmanuel Fuste emmanuel.fuste@laposte.net
14 Sep 2002 19:13:53 +0200


About locking:
scanning is state full, when I use my film scanner, I initialise it, I
chose which slot film i will proceed, preview, ajust focus, test gamma
corections, shoot. And I can do batch scanning etc...
Recalibrating the scanner took several minutes too (about 3-5)...
I dont want to have a user moving the film holder between a preview and
the final scan too because he do another job between this time.

You're going to add new states and new options, complexifying things
for nothing than trying to work around uneducated users with a pseudo
staleless mode.

Your batch-scan-loop and batch-next-tl_y # option is interesting but
keep the locking out of the problem. Keep things simples ;-)

For now, I think that the locking of the scanner should be let at the
discretion of the driver. (With the general rule of locking/unlocking at
the begining/end of the session).

For the long run, I vote for a simple locking rule:
 frontend connect -> device locked
 frontend disconnect -> device unlocked
all managed by a saned daemon.
This daemon could optionnaly do: authentication, crypto, queue pending
users ....
This daemon should: disconnect users after an idle timeout.
All user apps (frontend) pass through this daemon, simplifying the case
of a scanner attached to a multi user computer.

Ok, this is only my personnal vision of things :-), I am new to Sane,
and wanted to expose my external view of the problem.

keep us the good work !




>I think the problem is not so hard.
>We need a separate way to allow blocking.
>I am just adding a batch scan mode to xsane. For this
>the frontend needs a possinilty to tell the backend that
>we are doing a batch scan.
>something like:
>option batch-scan-start => first scan
>option batch-scan-loop => we are doing several batch scans
>option batch-scan-end => this is the last scan
>an additional option can helo to speed up things:
>option batch-next-tl_y # => tell the scanner where the next scan begins
>so the scanhead can be moved to this position between the two scans
>(some professional umax scanners do this in the firmware).
>the backend has to lock the device when a scan is done
>with batch-scan-start active and has to unlock the device when
>a scan is done with batch-scan-end.
>In all other cases the backend should only lock between sane_start
>and sane_cancel.
>This is not complete but I think it is a good approach to handle
>batch scans and locking.