[sane-devel] Canon Mx 700 - Scanbuttons

[m. allan noah]

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"