>> Jon Smirl wrote:
>> 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.
>>
> Yes, in kernel clean/smalls (encoding/)decoding engines abstracted by the
> input subsystem
> are a good thing.
> But you still need a way to send and received raw IR signal to be able to
> send or
> decode very out of spec signals like RC5 timing dependent Philips service
> mode
> codes. Or simply to decode / reverse engineer an IR protocol not already
> implemented
> by a kernel encoder/decoder.
