From The Linux Foundation

Task Priority

Note: Originally suggested for inclusion in LSB 4.0, SANE has been deferred Post-4.0.

Because of incomplete deployment, SANE would have to be a trial-use module for LSB Post-4.0. There are reasons its priority should be higher than that, though. Printer vendors want to ship unified drivers for all-in-one devices, which would include SANE backends. If we don't allow them to otherwise, calls to the SANE ABI would disqualify the driver from LSB certification.

Thus, part of the LSB Post-4.0 work for SANE will include a method for allowing SANE backends to ship in printer driver kits. Resolving this should be high priority, even if the SANE interfaces themselves aren't.

Review Of SANE For LSB Post-4.0

The SANE standard is documented here and includes the API specification here. The current standard version is 1.04. The current API version is 1.0.

The latest package versions available from the SANE project are:

sane-backends   1.0.20
sane-frontends  1.0.14

Note: There is (ever) continuing talk about updating the standard and API versions.

Deployment

The LSB reference platforms ship the following versions of the sane-backends package.

• RHEL5: 1.0.18
• SLES10: N/A
• SLED10: 1.0.17

SANE frontends link dynamically with libsane. In principle, any SANE backend can be used as libsane but in practice distributions use the dll backend. This way, applications can get access to all installed SANE backends.

More information on the various ways in which SANE frontends can use SANE backends can be found here.

Documented Interfaces

There are 14 public API interfaces.

sane_cancel
sane_close
sane_control_option
sane_exit
sane_get_devices *
sane_get_option_descriptor
sane_get_parameters
sane_get_select_fd **
sane_init
sane_open
sane_read
sane_set_io_mode **
sane_start
sane_strstatus **

Additional Information

Feedback on lsb-discuss indicates that not all interfaces are required. Interfaces marked with * are recommended for inclusion and those with ** optional. Note, however, that omitting any of the interfaces from the standard would break the normal deployment scenario where the dll backend provides libsane.

The same feedback also mentioned that types used in function signatures as well as enumerations referenced should be included in the standard. Enumeration values should be limited to those defined in version 1.04 of the SANE standard specification.

Undocumented Interfaces

To accommodate the dll backend's implementation SANE backends normally also provide a second set of API interfaces. This set parallels the documented interfaces and is constructed mechanically.

For a backend by the name of BE this second set of API interfaces is as follows.

sane_BE_cancel
sane_BE_close
sane_BE_control_option
sane_BE_exit
sane_BE_get_devices
sane_BE_get_option_descriptor
sane_BE_get_parameters
sane_BE_get_select_fd
sane_BE_init
sane_BE_open
sane_BE_read
sane_BE_set_io_mode
sane_BE_start
sane_BE_strstatus

Backend names need to chosen so that the above API interfaces are valid C identifiers.

Internal Interfaces

To avoid reinventing the wheel, some internal interfaces are provided as well but backend implementations are free to ignore those. Backends that do use them should link them statically and refrain from exporting these interfaces.

The internal interfaces all start with a sanei_ prefix.

LSB Post-4.0 Work Scope

• Upstream docs may be sufficient - do we need to secure a commitment for a fixed location?
• Add the 14 public interfaces to the database, get appropriate headers, stub libs back out
• Tests for the 14 public interfaces
• Do we need to standardize device setup? There is no USB scanner class so reliable device setup across distributions is problematic. Currently, both udev rules and HAL FDI files are in use and stanzas differ from distribution to distribution.