From: Jon Smirl <jonsmirl@gmail.com>
To: awalls@radix.net, dmitry.torokhov@gmail.com, j@jannau.net,
jarod@redhat.com, jarod@wilsonet.com, khc@pm.waw.pl,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-media@
Subject: [RFC v2] Another approach to IR
Date: Tue, 1 Dec 2009 10:08:59 -0500 [thread overview]
Message-ID: <9e4733910912010708u1064e2c6mbc08a01293c3e7fd@mail.gmail.com> (raw)
While reading all of these IR threads another way of handling IR
occurred to me that pretty much eliminates the need for LIRC and
configuration files in default cases. The best way to make everything
"just work" is to eliminate it.
The first observation is that the IR profile of various devices are
well known. Most devices profiles are in the published One-for-All
database. These device profiles consist of vendor/device/command
triplets. There is one triplet for each command like play, pause, 1,
2, 3, power, etc.
The second observation is that universal remotes know how to generate
commands for all of the common devices.
Let's define evdev messages for IR than contain vendor/device/command
triplets. I already posted code for doing that in my original patch
set. These messages are generated from in-kernel code.
Now add a small amount of code to MythTV, etc to act on these evdev
messages. Default MythTV, etc to respond to the IR commands for a
common DVR device. Program your universal remote to send the commands
for this device. You're done. Everything will "just work" - no LIRC,
no irrecord, no config files, no command mapping, etc.
Of course there are details involved in making this work. MythTV will
have to have a config option to allow it to emulate several different
DVR devices so that you can pick one that you don't own. It should
also have choices for emulating the common devices defined for the
remotes included with various Linux video board like the Hauppauge
remote.
For apps that haven't been modified you will have to run a daemon
which will capture vendor/device/command evdev events and convert them
into keystroke commands than work the menus. You'll need a config file
for this and have to write scripts. Instead I'd just go modify the app
the respond to the IR events, it is easy to do.
Long run, we define a MythTV IR profile, mplayer profile, etc and get
these into the IR database for universal remotes. Now MythTV can stop
emulating another vendor's device.
For the default MythTV case no external support will need to be
installed if the protocol decode engines are in the kernel. The raw
data will come in, run through the engines, and pop out as evdev
messages with a vendor/device/command triplet. Devices that decode in
hardware will just send vendor/device/command triplets.
--
Jon Smirl
jonsmirl@gmail.com
next reply other threads:[~2009-12-01 15:08 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 15:08 Jon Smirl [this message]
2009-12-01 15:47 ` [RFC v2] Another approach to IR Maxim Levitsky
2009-12-01 16:16 ` Jon Smirl
2009-12-01 17:03 ` Mauro Carvalho Chehab
2009-12-01 17:09 ` Devin Heitmueller
2009-12-01 17:29 ` Mauro Carvalho Chehab
2009-12-01 17:54 ` Dmitry Torokhov
2009-12-01 19:00 ` Mauro Carvalho Chehab
2009-12-01 19:27 ` Jon Smirl
2009-12-01 20:11 ` Dmitry Torokhov
2009-12-01 21:05 ` Mauro Carvalho Chehab
2009-12-02 9:38 ` Dmitry Torokhov
2009-12-02 12:44 ` Mauro Carvalho Chehab
2009-12-02 17:10 ` Dmitry Torokhov
2009-12-02 17:30 ` Jon Smirl
2009-12-02 18:23 ` Dmitry Torokhov
2009-12-02 18:57 ` Jon Smirl
2009-12-02 20:54 ` Mauro Carvalho Chehab
2009-12-02 19:22 ` Jarod Wilson
2009-12-02 19:56 ` Dmitry Torokhov
2009-12-02 20:04 ` Jarod Wilson
2009-12-02 20:14 ` Dmitry Torokhov
2009-12-02 20:23 ` Mauro Carvalho Chehab
2009-12-02 20:53 ` Dmitry Torokhov
2009-12-02 21:13 ` Mauro Carvalho Chehab
2009-12-03 16:03 ` Ferenc Wagner
2009-12-03 16:33 ` Mauro Carvalho Chehab
2009-12-03 16:50 ` Jon Smirl
2009-12-03 17:19 ` Mauro Carvalho Chehab
2009-12-03 17:31 ` Dmitry Torokhov
2009-12-04 16:11 ` Ferenc Wagner
2009-12-02 20:42 ` Jarod Wilson
2009-12-02 20:48 ` Dmitry Torokhov
2009-12-02 20:57 ` Jarod Wilson
2009-12-02 21:12 ` Trent Piepho
2009-12-02 21:28 ` Jarod Wilson
2009-12-02 21:40 ` Mauro Carvalho Chehab
2009-12-03 18:06 ` Krzysztof Halasa
2009-12-03 1:19 ` Andy Walls
2009-12-03 2:27 ` hermann pitton
2009-12-03 0:20 ` Jon Smirl
2009-12-03 2:22 ` Mauro Carvalho Chehab
2009-12-03 5:08 ` Jon Smirl
2009-12-03 11:09 ` Mauro Carvalho Chehab
2009-12-03 18:18 ` Krzysztof Halasa
2009-12-03 20:54 ` Mauro Carvalho Chehab
2009-12-03 2:48 ` Trent Piepho
2009-12-03 4:13 ` Jarod Wilson
2009-12-03 5:18 ` Jon Smirl
2009-12-03 11:20 ` Mauro Carvalho Chehab
2009-12-03 19:48 ` alhaz
2009-12-02 19:33 ` Mauro Carvalho Chehab
2009-12-02 19:50 ` Jon Smirl
2009-12-02 19:58 ` Jon Smirl
2009-12-02 20:47 ` Mauro Carvalho Chehab
2009-12-02 19:55 ` Jarod Wilson
2009-12-03 1:02 ` Andy Walls
2009-12-03 10:00 ` Mauro Carvalho Chehab
2009-12-03 12:02 ` Andy Walls
2009-12-03 11:09 ` Mauro Carvalho Chehab
2009-12-02 20:01 ` Dmitry Torokhov
2009-12-02 15:37 ` Jon Smirl
2009-12-02 17:00 ` Dmitry Torokhov
2009-12-02 11:26 ` Gerd Hoffmann
2009-12-02 12:45 ` Mauro Carvalho Chehab
2009-12-01 17:35 ` Patrick Boettcher
2009-12-01 17:41 ` Mauro Carvalho Chehab
2009-12-01 18:19 ` Jon Smirl
2009-12-01 17:37 ` Mauro Carvalho Chehab
-- strict thread matches above, loose matches on Subject: below --
2009-12-03 19:47 Guus Sliepen
2009-12-03 21:53 ` Jarod Wilson
2009-12-05 11:23 ` Guus Sliepen
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=9e4733910912010708u1064e2c6mbc08a01293c3e7fd@mail.gmail.com \
--to=jonsmirl@gmail.com \
--cc=awalls@radix.net \
--cc=dmitry.torokhov@gmail.com \
--cc=j@jannau.net \
--cc=jarod@redhat.com \
--cc=jarod@wilsonet.com \
--cc=khc@pm.waw.pl \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).