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. 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. >> 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, Pierre