From: Maxim L. <max...@gm...> - 2009-08-09 14:02:27
|
On Sun, 2009-08-09 at 15:47 +0200, Christoph Bartelmus wrote: > Hi! > > Maxim Levitsky "max...@gm..." wrote: > [...] > >> Because LIRC supports gaps up to something around 16 s. You are truncating > >> the gap at maximum_gap. Your driver should support the maximum supported > >> by the interface. That user space applications stop working when you > >> change maximum_gap should have been hint enough that something is wrong. > > Indeed, you are right. > > > > I misunderstood the kernel->userspace interface. > > > > First of all I now assume that I can report several gaps one after > > another, and even several pulses one after another? > > No, you always have to report gaps and pulses by turns. > The first data reported should be a long gap. > > > Second, I assume you want me to do the gap handling in following way: > > > > 1 - first data is recieved, and reported as is. > > 2 - after a fixed timeout (you say 150000 - 250000) I turn off the > > sampler, but I continue to report gaps of arbitrarily lengths, till I > > receive new interrupt from the hardware (and this is done using a timer) > > After let's say 150000 us you turn off the sampler to reduce the interrupt > load. At that time the last data reported was the last pulse, you don't > report the gap yet because you don't know yet how long it will take. When > the next pulse is reported by the hardware you calculate the gap by > measuring the time since the last pulse with do_gettimeofday. Now you know > the final gap value and can report it to user space. Ah, got it now, thanks for clear explanation! Best regards, Maxim Levitsky > > Christoph > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july |