linux-kernel - Re: [RFC v2] Another approach to IR

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1259682428.18599.10.camel@maxim-laptop>
Date:	Tue, 01 Dec 2009 17:47:08 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Jon Smirl <jonsmirl@...il.com>
Cc:	awalls@...ix.net, dmitry.torokhov@...il.com, j@...nau.net,
	jarod@...hat.com, jarod@...sonet.com, khc@...waw.pl,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, lirc-list@...ts.sourceforge.net,
	mchehab@...hat.com, superm1@...ntu.com,
	Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR

On Tue, 2009-12-01 at 10:08 -0500, Jon Smirl wrote: 
> 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.
You are making one  big wrong assumption that everyone that has a remote
uses mythtv, and only it.

Many users including me, use the remote just like a keyboard, or even
like a mouse.


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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/