> On Mon, Sep 29, 2008 at 6:18 PM, Emmanuel Fusté
> <emmanuel.fuste@laposte.net> wrote:
>>> 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.
>
> I've been considering a sysfs interface for raw signals. Specialized
> apps that can handle raw signal could use this interface. It's not
> hard to add support for raw codes, maybe in the next pass. Something
> like a "raw" attribute. Write ints to it and they get sent, read ints
> from it to see what was received.
>
> I'd don't think we should expose raw codes on the main evdev interfaces.
