Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Jarod Wilson <jarod@wilsonet.com>]

On Nov 27, 2009, at 12:06 AM, Jon Smirl wrote:

> On Thu, Nov 26, 2009 at 11:33 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
>>> In the code I posted there is one evdev device for each configured
>>> remote. Mapped single keycodes are presented on these devices for each
>>> IR burst. There is no device for the IR receiver.  A LIRC type process
>>> could watch these devices and then execute scripts based on the
>>> keycodes reported.
>>> 
> ...
>> 
>> Maybe we should revisit Jon's patchset as well. Regretfully I did not
>> have time to do that when it was submitted the last time.
> 
> Consider my patch set a technology demo starting point. It shows a
> modern architecture for integrating IR into evdev.  Use the input from
> everyone else to turn these concepts into a real design. I wrote the
> code for the fun of it, I have no commercial interest in IR. I was
> annoyed with how LIRC handled Sony remotes on my home system.
> 
> The design is a clean slate implementation of IR for the kernel. No
> attempt was made at legacy compatibility. I was familiar with evdev vs
> /dev/mouse problems from my work on the X server. Because of working
> on X I've also always hated keymaps (that's what drove the configfs
> design).
> 
> I wish one of the set top box or TV manufacturers would step up and
> own this.  They are the ones that would benefit the most. Jarod would
> probably be open to some consulting, right?

Mauro may actually have better connections on that front than I do... Thus far, I've only talked to a few vendors of IR devices, with mixed results getting any sort of support out of them. But its on my todo list to put out some feelers on the work front to see if we have any connections that we might be able to utilize.

-- 
Jarod Wilson
jarod@wilsonet.com