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"
