[sane-devel] Simplified installation procedure for Redhat Fedora Linux 1.0 and Epson 1670 scanner, also a report of a bug?

[Henning Meier-Geinitz]

Hi,

On Tue, Feb 10, 2004 at 04:58:26PM -0500, m. allan noah wrote:
> > > as far as option naming goes, that works, but i would rather have a 
> > > defined group (like 'advanced' does) for just buttons/sensors,
> > 
> > That may also work.
> 
> actually, i will take that back. the 'advanced' options are not in another 
> group, they are a capability.

True. While it's an additional group (or groups) also most of the time.

> > > 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.

> 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.
 
> > 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.

> > A possible extensio would also be a "reread value before scan"
> > capability.
> 
> not bad, but not good enough for my needs, since what we are really 
> talking about is a front-end being activated into some action by the 
> backend.

That was a proposal for yet another capability. It wasn't an
alternative :-)

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.

> > > this enables a front-end to ignore this group of fields (or just show them 
> > > as little fake leds or something) or ask the user which ones they care 
> > > about.
> > 
> > If the frontend knows about the new options it can use any special
> > handling it wants. If it doesn't, it shows the options just as normal
> > read-only bool options. So I don't see any problem here. This
> > detection is possible with all three ways we have discussed (special
> > option name, group or capability).
> > 
> 
> ok, i'll give you that one, other than i have a dislike for encoding data 
> in a string, when the cap is for that very purpose.

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.

> > > it also allows the backend to give them nice names, that aren't 
> > > preceded with any 'magic' strings of text.
> > 
> > These names are not presented to the user anyway so I don't think it's
> > a problem at all to use scanner-button- (or whatever). Using fixed
> > option names follows the "tradition" of well-known options.
> > 
> 
> 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.

> i like using well-known names, but doing string comparisons on the
> beginning of a name sounds like a need for a flag to me, hence the
> suggestion of using a cap.

Ok.

> > You can still use any title you like for the button by using the
> > "title" and add a help text in the "description".
> > 
> > > the fujitsus often have a single digit lcd panel on the scanner, and a 
> > > wheel that the user can use to increas or decrease the reading on that 
> > > lcd. when they press the scan button, the digit on the lcd is also 
> > > transmitted. this could be handled the same way, with cap SANE_CAP_SENSOR 
> > > set on a SANE_TYPE_INT perhaps.
> > 
> > As you say the transfer of that number only happens when pressing the
> > button. So either the backend should set SANE_INFO_RELOAD_OPTIONS when
> > the button status is read and place the number in some read only
> > option or just handle the number internally (brightness?). What I want
> > to say: this panel is different from buttons as cahnging the numbers
> > doesn't start an action on the computer itsself. For reading such data
> > from the scanner we already have read-only options. That's the reason
> > why they exist :-)
> 
> ok, i will agree with that. but just what is going to cause the frontend 
> to call sane_control_option on our button, so that we can set 
> SANE_INFO_RELOAD_OPTIONS on the return?

A cap or the magic option name of the button option.

Ok, so in addition to the above mentioned cap we need some well-known
options for the scanner buttons like "scan", "mail", "fax", "copy".
Any others?

Bye,
  Henning