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"
