[sane-devel] SANE2 standard completion

[m. allan noah]

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.

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

>         Here is a summary of the differences between SANE 1 and SANE 2 proposal standards:
>
>  structures changes:
>         - the SANE_Device struct has more fields, giving contact information about the devices in case of bug, and the ability to send device capability flags

general idea sounds good.

>         - the SANE_Parameters changes to suit the image format improvement. It also gives new informations such as a proposed filename and X/Y dpi.

these should be re-addressed.

>
>  options changes:
>         - capability hidden and allways settable added
>         - more commonly used options are now part of the standard

general idea sounds good.

>
>  SANE operations changes:
>         - sane_open has a SANE_Device ** parameter

sounds good.

>         - scanner's button handling

this is overly complicated, and should be re-examined.

[snip]

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


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

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

>         - there are some issues about backends configuration. In order to be detected, some backends need their  configuration files tweaked. I think that
>  having well-known configuration options would improve  the situation and would
>  also let us have a common way of accessing configuration parameters across
>  backends.

I might be inclined to go a step further and build a common config
file format, with better sanei_config support library that all
backends could use.

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

>         There are other points that I feel they could be improved, but could be done as we develop SANE2:
>         - we need a sane type for scanner buttons. Either we rename the SANE_TYPE_BUTTON to SANE_TYPE_SOFT_BUTTON and use SANE_TYPE_BUTTON for
>  physical buttons, or we create a SANE_TYPE_HARD_BUTTON. So that a frontend can easily detect hardware buttons.

I would rather not override the type, because we then lose the ability
to have a multi-bit sensor use the same facility. i think this is a
proper use for SANE_CAP_HARD_SELECT, or some new capability bit.

 There should be a list of well-known buttons
>  description to use when  possible.
>         - a SANE_TYPE_PANEL would be handy

maybe not required if you use a cap instead of a type- these could be
merged with the buttons?

>         - since there are well-know options there should be well-known groups, and the SANE_CAP of these options should also be given.

ok.

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

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