[RFC PATCH 0/4] Implementation of IR support using the input subsystem

[RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Jon Smirl]

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.

---

Jon Smirl (4):
      Microsoft mceusb2 driver for in-kernel IR subsystem
      GPT driver for in-kernel IR support.
      Example of PowerPC device tree support for GPT based IR
      Changes to core input subsystem to allow send and receive of IR messages. Encode and decode state machines are provided for common IR porotocols such as Sony, JVC, NEC, Philips, etc.


 arch/powerpc/boot/dts/dspeak01.dts |   19 -
 drivers/input/Kconfig              |    2 
 drivers/input/Makefile             |    3 
 drivers/input/evdev.c              |   55 +++
 drivers/input/input.c              |    4 
 drivers/input/ir-core.c            |  523 ++++++++++++++++++++++++++
 drivers/input/ir/Kconfig           |   26 +
 drivers/input/ir/Makefile          |    7 
 drivers/input/ir/ir-gpt.c          |  214 +++++++++++
 drivers/input/ir/ir-mceusb2.c      |  729 ++++++++++++++++++++++++++++++++++++
 include/linux/input.h              |   70 +++
 11 files changed, 1640 insertions(+), 12 deletions(-)
 create mode 100644 drivers/input/ir-core.c
 create mode 100644 drivers/input/ir/Kconfig
 create mode 100644 drivers/input/ir/Makefile
 create mode 100644 drivers/input/ir/ir-gpt.c
 create mode 100644 drivers/input/ir/ir-mceusb2.c

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Maxim Levitsky]

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?

I think that it would be much better to pass raw ir codes to userspace, and
make it deal with bazillion protocols, and you can always make it auto learn too, and save
results in configuration file.

My .02 cents.

Best regards,
	Maxim Levitsky

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Jon Smirl]

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.


>
> I think that it would be much better to pass raw ir codes to userspace, and
> make it deal with bazillion protocols, and you can always make it auto learn
> too, and save
> results in configuration file.
>
> My .02 cents.
>
> Best regards,
>        Maxim Levitsky
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Emmanuel Fusté]

> 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 think that it would be much better to pass raw ir codes to 
> userspace, and
> > make it deal with bazillion protocols, and you can always make it 
> auto learn
> > too, and save
> > results in configuration file.
> >
> > My .02 cents.
> >
> > Best regards,
> >        Maxim Levitsky
> >
>
>
>
> -- 
> Jon Smirl
> jonsmirl@gmail.com

Best regards,
Emmanuel.

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Jon Smirl]

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.


>
>>
>> >
>> > I think that it would be much better to pass raw ir codes to userspace,
>> > and
>> > make it deal with bazillion protocols, and you can always make it auto
>> > learn
>> > too, and save
>> > results in configuration file.
>> >
>> > My .02 cents.
>> >
>> > Best regards,
>> >        Maxim Levitsky
>> >
>>
>>
>>
>> --
>> Jon Smirl
>> jonsmirl@gmail.com
>
> Best regards,
> Emmanuel.
>
> --
> 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/
>



-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Maxim Levitsky]

Jon Smirl wrote:
> 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.
Just one question,

Suppose I have non-standard remote, and I want to teach lirc to use it,
and I have general purpose receiver, how can I do this?

Best regards,
	Maxim Levitsky


> 
> 
>>>> I think that it would be much better to pass raw ir codes to userspace,
>>>> and
>>>> make it deal with bazillion protocols, and you can always make it auto
>>>> learn
>>>> too, and save
>>>> results in configuration file.
>>>>
>>>> My .02 cents.
>>>>
>>>> Best regards,
>>>>        Maxim Levitsky
>>>>
>>>
>>>
>>> --
>>> Jon Smirl
>>> jonsmirl@gmail.com
>> Best regards,
>> Emmanuel.
>>
>> --
>> 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/
>>
> 
> 
> 

Re: [RFC PATCH 0/4] Implementation of IR support using the input subsystem

[Jon Smirl]

On Mon, Sep 29, 2008 at 7:17 PM, Maxim Levitsky <maximlevitsky@gmail.com> wrote:
> Suppose I have non-standard remote, and I want to teach lirc to use it,
> and I have general purpose receiver, how can I do this?

You need to write an app to use the sysfs interface for raw code. Or
you could write an in-kernel encoder/decoder and use the standard
interfaces. Or you could throw it away and spend $10 for a standard
one.


-- 
Jon Smirl
jonsmirl@gmail.com