[sane-devel] SANE2 standard completion

[Rene Rebe]

Hi Allan,

On 28.03.2008, at 14:46, m. allan noah wrote:

> On Thu, Mar 27, 2008 at 1:22 PM, stef <stef.dev at free.fr> wrote:
>>        Hello,
>>
>>        before any work can start on SANE 2, the current proposal  
>> has to be completed.
>
> and before we can complete it, we must acknowlege that it has not been
> touched in 5 years, and many of its contributors are no longer active,
> and many current sane devels (myself included) were not party to any
> of the discussions.

Actually I was active the time but never saw a need for an incompatible
change that has zero benefit for the 150++ scanners my Avision backend
supports and just consumes more of my time.

Right now the only thing I miss are marks for infra-red frames, and  
maybe
a ability to pass duplex data without buffering the rear side, which  
becomes
even more of a problem with the next generation, higher end devices I  
got
here on my desk due to the immense amount of data generate at that
speed (I got prototypes of future products here, so I can not name  
numbers,
but the current devices already support up to 60 pages per minute, which
are 120 images per minute, so you can imagine ...).

Buffering and reading that data just needlessly consumes CPU cycles and
contribute to data processing gaps between the pages.

Btw. I think the consumer scanner market is falling away anyway, because
the main use to scan photos is no longer needed with the rise of digital
cameras. So API innovation are most required for the mostly remaining
need where the document are in use and we need to process more
data with less overhead.

>>        The major change is the image data format. SANE 2 will be  
>> able to handle new formats easily (which matches the current needs,  
>> especially regarding ir
>>  channel). There will be 2 major image format, one pixel oriented  
>> and the other will give images as a mime attachment. There is also  
>> standard part for button handling.
>
> but the mime type code creates new problems. it will allow any backend
> to produce any kind of output that it wishes, as long as there is a
> mime-type for it. frontends will never know what to expect. I would
> much rather produce a list of known frame types, and put a note in the
> standard that frontend devels should expect new types to be added.
> this enables us to specify exactly how common types will be presented.

Ack
.
>>        - scanner's button handling
>
> this is overly complicated, and should be re-examined.
>
> [snip]

Ack.

>>        But before starting, there are some things I'd like to see  
>> in the new standard:
>>        - the current code flow is
>>        sane_init
>>                sane_open
>>                        sane_start
>>                                sane_read
>>                        sane_cancel
>>                sane_close
>>        sane_exit
>>
>>                rather than calling sane_cancel at the end of scan,  
>> I'd like to have a sane_end function. Leaving the use of  
>> sane_cancel for canceling the scan like it allready does. This new  
>> function would do about the same, but code flow would be cleaner  
>> and easier to understand:
>>        sane_init
>>                sane_open
>>                        sane_start
>>                                sane_read
>>                        sane_end
>>                sane_close
>>        sane_exit
>>
>
> this is a simple, single scan case. can you draw up what you think an
> ADF or duplex scan would look like? right now, it does sane_start,
> sane_read, sane_start, sane_read, sane_start, sane_read,

I do not see a problem in this call graph. Sure, we could leave the
cancel (or rename it to _end :-), however existing codebase like
frontends (applications) have deal with the current API and
backends (drivers) anyway. This is what I mean when I declare
unnecessary work. The gain is just a little nicer callgraph on
the paper.

>>        - the proposed button handling would surely be better if we  
>> create sane_lock_buttons(), sane_update_buttons() and sane_unlock()  
>> buttons, instead
>> of doing this with control options.
>
> i have implemented button support in the fujitsu backend without any
> locking at all, and it works well, and is compatible with SANE1. Maybe
> i am missing something, but i dont see the need for the complication.

Ditto for the Avision backend.


>>        - we should also add something about panels. Would some  
>> control options be enough,  or do we also need some lock/update/ 
>> unlock behavior ?
>
> Control panels vary so widely between scanners, that i dont know if we
> can build a generic facility to support them all. can you give some
> examples?

Yes, they differ a lot. From profile selection of current Avision (and
OEM) devices, to simplex duplex buttons, to even whole resolution
and color selection of the HP 7400 even in the Avision family of
devices.

I finally support this  (except the 7400 which I did not found spare
time for) by just having a single message option in the Avision
backend and decoding anything the scanner might like to tell
the application, like:

4, simplex, 300dpi, ...

(usually just the profile number on mayority of devices).

I decide to go this road as in practice is found it cumbersome
to train every frontend the multitude of possible option. An
application (our own server thing or other stuff) can pick up
whatever it can parse from the IIRC comma separated tokens.

>>        - do we want to improve warmup handling ? Currently there is  
>> no feedback when warming-up is going on, which is sometime  
>> confusing, we can have the feeling that nothing is happening. Do we  
>> want a sane_warm_up() or a
>> SANE_STATUS_WARMING_UP would be enough ?
>>
>
> i would be inclined to use the status value, and perhaps a note in the
> spec that the frontend should retry? this enables a backend to send
> warm up during sane_start, or first sane_read, or even sane_open i
> guess.

So Ack.

A warmup status code would indeed be useful and is what I already
have ifdef'ed in the avision backend. But we do not need a complete
SANE rewrite for this.

>>        - a SANE_STATUS_LOCKED could be added to handle the case  
>> where the hardware lock of a scanner has been left.
>
> agreed. though not all machines can detect the lock.

Yep, and still nothing we need all the other changes for.
We could add the single value, most frontends compare for
!= SANE_STATUS_GOOD anyway, and do some sane_strstatus()
or alike otherwise and name it SANE 1.1, 1.2, 1.3, ...

Yours,

-- 
   René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name