[sane-devel] Canon Mx 700 - Scanbuttons

[m. allan noah]

On Wed, Oct 31, 2012 at 4:51 PM, Louis Lagendijk <louis at fazant.net> wrote:
> On Wed, 2012-10-31 at 08:47 -0400, m. allan noah wrote:
>
>> >> 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
> Hello all,
> Strictly speaking accoding to the sane abi doc (sane.ps) buttons do not
> have a value (Page 20: An option of this type has no value. Instead,
> setting an option of this type has an option-specific side effect.
>
> Page 21: SANE_TYPE_BUTTON, SANE_TYPE_GROUP: the option size is ignored
>
> If a BUTTON can RETURN a value, we need to correct both places:
> P20 only talks about SETTING a value, but does not discuss GETTING the
> button, but P21 seems to suggest that reading is pointless.
>
> to me this looks as if the button-type is only meant to SET a (boolean)
> option and never can be read. But then it has only a subset of
> characteristics of the BOOL type (it is actually a boolean with implicit
> encoding: leaving it out indicates a false, sending the option, but no
> value, means a true, yes I come from a background where ASN.1 is used).
>
> To me it still looks as if a boolean or integer encoding are  most
> appropriate. So I prefer to leave the buttons as integers (although they
> are now strictly speaking booleans, as I moved the original and target
> parameters to own options
>
> Comments?
>

My comment is that the SANE_TYPE_BUTTON does not describe a hardware
button. It describes a software button, like 'eject paper' or some
such.

allan
-- 
"The truth is an offense, but not a sin"