On Thu, 2010-07-29 at 19:26 +0300, Maxim Levitsky wrote:
> On Thu, 2010-07-29 at 11:38 -0400, Andy Walls wrote:
> > On Thu, 2010-07-29 at 17:41 +0300, Maxim Levitsky wrote:
> > > On Thu, 2010-07-29 at 09:23 +0200, Christoph Bartelmus wrote:
> > > > Hi Maxim,
> > > >
> > > > on 29 Jul 10 at 02:40, Maxim Levitsky wrote:
> > > > [...]
> > > > > In addition to comments, I changed helper function that processes
> > > > > samples
> > > > > so it sends last space as soon as timeout is reached.
> > > > > This breaks somewhat lirc, because now it gets 2 spaces in row.
> > > > > However, if it uses timeout reports (which are now fully supported)
> > > > > it will get such report in middle.
> > > > >
> > > > > Note that I send timeout report with zero value.
> > > > > I don't think that this value is importaint.
> > > >
> > > > This does not sound good. Of course the value is important to userspace
> > > >
> > > > and 2 spaces in a row will break decoding.
> > > >
> > > > Christoph
> > >
> > > Could you explain exactly how timeout reports work?
> > >
> > > Lirc interface isn't set to stone, so how about a reasonable compromise.
> > > After reasonable long period of inactivity (200 ms for example), space
> > > is sent, and then next report starts with a pulse.
> > > So gaps between keypresses will be maximum of 200 ms, and as a bonus I
> > > could rip of the logic that deals with remembering the time?
> > >
> > > Best regards,
> > > Maxim Levitsky
>
> So, timeout report is just another sample, with a mark attached, that
> this is last sample? right?
On a measurement timeout, the Conexant hardware RX FIFO has this special
timer overflow value in it as the last measurement:
value = 0x1ffff => a mark with a measurement of 65535 * 4 clocks
(and the measurement before this one in the FIFO is usually the last
actual mark received).
I ultimately translate that to
pulse = false; /* a space */
duration = 0x7fffffff; /* 2.147 seconds */
to give the in kernel decoders a final space.
What is lost is the actual space measurement by the hardware (whatever
65535 * 4 Rx clocks is), before the timeout.
If LIRC likes to measure intertransmission gaps, what I am currently
doing will not give LIRC a reasonable gap estimate/measurement, if the
timeout is shorter than the actual gap.
> Christoph, right?
>
> In that case, lets do that this way:
>
> As soon as timeout is reached, I just send lirc the timeout report.
> Then next keypress will start with pulse.
>
> I think this is the best solution.
I'm flexible. I don't know LIRC internals well enough to know what's
best. I suspect sending a valid space measurement of the timeout,
before the timeout report, may be useful for LIRC to obtain information
on the gaps that are longer than the hardware timeout.
Regards,
Andy
> Best regards,
> Maxim Levitsky
>
--
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
