[sane-devel] Sane API

Thierry HUCHARD thierry at ordissimo.com
Wed Oct 21 13:04:44 BST 2020

Le 2020-10-20 10:12, Alexander Pevzner a écrit :
> Hi Thierry,
> On 10/20/20 9:50 AM, Thierry HUCHARD wrote:
>> I went to quickly look at sane-2.0: - I agree with @paddy-hack,
>> making new with old is not necessarily a good thing! - I found that
>> the difference was in the options. The operations are identical. It
>> will be easy for a developer to create a gateway from sane-1.0 to
>> sane-2.0. - The options are hardware dependent and there, some
>> options are emulatable, others are not. - If sane-2.0 is just the
>> formatting of the options, why not do it in sane-1.0?
> Current API misses some essential things, that cannot be implemented
> in terms of options:
> - PnP notifications (scanner was connected/disconnected some time after
> driver was initialized). This limitation can be worked around by
> continuous poll, but this poll drains a battery a generates network/USB
> traffic, so it is better to avoid.

I don't see why notifications should be made by sane.
It is the system that takes care of the connection / disconnection of 
the devices!
USB is supported by udev
For the network, Cups detects the printers, rather than weighing down 
the system it might be a good idea for Cups and Sane to propose a common 
I remain convinced that it is not up to Sane or Cups to do this work but 
to the system!

> - If some scanner is identified by multiple backends, it would be nice
> to let user app to automatically choose one of the list. For this

I'm for leaving the choice to the user, the automatic choice criteria 
are generally subjective choice
criteria (specific to the developer), generally they limit the 

> purpose, it would be nice to expose some information regarding scanner
> location, before scanner is opened (say, "USB bus X device Y, or NET
> addr aaa.bbb.ccc.ddd). It requires adding extra fields to the
> SANE_Device structure, which makes it incompatible with SANE 1.0
> For the following things we just don't have appropriate 
> SANE_Value_Type:
> - Scanner resolution if a form of X*Y pair. This is important, to
> support "asymmetrical" resolutions (300*600, for example)

This change could easily be implemented without SANE-1.0.

> For the following options we don't have enough discipline:
> - SANE_NAME_SCAN_SOURCE. There is no common names for ADF simplex/ADF
> duplex, ADF front/ADF back

It's only discipline!

> sane_airscan_get_parameters() must be accurate immediately after
> return from sane_start(). It is not always possible, unless
> sane_start() has to wait until image is available (compare sane-escl
> and sane-airscan approach).
> sane_airscan_get_select_fd() defined with serious mistake: it requires
> backend to close select_fd immediately after completion or
> cancellation of the scan job. In multi-threaded program closed file
> descriptor could be immediately reused for some different purpose by
> another thread.
> There is no possibility to request image in the device-specific "raw"
> format. I.e., if I want PDF and device can return PDF, image still
> will be repacked PDF->sane format->PDF.

Indeed, sane_read should be allowed to return the scanner data without 
processing it!

> My list is most likely very incomplete.

More information about the sane-devel mailing list