On Wed, Nov 03, 2010 at 01:15:30PM +0100, David Härdeman wrote:
> On Tue, 2 Nov 2010 17:12:14 -0400, Jarod Wilson wrote:
> > On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote:
> >> I think the driver could be further simplified by using
> >> ir_raw_event_store_with_filter(), right?
>
On Tue, 2 Nov 2010 17:12:14 -0400, Jarod Wilson wrote:
> On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote:
>> I think the driver could be further simplified by using
>> ir_raw_event_store_with_filter(), right?
>
> And in fact, it is. I've got a new series of patches redone atop you
On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote:
> On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote:
> > We were storing a bunch of spaces at the end of each signal, rather than
> > a single long space. The in-kernel decoders were actually okay with
> > this, but lirc isn
On Fri, Oct 29, 2010 at 09:21:21PM +0200, David Härdeman wrote:
> On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote:
> > We were storing a bunch of spaces at the end of each signal, rather than
> > a single long space. The in-kernel decoders were actually okay with
> > this, but lirc isn
On Thu, Oct 28, 2010 at 11:08:10PM -0400, Jarod Wilson wrote:
> We were storing a bunch of spaces at the end of each signal, rather than
> a single long space. The in-kernel decoders were actually okay with
> this, but lirc isn't. Both are happy again with this change, which
> starts accumulating d
We were storing a bunch of spaces at the end of each signal, rather than
a single long space. The in-kernel decoders were actually okay with
this, but lirc isn't. Both are happy again with this change, which
starts accumulating data upon seeing an 0x7f space, and then stores it
when we see the next
