В Fri, 3 Dec 2021 15:19:16 +0100 Wilhelm Meier via sane-devel <sane-devel@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 <kitno...@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 > >> <mano...@altlinux.org> wrote: > >>> > >>> В Thu, 2 Dec 2021 17:29:13 -0800 > >>> Ralph Little <skelb...@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" > > > > > >