scanner button discussion, was: Re: [sane-devel] Simplified installation procedure for Redhat F...

[m. allan noah]

> > > > and have an additional bit that gets or'd with the other SANE_CAP_*,
> > > > something like SANE_CAP_SENSOR on a SANE_TYPE_BOOL
> > > 
> > > Is it really a new capability? A button is a typical read-only bool
> > > option that's setable by the user I think.
> > 
> > you could make a case for the buttons to be represented by an opt with a 
> > type = SANE_TYPE_BOOL and cap = SANE_CAP_SOFT_DETECT,
> 
> It's also SANE_CAP_HARD_SELECT.
> 
> > unfortunately, the front-end would need to be signalled that this opt
> > had changed.
> 
> True. And that's the real difference to other options. That's why I
> proposed that "auto-poll" capability.

ok, cool. we are talking about the same thing, i was just thinking that 
'auto' to me means that the backend will do it. 'auto' to you means the 
front-end will. the latter is what i meant, so we agree :)

> 
> > this means the frontend needs to give control to the backend
> > periodically (or the backend needs to run a sep. thread, and signal
> > the frontend) best way that i can see a backend to tell a frontend
> > that this is the case is to add a cap.
> 
> We can only use the polling way as SANE works this way. It's
> completely up to the backend if it uses a theard/process to read the
> button status and set a variable that's read when the button option is
> read from the frontend. Or if it justs sends a "read scanner button"
> command to the scanner whenever the frontend asks for the status.
>

ok, fine. since most scanners have one command that gets the status of 
multiple buttons at the same time, i would recommend the backend writer 
try to use a button reader thread, but maybe provide an option to turn 
that off, and do the command to the scanner when the front-end polls.

i see a problem with this, though. in the case of the fujitsu's little 
screen, the value on the screen along with which button was pushed are 
used together to determine action in the windows sw. with sane, if those 
are polled independently, the values may not coorespond. i guess this 
could be fixed with your suggestion of a re-read before scan or some such. 
or perhaps, a very high refresh rate on the frontend will do it...

> > > Well, maybe add a flag like "auto-poll". That would be a new
> > > capability. But keep in mind that new capabilities are SANE2-only
> > > while new options can easily be added to SANE1 also.
> > 
> > i find that somewhat strange. a new cap out beyond bit 7 of the existing 
> > cap bitmap should not screw up any frontends, right? i am all for 
> > inter-operability, but that would seem to be the point of such a large 
> > bitmap...
> 
> We should check if the frontends can cope with that and if the
> backends set the capabilities to 0 before manipulating them. Both
> should work, so I think you are right.

i hope so.

> Ok, so what about:
> 
> SANE_CAP_REFRESH 128 If set, this capability indicates that the
>                      option value may be cahnged by the hardware at
> 		     any time. The option value should be polled by the
> 		     frontend constantly. The intervall of polling should
> 		     be 0.1 to 5 seconds. This capability can e.g. be used
> 		     for scanner buttons.
> 
> Just an example. It could also be SANE_CAP_POLL or whatever. Or even
> SANE_CAP_BUTTON wven if I don't really like that.

refresh is a fine name. i would like to see a tighter suggested poll rate, 
maybe .2 thru 3 seconds.

> Ok. But we'll need the options as well-known options anyway. Otherways
> the frontends knows that something changed in the hardware but doesn't
> know which button was actually pressed.

i think that the backend should provide the name of the button as written 
on the scanner somehow, and the user be given the option to decide via a 
config in the front end, just what each button will do. this does not 
really require specific option names.

> > even in scanimage, the name is not displayed to the user?
> 
> In this case, it is. But scanimage wouldn't be a good frontend for
> buttons anyway as it doesn't wait for anything.

never assume that scanimage is the only command-line frontend. i can see a 
simple command line prog that _only_ reads the buttons, and exec() to a 
specific program.

allan