[lkml]   [2008]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: In-kernel IR remote control support
    On Sat, Nov 15, 2008 at 6:58 AM, Pavel Machek <> wrote:
    > On Thu 2008-11-13 00:09:00, 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.
    > Time to fork lirc...?
    > Can you elaborate? I don't see why IR remotes deserve special
    > handling. I'd expect to just plug in the receiver and have it work as
    > /dev/input/*.
    >> 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.
    > So you make it suck for everyone just because few obscure IR
    > remotes. Perfect enemy of good, I'd say :-(.
    > Can we merge the common ones into the kernel, while still keeping the
    > obscure ones in userspace using uinput or something?
    > I don't see why Jon's work bothers you. He's trying to do the right
    > support for the common remotes. That seems like a net plus to me, and
    > you can still keep the obscure ones in userland.

    We manage to have both kernelspace and userspace USB drivers. I think
    that would be the right approach here, especially since whole classes
    of some remotes change model to model. Apple remotes are an example of
    this: you have to figure out what different signal each new model
    sends and it is really nice for the user to be able to do this and put
    it in a config file and not have to wait for the next kernel version.

    Finding the middle ground here is probably the sanest course.

    > --
    > (english)
    > (cesky, pictures)

     \ /
      Last update: 2008-11-15 17:13    [W:0.025 / U:39.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site