Re: [RFC3] Teach drivers/media/IR/ir-raw-event.c to use durations

[Andy Walls <awalls@md.metrocast.net>]

On Sat, 2010-04-10 at 09:10 -0300, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Sat, 2010-04-10 at 08:48 +0200, David Härdeman wrote:
> >> On Fri, Apr 09, 2010 at 11:00:41AM -0300, Mauro Carvalho Chehab wrote:
> >>> struct {
> >>> 	unsigned mark : 1;
> >>> 	unsigned duration :31;
> >>> }
> >>>
> >>> There's no memory spend at all: it will use just one unsigned int and it is
> >>> clearly indicated what's mark and what's duration.
> >> If all three of you agree on this approch, I'll write a patch to convert 
> >> ir-core to use it instead.
> > 
> > I'm OK with it.
> > 
> > I haven't been paying close attention,so I must ask: What will the units
> > of duration be?
> > 
> > a. If we use nanoseconds the max duration is 2.147 seconds.
> > 
> > If passing pulse measurments out to LIRC, there are cases where irrecord
> > and lircd want the duration of the long silence between the
> > transmissions from the remote. Do any remotes have silence periods
> > longer than 2.1 seconds?
> > 
> > b. If we use microseconds, the max duration is 214.7 seconds or 3.6
> > minutes.  That's too high to be useful.
> > 
> > c.  Something in between, like 1/8 (or 1/2, 1/4, or 1/10) of a
> > microsecond?  1/8 gives a max duration of 26.8 seconds and a little
> > extra precision.
> 
> (c) is really ugly.
>
> (b) max limit is too high. Currently, the core assumes that everything longer
> than one second is enough to re-start the state machine. So, I think (a)
> is the better option.
> 
> Another way to see it: it is not reasonable for someone to press a key and wait
> for 2.1 seconds to see one bit of the key to be recognized.

True enough.


> So, IMHO, let's just use nanoseconds with 31 bits. the sampling event function
> should check for ktime value: if bigger than 2^32-1, then assume it is a
> long event, resetting the state machine.

Sounds OK to me.  Thanks for the reply.

Regards,
Andy

> Cheers,
> Mauro