Hi,
On 2021-12-02 2:35 p.m., Paul Wolneykien wrote:
As I can see, XSane doesn't poll the scanner's hardware buttons.
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?
I've grep'ed the mailing list archives a little and it seems that the
main purpose of various button daemons (scanbuttond, scanbd) is to
implement such a facility as "push scan": the user goes to a remote
(possibly, network) scanner, places a standard material into it,
presses a button on the scanner and the system performes an automatic
(that's important!) scan.
It also seems that in other situations, when a user wants to use an
interactive frontend (for making previews, selecting the scan
area, adjusting black and white points and gamma) the scanner is
expected to be placed on the table near PC. Or, at least, that the
material for scan can be placed into the scanner without a need for
further attention (i.e. a sheet material), so the user can set it up
and then back to his/her keyboard and mouse to make a scan or a number
of scans with different settings using the GUI frontend.
These two stories (the "push story" and the "desktop story") are nice
and simple, but are more or less unapplicable in the world of book
scanning!
Firstly, books are all different, so you need to make previews,
select areas and adjust things for each one. Secondly, books aren't
flat, so even if you use a special hardware you almost always need
to handle the book with both your hands!
So, for scanning books, it would be nice to be able to control such a
frontend as XSane with the scanner's hardware buttons. Because most of
the time you can reach the hardware button even if you handle the book
using both hands (however, a configurable delay after the button is
pressed may be helpful option).
(The other possible way to solve the described problem is to use a
separate triggering device. May be a pedal! But that's another story...)
I want to know/discuss, what a design of a button monitor for
use with interactive frontends would fit into SANE better. Any ideas?
Button control has always been lacking in SANE and the Linux scanning
world compared to the Windows counterpart. scanbd is not well documented
and setting it up is not straightforward.
There are two modes that I can think of, that are actually implemented:
1) Button launch - you need some process to monitor/poll for button
presses, then launch a pre-programmed application to perform the
requested function. This would be the scanbd scenario. I have not
experimented with scanbd myself.
2) Scan on button press - some backends allow you to defer the scan
function having launched it in some frontend, until a button is pressed.
The support for this is often provided in the backend and I think this
is a poor solution. The backend should surely just expose the button
press functionality to the frontend.
Surely some work could improve this area.
There are also some other considerations that impinge on this aspect.
Some time ago, I added some functionality to a backend to add support
for a scanner that has a little LCD window that shows a number which you
can increment/decrement with some buttons. This might be used to
indicate a number of print copies perhaps. The backend can now do this,
but for it to be effective in the frontend, the value has to be
regularly polled. xsane can show this value in the Advanced window after
requesting it from the scanner. 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.
I would certainly be happy to see this area improved.
Cheers,
Ralph
