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/
