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. Thanks for your valuable feedback Louis