Messages in this thread | | | Date | 13 Nov 2008 00:09:00 +0100 | From | (Christoph Bartelmus) | Subject | Re: In-kernel IR remote control support |
| |
Hi,
on 12 Nov 08 at 14:39, J.R. Mauro wrote: [...] > On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl <jonsm...@gmail.com> wrote: >> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro <jrm8...@gmail.com> wrote: >>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl <jonsm...@gmail.com> wrote: >>>> New release of in-kernel IR support implementing evdev support. The goal >>>> of in-kernel IR is to integrate IR events into the evdev input event >>>> queue and maintain ordering of events from all input devices. Still >>>> looking for help with this project.
>>> (Forgive me if this has already been asked or dealt with)
>>> Have you contacted the LIRC developers? Is there any overlap between >>> your projects?
>> The LIRC people know about this. Pieces of the code are coming from >> the LIRC source base and being reworked for kernel inclusion.
> Great, it's nice to see there's cooperation.
LOL. There's just a small omission from Jon's side... Yes, LIRC people know about this. And Jon has a no-go from me.
Decoding IR protocols in-kernel is the wrong way IMHO and this will not be supported by LIRC as long as I maintain LIRC. It's simply not possible to decode all existing IR protocols and LIRC just stores the timing data for these protocols as-is without trying to decode them. With the in-kernel decoding approach these remotes cannot be supported. I'm not willing to sacrifice the support for these even though they only consist of a very small fraction of remotes in use.
Christoph
| |