[sane-devel] Interactive use of scanner buttons

[Wilhelm Meier]

There is this old project of mine called "scanbd", the "scanner button
daemon". There wasn't low / no activity in the last year(s), but it is
still functional because it is strictly POSIX conform.

If anyone is interested in taking care of that, I would be very happy.

https://sourceforge.net/projects/scanbd/

Regards,
 Wilhelm

On 03.12.21 15:33, Paul Wolneykien wrote:
> В Fri, 3 Dec 2021 09:02:43 -0500
> "m. allan noah" <kitno455 at gmail.com> пишет:
> 
>> Many backends are single threaded currently, so this would be a pretty
>> invasive change.
> 
>   But that's not a required change, isn't it? If a backend isn't ready
> for it, it just should not add SANE_CAP_DYNAMIC to the options.
> 
> 
>> Frankly, polling over the network once per second is
>> not that much traffic, and certainly easier to implement.
>>
>> allan
>>
>> On Fri, Dec 3, 2021 at 8:50 AM Paul Wolneykien <manowar at altlinux.org>
>> wrote:
>>
>>> В Thu, 2 Dec 2021 17:29:13 -0800
>>> Ralph Little <skelband at gmail.com> пишет:
>>>  
>>>> However, regular polling can be
>>>> detrimental as a general feature. One commentator suggested that
>>>> over a network, this could become an unnecessary bandwidth hog.
>>>> In SANE we would want to add polling features in a generic
>>>> fashion and we should wary of undesirable side-effects. Flooding
>>>> a network just because you are sitting in an idle instance of
>>>> xsane is certainly such an example. It is something that we
>>>> should discuss carefully before enhancing the standard.  
>>>
>>>   Yes, polling over the network is a very bad idea. That means, we
>>> need something like subscribe+notify interface in SANE. What about
>>> the following API upgrade?
>>>
>>>   A new capability for dynamic options (not only the buttons, but
>>> all things that could be changed by the scanner inself):
>>>
>>>   +  #define SANE_CAP_DYNAMIC
>>>
>>>   Then a new action for sane_control_option() indicating we want to
>>> subscribe to scanner-initiated updates of the given value:
>>>
>>>   + SANE_ACTION_SUBSCRIBE
>>>
>>>   Then a function type for a notification handler pointer:
>>>
>>>   + typedef void (*sane_option_change_callback)(SANE_Int option,
>>> void *value);
>>>
>>>   Having these minor API changes, it's become possible to make a
>>> call to sane_control_option() like the following:
>>>
>>>   sane_control_option(sane_handle, option_number,
>>> SANE_ACTION_SUBSCRIBE, my_handler, NULL);
>>>
>>>   And if the option option_number is marked as SANE_CAP_DYNAMIC in
>>> the option descriptor, the backend should setup the given
>>> notification handler and invoke it each time the option is updated.
>>>   For options not explicitly marked as dynamic it should return
>>> SANE_STATUS_UNSUPPORTED. So, no changes are required for the present
>>> backends.
>>>
>>>   How the backend could monitor the option changes? It's up to the
>>> backend. But with the present codebase/hardware polling would be
>>> used most of the time, I guess. That will be, however, a local-only
>>> polling over USB or SCISI interfaces, not a polling over the
>>> network as the backend code runs on the server connected to the
>>> scanner in the client-server scenario. Of course we also need to
>>> implement the proper RPC in order to support callbacks over the
>>> network, but that doesn't affect the backends and doesn't require
>>> more API changes.
>>>
>>>   As to a resident polling process inside the backend, we already
>>> have sanei_thread_*() functions for that.
>>>
>>>  
>>
> 
>