Hi Alex, > Am 20.10.2020 um 18:59 schrieb Alexander Pevzner <[email protected]>: > > Hi Jürgen, > > On 10/20/20 7:40 PM, Jürgen Mellinger wrote: >> I would like to add "mssing option to poll ADF state" to what is missing >> from the current API. >> With the current API, it is not possible to prompt the user with meaningful >> messages such as "please put a document into the ADF" vs "there is a paper >> jam in the ADF" and similar. > > From my experience with eSCL/WSD scanners > 1) Polling current ADF state BEFORE scan attempt is not reliable > 2) Reporting of ADF-related errors AFTER failed scan attempt is reliable
If so, how does a typical client application behave without confusing the user? Independently of eSCL/WSD, how would one want a frontend behave when talking to a SANE driver? -Jürgen > >> —Juergen >>> Am 20.10.2020 um 10:12 schrieb Alexander Pevzner <[email protected]>: >>> >>> 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. >>> - 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 >>> 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) >>> >>> 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 >>> >>> 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. >>> >>> My list is most likely very incomplete. >>> >>> -- >>> >>> Wishes, Alexander Pevzner ([email protected]) >>> > > > -- > > Wishes, Alexander Pevzner ([email protected]) >
