[sane-devel] [lsb-discuss] Scanning interfaces and LSB 4.0

[Olaf Meeuwissen]

Till Kamppeter <till.kamppeter at gmail.com> writes:

> Theodore Ts'o wrote:
>> The simple solution would be add the necessary Scanner interfaces
>> to the LSB.  Unfortunately, we have many other high priority items
>> on our work queue, and the SANE interfaces need to be documented
>> before they could be added to the LSB.  This means we need
>> volunteers to do the following:

I'd be willing to help out here, but your timing is most unfortunate.
I'll be leaving for a holiday on the 24th and will have just about no
internet access (bliss!) until August 18.

FTR, I have been working at AVASYS Corporation on "Image Scan! for
Linux" for the last five years or so and, out of necessity, become
quite familiar with the SANE spec.  "Image Scan! for Linux" is a SANE
frontend/backend combination that caters to Epson scanning devices and
tries hard to be LSB compliant and distribution independent.

FWIW, I am also involved in the OpenPrinting Japan activities.

>> 1) Determine the set of SANE interfaces that needs to be added to
>> the LSB.
>
> Here we would need the complete set of interfaces for a scanner
> driver/backend. Anyone from the SANE developers could tell what
> exactly is needed?

# SANE devels, please correct/add where you think this is necessary.

As an absolute minimum, the following API entries from sane/sane.h
need to be present:

  sane_init
  sane_exit
  sane_open
  sane_close
  sane_get_option_descriptor
  sane_control_option
  sane_get_parameters
  sane_start
  sane_read
  sane_cancel

To support device discovery, the SANE API requires implementation of

  sane_get_devices

but frontends do not need to call it if they have other means to get
at a devicename that backends understand.  In practice this is quite
unlikely, so `sane_get_devices` is pretty much required as well.

Conforming backends also need to implement:

  sane_set_io_mode
  sane_get_select_fd

but can get away with just returning a SANE_STATUS_UNSUPPORTED.  That
is, they do not have to support non-blocking I/O and/or signalling
whether there is data to be read.  As such, I'd say these API entries
are not strictly necessary from an LSB point of view.

# SANE devels, the LSB mandated CUPS API is also a subset of the full
# CUPS API.  There is no need to require all of it to go in.

Finally, there is the `sane_strstatus` API entry that converts an
integer status into a string that I consider optional.  FWIW, the
sane-backends package provides a single implementation for *all*
backends.

Naturally, any types used in the function signatures and all enums
referenced need to be present.  WRT enums, I think the listed values
should be limited to what is in version 1.04 of the SANE spec
document.

# There have been some additions of late that are slated for SANE 1.1
# but those will not be in any of the major distributions by the time
# you want LSB 4.0.

> [snip]

Hope this helps,
-- 
Olaf Meeuwissen                   FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962           sign up at http://member.fsf.org/