On Thu, Nov 26, 2009 at 10:58:59PM -0500, Jon Smirl wrote:
> >
> >> Code is only lightly tested. Encoders and decoders have not been
> >> written for all protocols. Repeat is not handled for any protocol. I'm
> >> looking for help. There are 15 more existing LIRC drivers.
> >
> > And there's the ha
On Thu, Nov 26, 2009 at 10:34:55PM -0500, Jon Smirl wrote:
> On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
> > This part... Not so wild about. The common thought I'm seeing from people is
> > that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> > this could be abst
Jarod Wilson wrote:
> On 11/26/2009 08:34 PM, Jon Smirl wrote:
>> Raw mode. There are three sysfs attributes - ir_raw, ir_carrier,
>> ir_xmitter. Read from ir_raw to get the raw timing data from the IR
>> device. Set carrier and active xmitters and then copy raw data to
>> ir_raw to send. These att
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
>> Raw mode. There are three sysfs attributes - ir_raw, ir_carrier,
>> ir_xmitter. Read from ir_raw to get the raw timing data from the IR
>> device. Set carrier and active xmitters and then copy raw data to
>> ir_raw to send. These attributes
On Thu, Nov 26, 2009 at 10:12 PM, Jarod Wilson wrote:
> This part... Not so wild about. The common thought I'm seeing from people is
> that we should be using setkeycode to load keymaps. I mean, sure, I suppose
> this could be abstracted away so the user never sees it, but it seems to be
> reinven
First up, thank you for reposting this. I believe several of us were
keeping this code in mind for the in-kernel decoding portion of this
discussion, but it hadn't been stated outright in the recent threads here.
On 11/26/2009 08:34 PM, Jon Smirl wrote:
This is a repost of the LIRC input patch
This is a repost of the LIRC input patch series I wrote a year ago.
Many of the ideas being discussed in the currect "Should we create a
raw input interface for IR's?" thread have already been implemented
in this code.
---
All of this kernel code i
