On Mon, Jun 9, 2025 at 2:34 PM Ralph Little <[email protected]> wrote:
> Hi, > > On Mon, Jun 9, 2025 at 11:27 AM m. allan noah <[email protected]> wrote: > >> >> On Mon, Jun 9, 2025 at 12:11 PM Tricia via sane-devel < >> [email protected]> wrote: >> >>> Hi, Dirk. >>> >>> On Mon, Jun 09, 2025 at 01:57:28AM -0700, Dirk Meier via sane-devel >>> wrote: >>> >>> And here, we find that `scan` is now `1` (in technical terms, this means >>> that _while checking_, scanbd found the scan button was being held down. >>> It's possible to press the button so quickly that scanbd misses it while >>> polling...) >> >> >> A point of clarification here- the fujitsu backend attempts to buffer the >> responses from the hardware and returns that buffered response so that >> presses are not lost. But, if the frontend is slow enough in its polling >> loop, I expect that could still happen. I'm not sure what the timing is for >> scanbd >> >> > Yeah, I have seem some machines capture button press events and latch them > in software for the next query, while others only report button presses > live. In the latter case, if you don't query while the button is being > physically pressed, then you just don't see it at all. This is poor design > I believe. It seems to me that it is unrealistic to expect that polling > rate is sufficiently high for reliable detection necessarily. I would > imagine that some Windows drivers are hammering USB ports at a fairly rapid > rate to make this sufficiently responsive which is a bit crazy. > Fortunately, the Fujitsu (now Ricoh) hardware helps too, as it also buffers button presses for a second or two, as long as you do not reset the hardware. These are the sorts of features you get from quality equipment :) allan -- "well, I stand up next to a mountain- and I chop it down with the edge of my hand"
