On Wed, Oct 31, 2012 at 8:26 AM, Louis Lagendijk <louis at fazant.net> wrote: > 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 >
Sounds like a good change. Unfortunately, the sane standard is a little weak on buttons, so backend authors have to guess. I would say that button/event reading code should not expect the type to be SANE_TYPE_BUTTON, as some sensors will be able to give integer values. allan -- "The truth is an offense, but not a sin"