[sane-devel] Simplified installation procedure for Redhat Fedora Linux 1.0 and Epson 1670 scanner, also a report of a bug?
m. allan noah
anoah at pfeiffer.edu
Tue Feb 10 18:30:14 GMT 2004
On Tue, 10 Feb 2004, Henning Meier-Geinitz wrote:
> Hi,
>
> On Mon, Feb 09, 2004 at 03:25:33PM -0500, m. allan noah wrote:
> > sure. but we might still be a ways off from sane2.
>
> It's just a set of options so they can be used with SANE1 without any
> trouble.
other than this whole locking bit...
>
> > also, i dont feel like
> > the proposal gives enough detail about just what each bit of the button
> > bitmap does, or which ones actually exist in the scanner. if the backend
> > could spec names for each bit, then you would not have some
> > trial-and-error to get your front-end to do the right thing on each button
> > press.
>
> We could at least define some standard buttons (scan, mail etc.).
>
> E.g.
> #define SANE_BUTTON_SCAN (1 << 0)
> #define SANE_BUTTON_MAIL (1 << 1)
> #define SANE_BUTTON_FAX (1 << 2)
> [...]
>
> If you want custom descriptions, it won't work that way. What about
> this proposal:
>
> --------------------
>
> "scanner-buttons-lock" is of type SANE_TYPE_BOOL, default = SANE_FALSE
>
> As before. For locking and unlocking the buttons (I don't think it's
> needed but that's a long discussion and there a pros and cons on both
> sides). The backend must make sure that only one frontend has access
> to the scanner buttons of one scanner at the same time.
>
> "scanner-button-*" e.g. "scanner-button-scan" of type SANE_BOOL is a
> read-only option.
>
> If the lock is not active, SANE_STATUS_ACCESS_DENIED is returned.
> Otherwise, if the button is pressed currently (or has been pressed
> since the last read of this option) the value is SANE_TRUE. Otherwise
> SANE_FALSE. The title of the option is the name of the button: E.g.
> "Scan". The frontend should poll this option about once per second.
>
> Several of these options can be defined. All options which names start
> with "scanner-button-" are scanner button options.
>
> ---------------------
>
> Anything I'm missing here?
>
i agree with you about the lack of need for each backend to enable
locking. in a multi-user network situation, that kind of complexity could
be taken care of once in the saned code, not each backend...
as far as option naming goes, that works, but i would rather have a
defined group (like 'advanced' does) for just buttons/sensors, and have an
additional bit that gets or'd with the other SANE_CAP_*, something like
SANE_CAP_SENSOR on a SANE_TYPE_BOOL
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. it also allows the backend to give them nice names, that aren't
preceded with any 'magic' strings of text.
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.
allan
> Bye,
> Henning
>
>
--
"so don't tell us it can't be done, putting down what you don't know.
money isn't our god, integrity will free our souls" - Max Cavalera
More information about the sane-devel
mailing list