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
