linux-kernel - Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

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 for Android: free password hash cracker in your pocket

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

Message-ID: <9e4733910911260748v454d3b0bvcc6bfc86823cdd39@mail.gmail.com>
Date:	Thu, 26 Nov 2009 10:48:26 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Gerd Hoffmann <kraxel@...hat.com>,
	Devin Heitmueller <dheitmueller@...nellabs.com>,
	Jarod Wilson <jarod@...sonet.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was: 
	Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Thu, Nov 26, 2009 at 9:45 AM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> Gerd Hoffmann wrote:
>> On 11/25/09 19:20, Devin Heitmueller wrote:
>>> On Wed, Nov 25, 2009 at 1:07 PM, Jarod Wilson<jarod@...sonet.com>
>>> wrote:
>>>> Took me a minute to figure out exactly what you were talking
>>>> about. You're referring to the current in-kernel decoding done on
>>>> an ad-hoc basis for assorted remotes bundled with capture devices,
>>>> correct?
>>>>
>>>> Admittedly, unifying those and the lirc driven devices hasn't
>>>> really been on my radar.
>>
>> I think at the end of the day we'll want to have all IR drivers use the
>> same interface.  The way the current in-kernel input layer drivers work
>> obviously isn't perfect too, so we *must* consider both worlds to get a
>> good solution for long-term ...

I made an attempt at implementing all of this a year ago.
http://lkml.org/lkml/2008/11/5/233

All of this kernel code is tiny, about 20K including a driver.

Basic flow works like this:

Add a new IR data type to the input framework
http://lkml.org/lkml/2008/11/5/234

Example mceusb IR input driver
http://lkml.org/lkml/2008/11/5/238

In-kernel decoding of core IR protocols - RC5, RC6, etc
http://lkml.org/lkml/2008/11/5/234

Decoded core protocols pass through a translation map based on configfs
When core protocol matches an entry in configfs it is turned into a
keycode event.
http://lkml.org/lkml/2008/11/5/235

You make a directory in /configfs/remotes for each remote you have.
Making the directory creates a new evdev device.  Under the directory
make an entry for each command generated by the device. These entries
cause the decoded IR data to be mapped into keycodes on the new evdev
device. udev would load these configfs mappings at boot time...

mkdir /config/remotes/sony
 -- this creates a new evdev device
mkdir remotes/sony/one
echo 7 >remotes/sony/one/protocol
echo 264 >remotes/sony/one/command
echo 2 >remotes/sony/one/keycode

This transforms a button push of 1 on my remote into a key stroke for KEY_1

 *   configfs root
 *   --remotes
 *   ----specific remote
 *   ------keymap
 *   --------protocol
 *   --------device
 *   --------command
 *   --------keycode
 *   ------repeat keymaps
 *   --------....
 *   ----another remote
 *   ------more keymaps

You can map the 1 button from multiple remotes to KEY_1 if you want. Or
you can use a single remote to create multiple virtual keyboards.

-------------------------

Raw IR pulse data is available in a FIFO via sysfs. You can use this
to figure out new remote protocols.

Two input events are generated
1) an event for the decoded raw IR protocol
2) a keycode event if thedecoded raw IR protocol matches an entry in
the configfs

You can also send pulses.

------

If you want to script this, you would have a user space task that
watches for either the decoded IR codes or the mapped keycodes.

This system also works with user space device drivers. They can inject
input events into the early event flow and they will get processed as
if the event originated in the kernel.

---------------------

Sure you could push the protocol decoding code (RC5, etc) into user
space. Seems like a lot of hassle to move about 3KB of code out of the
kernel.

-- 
Jon Smirl
jonsmirl@...il.com
--
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/