[sane-devel] Interactive use of scanner buttons

[Paul Wolneykien]

В 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?


> 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"
> > 
> > 
> >