m. allan noah schrieb: > On Sat, Jan 10, 2009 at 1:11 PM, Pierre Willenbrock > <pierre at pirsoft.dnsalias.org> wrote: >> m. allan noah schrieb: >>> On Fri, Jan 9, 2009 at 5:02 PM, Pierre Willenbrock >>> <pierre at pirsoft.dnsalias.org> wrote: >> [...] >>>> Another question: Is it okay to only look at the hardware state if the >>>> frontend asks for the state of the option? That way shorter presses can >>>> be lost, if the frontend does not poll often enough. >>> In my case, the scanners are smart enough to buffer the button presses >>> for 3 seconds, and I effectively read the status of all the buttons >>> from the scanner every time you ask for the value of the first option. >>> So, as long as the front-end reads within that 3 second window, no >>> presses are lost. >>> >>> If your machines dont buffer, then you might need a thread just to >>> read the status really quickly? Do you know how frequently the windows >>> driver reads the buttons? >> The genesys chips don't help at detecting hardware buttons. The only >> sensor logic in the chip is for the home-sensor. The rest is GPIO. > > Is it possible for a user to press and release the button and have the > driver 'lose' it if you dont read the GPIO pins during the 'pressed' > inteval?
Exactly like that. And the windows driver has the same problem. >> The windows driver polls at 2Hz, this is not much better than the >> polling frequency of sanebuttonsd(1Hz). I'll go for the non-threaded >> variant for now, while making the logic work if the polling function is >> called more often than the sane options are looked at. > > 1Hz from sanebuttonsd has generated some complaints about being too > slow. I think we should bump it up to 2hz, so that might help. > >>>> Before i start to ask more similar questions: Is this documented >>>> somewhere? I looked at the html-version of the standard, but could only >>>> find the capabilities thing for buttons. >>> Nothing is documented. Everything we are discussing now came about >>> from prior threads on this list, and thru several iterations of button >>> support and button daemon work i did for users of the fujitsu backend. >>> IOW, this might not work for your scanners, so we should modify it if >>> required. >> Thanks for your answers, > > NP- > > allan
