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