lkml.org 
[lkml]   [2008]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2008-11-14 18:41    [W:0.044 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site