[sane-devel] Canon Mx 700 - Scanbuttons

[Louis Lagendijk]

On Sun, 2012-10-28 at 06:15 +0100, Wilhelm wrote:
> Am 27.10.2012 19:34, schrieb Louis Lagendijk:
> > On Sat, 2012-10-27 at 12:25 -0400, m. allan noah wrote:
> >>> I finally found some time to dig into the backend to see what it does
> >>> and how to use it (too many other things to do and been ill for a
> >>> while). I now understand how things work.
> >>>
> >>> The button-1 and button-2 options are set when sane_control_option() is
> >>> called for option button_update with action SANE_ACTION_SET_VALUE.
> >>> SANE_ACTION_SET_VALUE button_update is used to poll the scanner and set
> >>> button-1 and button-2. But scanbd does not support
> >>> SANE_ACTION_SET_VALUE.
> >>>
> >>
> >> The sane standard does not really cover the proper implementation of
> >> buttons, but I would say that the mechanism you described is weird,
> >> and should be changed. Reading the value of the button should do
> >> whatever is required to get the value from the scanner.
> >
> > I agree, it took me a while to get my brain around it. Sending a setting
> > command for one option to initiate a read cache action is funny indeed.
> >
> > But do we not run the risk that changes will break other applications
> > that rely on the current, weird behavior?
> >
> >> It should not
> >> be required to set another option to update the value of the button.
> >> In the case where the value for all buttons is requested in one
> >> command to the scanner, the backend should cache the values as
> >> required. The fujitsu backend uses this scheme, perhaps the code could
> >> be adapted.
> >
> > Well, the caching is done when button_update is set. It should indeed be
> > sufficient to read the buttons and cache the result at that point in
> > time.
> > I will adapt the code accordingly, but leave the button_update stuff in
> > so we do not break anything for other users.
> 
> Does that mean, that reading the button value will reflect the button 
> changes in the future *without* setting the button-update option?
> 
I have the changes in my local git repository and will push these
shortly after some more testing.

Yes, the button status is now updated directly when the option is read.
I have actually (as suggested by Allan) implemented a caching mechanism
that caches all options and where where all options are e-read when an
option is read a second time.
 
> If you change the stuff, do you mind also changing the option-type of 
> button-1/-2 to SANE_TYPE_BUTTON (it is actually SANE_TYPE_INT)?
> 
I am still looking at this. For now I have been able to wrap my brain
around how to read a button option. Do I understand you correctly that a
get operation on a button returns an integer. The documentation does
only state that a button has no value. I see that some backends do
return a value for type button, others don't. GIven the docuemntation I
am not sure. I will wait for others to comment before I make changes
(they would be fairly simple). 

> Is anyone aware of similar operation (setting one option for querying 
> another) in other backends (in that case I would consider updating 
> scanbd to suppport such a schema as well)?
> 
For the pixma backend they are not required anymore....


kind regards, Louis