Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752040AbZKZFlh (ORCPT ); Thu, 26 Nov 2009 00:41:37 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751667AbZKZFlg (ORCPT ); Thu, 26 Nov 2009 00:41:36 -0500 Received: from mail-pz0-f171.google.com ([209.85.222.171]:61657 "EHLO mail-pz0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751296AbZKZFle (ORCPT ); Thu, 26 Nov 2009 00:41:34 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=TIHBo00vtcGhDb14tJd6bSUD3zUYfzVeuYQTRiY52TPYuUETDJZ+0NLlOVu5gRrko3 Jh/RyAITp1Q2WxbmrIyYAdn87R5fyq9F1znJ0XjxTEz1oH2UzHYmIL9jZYwhMiaZ30lW gpH/9Btn3rkBP4vBlNyCbkL3gKuGCncuLD2KM= Date: Wed, 25 Nov 2009 21:41:35 -0800 From: Dmitry Torokhov To: Trent Piepho Cc: Maxim Levitsky , Jarod Wilson , Krzysztof Halasa , Mauro Carvalho Chehab , Jarod Wilson , linux-kernel@vger.kernel.org, Mario Limonciello , linux-input@vger.kernel.org, linux-media@vger.kernel.org, Janne Grunau , Christoph Bartelmus Subject: Re: IR raw input is not sutable for input system Message-ID: <20091126054135.GG23244@core.coreip.homeip.net> References: <200910200956.33391.jarod@redhat.com> <200910200958.50574.jarod@redhat.com> <4B0A765F.7010204@redhat.com> <4B0A81BF.4090203@redhat.com> <20091123173726.GE17813@core.coreip.homeip.net> <4B0B6321.3050001@wilsonet.com> <1259105571.28219.20.camel@maxim-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1064 Lines: 22 On Tue, Nov 24, 2009 at 07:32:42PM -0800, Trent Piepho wrote: > > One thing that could be done, unless it has changed much since I wrote it > 10+ years ago, is to take the mark/space protocol the ir device uses and sent > that data to lircd via the input layer. It would be less efficient, but > would avoid another kernel interface. Of course the input layer to lircd > interface would be somewhat different than other input devices, so > it's not entirely correct to say another interface is avoided. No, it would still be completely new interface that just happened to use input layer as transport. An ordinary program that would just want to react to play. pause, forward, etc buttons would have no idea what to do with the data so you'd still need a very specialized library to deal with the data. -- Dmitry -- 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/