Messages in this thread | | | Date | Fri, 14 Nov 2008 19:37:55 +0200 | From | Maxim Levitsky <> | Subject | Re: In-kernel IR remote control support |
| |
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./
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |