Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752912AbZK0VuT (ORCPT ); Fri, 27 Nov 2009 16:50:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752055AbZK0VuM (ORCPT ); Fri, 27 Nov 2009 16:50:12 -0500 Received: from einhorn.in-berlin.de ([192.109.42.8]:37948 "EHLO einhorn.in-berlin.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750956AbZK0VuL (ORCPT ); Fri, 27 Nov 2009 16:50:11 -0500 X-Envelope-From: stefanr@s5r6.in-berlin.de Message-ID: <4B104971.4020800@s5r6.in-berlin.de> Date: Fri, 27 Nov 2009 22:49:37 +0100 From: Stefan Richter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23) Gecko/20091025 SeaMonkey/1.1.18 MIME-Version: 1.0 To: Jon Smirl CC: Christoph Bartelmus , jarod@wilsonet.com, awalls@radix.net, dmitry.torokhov@gmail.com, j@jannau.net, jarod@redhat.com, khc@pm.waw.pl, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, mchehab@redhat.com, superm1@ubuntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? References: <9e4733910911270757j648e39ecl7487b7e6c43db828@mail.gmail.com> In-Reply-To: <9e4733910911270757j648e39ecl7487b7e6c43db828@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 40 Jon Smirl wrote: > 3) No special tools - use mkdir, echo, cat, shell scripts to build maps >From the POV of a distributor, there is always a special tool required. Whether it is implemented in bash, Python, or C doesn't make a difference to him. For an enduser whose distributor doesn't package that tool, it also doesn't matter whether it is bash or Python. (C is awkward because it needs to be run through gcc first.) A Pyton tool can operate the existing EVIOCSKEYCODE interface just as well as a C tool. Your mkdir/ echo/ cat programs would still just this: Programs. Sure, these programs would be interpreted by an interpreter which is installed everywhere, and the data they operate on is in a clear text format. The downside is that these programs do not exist yet. > 5) Direct multi-app support - no daemon Think of lircd (when it feeds into uinput) as of a userspace driver rather than a daemon. The huge benefit of a userspace driver is that it can load configuration files. Multi-app support is provided by evdev of course. > What are other goals for this subsystem? - Minimal development cost; reduced maintenance cost relative the to status quo. - No regressions would be best. -- Stefan Richter -=====-==--= =-== ==-== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/