public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jon Smirl <jonsmirl@gmail.com>
To: linux-kernel@vger.kernel.org, lirc-list@lists.sourceforge.net
Subject: [RFC PATCH 0/4] V3 - Implementation of IR support using the input subsystem
Date: Mon, 06 Oct 2008 15:43:06 -0400	[thread overview]
Message-ID: <20081006194032.15992.8393.stgit@terra> (raw)

Third 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.

New feature, raw mode. There are three sysfs attributes - ir_raw, ir_carrier, ir_xmitter. Read from ir_raw to get the raw timing data from the IR device. Set carrier and active xmitters and then copy raw data to ir_raw to send. These attributes may be better on a debug switch. You would use raw mode when decoding a new protocol. After you figure out the new protocol, write an in-kernel encoder/decoder for it.

What should the IR API look like? 

How are IR events mapped into keyboard events? Should they be mapped? Map them in the kernel or in user space? The maps are tiny, less than 1K per remote.  Sysfs can be used to load maps into the kernel driver. Make maps only for the common buttons and don't map unusual ones?

How should multiple remotes be handled? Split them out into individual input devices, or group them onto a single IR device? I can implement either.

The in-kernel code is tiny, about 20K including a driver.

>From last post...
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.

Code is only lightly tested. 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
      Example of PowerPC device tree support for GPT based IR
      GPT driver for in-kernel IR support.
      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              |   21 +
 drivers/input/ir-core.c            |  659 ++++++++++++++++++++++++++++++++
 drivers/input/ir/Kconfig           |   26 +
 drivers/input/ir/Makefile          |    7 
 drivers/input/ir/ir-gpt.c          |  221 +++++++++++
 drivers/input/ir/ir-mceusb2.c      |  741 ++++++++++++++++++++++++++++++++++++
 include/linux/input.h              |  101 +++++
 include/linux/mod_devicetable.h    |    3 
 12 files changed, 1846 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

             reply	other threads:[~2008-10-06 19:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-06 19:43 Jon Smirl [this message]
2008-10-06 19:43 ` [RFC PATCH 1/4] 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 Jon Smirl
2009-05-28 23:23   ` Maxim Levitsky
2009-05-29  1:15     ` Jon Smirl
2008-10-06 19:43 ` [RFC PATCH 2/4] GPT driver for in-kernel IR support Jon Smirl
2008-10-06 19:43 ` [RFC PATCH 3/4] Example of PowerPC device tree support for GPT based IR Jon Smirl
2008-10-06 19:43 ` [RFC PATCH 4/4] Microsoft mceusb2 driver for in-kernel IR subsystem Jon Smirl
2008-10-06 19:46 ` [RFC PATCH 0/4] V3 - Implementation of IR support using the input subsystem Jon Smirl
2008-10-09 12:03 ` Pavel Machek
2008-10-10  4:11   ` Jarod Wilson
2008-10-10  5:04     ` Jon Smirl
2008-10-10 13:42       ` Jarod Wilson
2008-10-10 14:08         ` Jon Smirl
2008-10-10 21:10           ` Jarod Wilson
2009-05-28 15:06 ` Maxim Levitsky
2009-05-28 15:58   ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081006194032.15992.8393.stgit@terra \
    --to=jonsmirl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lirc-list@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox