Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752532AbZK1PgD (ORCPT ); Sat, 28 Nov 2009 10:36:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752426AbZK1PgB (ORCPT ); Sat, 28 Nov 2009 10:36:01 -0500 Received: from mail-fx0-f213.google.com ([209.85.220.213]:63863 "EHLO mail-fx0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249AbZK1Pf7 (ORCPT ); Sat, 28 Nov 2009 10:35:59 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=q5E2QleVCL2Sc6dY654kXMFR8NpebZEoKJMYstnvw09VyxejgJUjZCw8DetDjGi9dc 1eQOPwqAeql1gOXlLt6X8jPP41nH5uCf4IRIIT83ybk7jbQXJ83thcHOsWQtD0TiblSD y1nWS5tTkrSTU9LCl7LAWVRVSHecPWBqXidgk= Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR system? From: Maxim Levitsky To: Krzysztof Halasa Cc: Stefan Richter , Jon Smirl , Christoph Bartelmus , jarod@wilsonet.com, awalls@radix.net, dmitry.torokhov@gmail.com, j@jannau.net, jarod@redhat.com, linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, mchehab@redhat.com, superm1@ubuntu.com In-Reply-To: References: <9e4733910911270757j648e39ecl7487b7e6c43db828@mail.gmail.com> <4B104971.4020800@s5r6.in-berlin.de> <1259370501.11155.14.camel@maxim-laptop> <1259419368.18747.0.camel@maxim-laptop> Content-Type: text/plain; charset="UTF-8" Date: Sat, 28 Nov 2009 17:35:59 +0200 Message-ID: <1259422559.18747.6.camel@maxim-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 919 Lines: 27 On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote: > Maxim Levitsky writes: > > >> And that's good. Especially for a popular and simple protocol such as > >> RC5. > >> Actually, it's not about adding the decoder. It's about fixing it. > >> I can fix it. > > > > This is nonsense. > > You forgot to say why do you think so. Because frankly, I am sick of this discussion. Generic decoder that lirc has is actually much better and more tolerant that protocol specific decoders that you propose, You claim you 'fix' the decoder, right? But what about all these lirc userspace drivers? How they are supposed to use that 'fixed' decoder. -- 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/