linux-kernel - [RFC] What are the goals for the architecture of an in-kernel IR system?

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-next>] [day] [month] [year] [list]

Date:	Fri, 27 Nov 2009 10:57:59 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Christoph Bartelmus <christoph@...telmus.de>
Cc:	jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
	j@...nau.net, jarod@...hat.com, khc@...waw.pl,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org, mchehab@...hat.com, superm1@...ntu.com
Subject: [RFC] What are the goals for the architecture of an in-kernel IR 
	system?

On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
<christoph@...telmus.de> wrote:
> Hi Mauro,
>
> on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
>> Christoph Bartelmus wrote:
> [...]
>>> But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
>>> because I'm not familiar at all with input layer toolset.
> [...]
>> I hope it helps for you to better understand how this works.
>
> So the plan is to have two ways of using IR in the future which are
> incompatible to each other, the feature-set of one being a subset of the
> other?

Take advantage of the fact that we don't have a twenty year old legacy
API already in the kernel. Design an IR API that uses current kernel
systems. Christoph, ignore the code I wrote and make a design proposal
that addresses these goals...

1) Unified input in Linux using evdev. IR is on equal footing with
mouse and keyboard.
2) plug and play for basic systems - you only need an external app for scripting
3) No special tools - use mkdir, echo, cat, shell scripts to build maps
4) Use of modern Linux features like sysfs, configfs and udev.
5) Direct multi-app support - no daemon
6) Hide timing data from user as much as possible.

What are other goals for this subsystem?

Maybe we decide to take the existing LIRC system as is and not
integrate it into the input subsystem. But I think there is a window
here to update the LIRC design to use the latest kernel features. We
don't want to build another /dev/mouse and have to rip it out in five
years.

>
> When designing the key mapping in the kernel you should be aware that
> there are remotes out there that send a sequence of scan codes for some
> buttons, e.g.
> http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159

This is good input.

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