> On Mon, Sep 29, 2008 at 4:14 PM, Maxim Levitsky
> <maximlevitsky@gmail.com> wrote:
> > Jon Smirl wrote:
> >>
> >> Second pass at implementing evdev support for IR. 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.
> >>
> >> Note that user space IR device drivers can use the existing support in
> >> evdev to inject events into the input queue.
> >>
> >> Send and receive are implemented. Received IR messages are decoded and
> >> sent to user space as input messages. Send is done via an IOCTL on
> the input
> >> device.
> >>
> >> Two drivers are supplied. mceusb2 implements send and receive
> support for
> >> the Microsoft USB IR dongle.
> >> The GPT driver implements receive only support for a GPT pin - GPT is a
> >> GPIO with a timer attached.
> >>
> >> Encoders and decoders have not been written for all protocols.
> Repeat is
> >> not handled for any protocol. I'm looking for help. There are 15 more
> >> existing LIRC drivers.
> >
> >
> > Hi,
> >
> > One thing worries me, there are bazillion of different IR protocols,
> > but in-kernel decode support will mean that only handful of known
> protocols
> > will work.
> > Suppose I take an old remote which has some unknown protocol.
> > I want to be able to teach the system to listen to it.
> > But how this can be done if protocols are hard coded?
>
> There's not a bazillion different protocols.
>
> For example thirty different vendors may use the NEC encoding. They
> will each use a unique device number and their own commands. While
> each of the thirty vendors may assign different device/command codes
> they are all still using the NEC encoding. These remotes won't trigger
> the other devices because the device fields won't match.
>
> This code only converts raw IR timing of NEC/etc encoding into
> device/command. User space has to then figure out how to interpret
> device/command.
>
> Christoph has pointed out that their are some more obscure encodings
> from RCMM, Grundig, Bang&Olufsen, Goldstar, Serial, Denon, RECS80, and
> Motorola that are different than the common ones at
>
http://www.sbprojects.com.
>
> It takes about 1KB of code to add an encoding. We could make an "extra
> encoding" module for these obscure ones.
>
> You can't have an infinite variety of encodings or table based
> universal remote controls wouldn't work.
>