[sane-devel] Interactive use of scanner buttons

[Wilhelm Meier]

On 03.12.21 16:54, Paul Wolneykien wrote:
> В Fri, 3 Dec 2021 15:19:16 +0100
> Wilhelm Meier via sane-devel <sane-devel at alioth-lists.debian.net> пишет:
> 
>> 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.
> 
>   I've seen it. And I have a question about it:
> 
>>> And if I understand the scanbd manual right, the daemon locks the
>>> SANE interface to the scanner until a button is pressed, and then gives
>>> exclusive access to the scanner for the frontend. So, the daemon is
>>> primarily for launching a frontend, but not for controlling the
>>> frontend while it is running. Am I right?
> 
>   Is that true that the daemon isn't functional while a frontend is
> using the scanner?

Which daemon do you mean?

If no scanning is active, that is no scan-application has connected to
the scanbd-daemon, this daemon is polling the button.
If an application connects, the scanbd starts saned to handle to
connection. When the application ist scanning, no button-polling can be
done (because scanbd releases the device so thant saned can grab the
device). After the scanning the application disconects and scanbd starts
polling again.


> 
> 
>> 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:15, Kelly Price wrote:
>>> Well, that and if the access to the scanner is locked at the saned
>>> level, polling isn't going to tie it up and saned can always return
>>> a "We're busy scanning" signal.
>>>
>>> On Fri, Dec 3, 2021 at 9:03 AM m. allan noah <kitno455 at gmail.com>
>>> wrote:
>>>>
>>>> Many backends are single threaded currently, so this would be a
>>>> pretty invasive change. 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.
>>>>>
>>>>
>>>>
>>>> --
>>>> "well, I stand up next to a mountain- and I chop it down with the
>>>> edge of my hand"
>>>
>>>
>>>
> 
>