Re: In-kernel IR remote control support

[Maxim Levitsky <maximlevitsky@gmail.com>]

Emmanuel Fust wrote:
> Hi,
> 
>  >Christoph Bartelmus wrote:
>  >> Hi,
>  >>
>  >> on 12 Nov 08 at 14:39, J.R. Mauro wrote:
>  >> [...]
>  >>> On Wed, Nov 5, 2008 at 3:07 PM, Jon Smirl wrote:
>  >>>> On Wed, Nov 5, 2008 at 2:59 PM, J.R. Mauro wrote:
>  >>>>> On Wed, Nov 5, 2008 at 2:47 PM, Jon Smirl 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.
>  >+1
>  >
>  >I agree completely.
>  >This way we can make lirc to recognize any remote.
>  >
>  >Don't yet have a general receiver, but when I have one, I would like 
> to use my remotes,
>  >and who knows what protocols they use...
>  >
>  >
>  >Best solution is to make new input layer message, a raw PCM data.
> No, raw PCM data has nothing to do as an input layer message. Is is not 
> an input event.
> 
>  >or, you can even keep the daemon, but make it inject input events back 
> to input system.
>  >
> Exactly as Jon designed it. Use the raw sysfs interface to get raw data 
> and inject input events back to input system.
> 
>  >The only think I don't like at all about lirc is that you need special 
> library to talk
>  > to it while I want remotes to be used as a keyboards.
>  >
>  >Btw, one can write a lirc client that does the above, but this is hackish.
>  >
>  >Some standard ir protocols can be decoded in kernel, but there should 
> be standard
>  > (not debug) way to do so in userspace.
> 
> Call it raw instead of debug and you're done. Lircd will be the main if 
> not the only regular user of this raw interface.
I was under impression that sysfs interface isn't fit for everyday use.
Is it at least possible to receive a continuous stream of data?
Then lets rename it to regular not debug interface.


> 
> Jon did a wonderful jobs, it's thin, simple, clean and fit perfectly 
> with the input system. No more specialized libs. With a little work, 
> existing decoders could cover more than 70% the IR remotes. With more 
> engines, we could rapidly cover more than 95% of know IR protocols. A 
> simplified lircd could at any time cover the rest.
Best regards,
	Maxim Levitsky

> 
> Bests regards,
> Emmanuel.
> ---
> 
> 
> 
> /Créez votre adresse <http://www.laposte.net> électronique 
> prenom.nom@laposte.net
> 1 Go d'espace de stockage, anti-spam et anti-virus intégrés./