On Tue, 2 Nov 2010 17:12:14 -0400, Jarod Wilson ja...@redhat.com 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
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 ja...@redhat.com 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(),
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't.
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 data
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't.
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
