[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m38wdtw85j.fsf@intrepid.localdomain>
Date: Thu, 26 Nov 2009 17:41:28 +0100
From: Krzysztof Halasa <khc@...waw.pl>
To: Gerd Hoffmann <kraxel@...hat.com>
Cc: Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
dheitmueller@...nellabs.com, dmitry.torokhov@...il.com,
j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure
Gerd Hoffmann <kraxel@...hat.com> writes:
> Why not? With RC5 remotes applications can get the device address
> bits for example, which right now are simply get lost in the ir code
> ->
> keycode conversion step.
Right, this in fact makes the input layer interface unusable for many
remotes at this time.
I think the address (aka group) should be just a part of the key
("command") code, IIRC this is what lirc RC5 does (I'm presently using
a custom "media" version of RC5).
> I know that lircd does matching instead of decoding, which allows to
> handle unknown encodings. Thats why I think there will always be
> cases which only lircd will be able to handle (using raw samples).
>
> That doesn't make attempts to actually decode the IR samples a useless
> exercise though ;)
Sure. Especially RC5-like protos are simple to decode, and it's very
reliable, even with a very unstable remote clock source (such as
RC-based = resistor + capacitor).
--
Krzysztof Halasa
--
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/
Powered by blists - more mailing lists