On 03.12.21 16:54, Paul Wolneykien wrote: > В Fri, 3 Dec 2021 15:19:16 +0100 > Wilhelm Meier via sane-devel <[email protected]> пишет: > >> 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 <[email protected]> >>> 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 >>>> <[email protected]> wrote: >>>>> >>>>> В Thu, 2 Dec 2021 17:29:13 -0800 >>>>> Ralph Little <[email protected]> пишет: >>>>> >>>>>> 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" >>> >>> >>> > >
