Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753734AbZLAKqg (ORCPT ); Tue, 1 Dec 2009 05:46:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753291AbZLAKqf (ORCPT ); Tue, 1 Dec 2009 05:46:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26082 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753244AbZLAKqe (ORCPT ); Tue, 1 Dec 2009 05:46:34 -0500 Message-ID: <4B14F3EA.4090000@redhat.com> Date: Tue, 01 Dec 2009 11:46:02 +0100 From: Gerd Hoffmann User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: Andy Walls CC: Krzysztof Halasa , Jon Smirl , Christoph Bartelmus , dmitry.torokhov@gmail.com, j@jannau.net, jarod@redhat.com, jarod@wilsonet.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, maximlevitsky@gmail.com, mchehab@redhat.com, stefanr@s5r6.in-berlin.de, superm1@ubuntu.com Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? References: <9e4733910911280906if1191a1jd3d055e8b781e45c@mail.gmail.com> <9e4733910911280937k37551b38g90f4a60b73665853@mail.gmail.com> <1259450815.3137.19.camel@palomino.walls.org> <1259542097.5231.78.camel@palomino.walls.org> In-Reply-To: <1259542097.5231.78.camel@palomino.walls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1154 Lines: 26 Hi, > A current related problem is that i2c based devices can only be bound to > only one of ir-kbd-i2c *or* lirc_i2c *or* lirc_zilog at any one time. > Currently it is somewhat up to the bridge driver which binding is > preferred. Discussion about this for the pvrusb2 module had the biggest > email churn IIRC. Once lirc_dev is merged you can easily fix this: You'll have *one* driver which supports *both* evdev and lirc interfaces. If lircd opens the lirc interface raw data will be sent there, keystrokes come in via uinput. Otherwise keystrokes are send directly via evdev. Problem solved. cheers, Gerd PS: Not sure this actually makes sense for the i2c case, as far I know these do decoding in hardware and don't provide access to the raw samples, so killing the in-kernel IR limits to make ir-kbd-i2c being on par with lirc_i2c might be more useful in this case. -- 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/