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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
