[sane-devel] Sane API

[Povilas Kanapickas]

Hi all,

On 10/21/20 4:32 PM, Alexander Pevzner wrote:
> On 10/21/20 3:04 PM, Thierry HUCHARD wrote:
>> 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!
> 
> Because only backends knows, how system events are mapped to scanner PnP
> events.
> 
> Applications should not be responsible to poll USB bus for USB-level
> events, which some knowledge how to distinguish mouse from scanner, poll
> DNS-SD events, with some knowledge, which services are registered by
> scanners and so on.
> 
> May be in printer world it could work, because there are only one device
> class, used by USB printers, and only 3 service types, used by DNS-SD to
> advertise a printer, and these is no such thing as SCSI printer, but
> scanner hardware is MUCH more chaotic.

Can't we just add an additional set of APIs for this use case in e.g.
SANE 1.1? The applications may dlsym these APIs if they want to be
backwards-compatible with SANE 1.0.

>>> - 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
>> possibilities.
> 
> This is UI (user interface) - level decision, our goal is to provide a
> mechanism that makes this decision possible to be implemented.
> 
>>> 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.
> 
> OK, but how?

We already have "x-resolution" and "y-resolution" options. X/Y
resolutions can be handled the same way the non-pecific "resulution"
option is handled right now. That is, application sets the preferred X
and Y resolutions and then must check what actual supported resolution
was selected by the backend by querying these options again.

>>> 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!
> 
> Yes, but in result, every application that care must be aware about all
> existent variants.
> 
> The existent situation needs at least to be documented, and well-known
> names needs to be added to the documentation and C header file.
> 
>> Indeed, sane_read should be allowed to return the scanner data without
>> processing it!
> 
> And it actually affects behavior of some other options and API calls.
> 
> For example, if backend doesn't decode, it should not be obliged to
> return accurate data from sane_get_parameters. List of possible color
> modes could be different for "raw" and decoded modes (in raw mode
> backend may support mode that it cannot decode). Scan region settings
> may or may not work in the "raw" mode. All emulated options unlikely to
> work in the "raw" mode, and so on,

The current standard actually handles a lot of similar problems already.
For example, the capabilities scan modes of a scanner can differ
significantly: transparency scans may offer completely different
resolutions than regular scans, transparency infrared scans may offer
only gray color and the scan boundaries offered by all of the modes may
be different.

I agree that sane_get_parameters will return special values for "raw"
mode, but if application supports "raw" mode, then it will already have
special path for it which could handle sane_get_parameters in a special
way too.

Please let me know if I missed anything.

Cheers,
Povilas