[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.58.0911241918390.30284@shell2.speakeasy.net>
Date: Tue, 24 Nov 2009 19:32:42 -0800 (PST)
From: Trent Piepho <xyzzy@...akeasy.org>
To: Maxim Levitsky <maximlevitsky@...il.com>
cc: Jarod Wilson <jarod@...sonet.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Krzysztof Halasa <khc@...waw.pl>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Jarod Wilson <jarod@...hat.com>, linux-kernel@...r.kernel.org,
Mario Limonciello <superm1@...ntu.com>,
linux-input@...r.kernel.org, linux-media@...r.kernel.org,
Janne Grunau <j@...nau.net>,
Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: IR raw input is not sutable for input system
On Wed, 25 Nov 2009, Maxim Levitsky wrote:
>
> Its not the case.
> There are many protocols, I know that by experimenting with my universal
> remote. There are many receivers, and all have different accuracy.
> Most remotes aren't designed to be used with PC, thus user has to invent
> mapping between buttons and actions.
> Its is not possible to identify remotes accurately, many remotes send
> just a 8 bit integer that specifies the 'model' thus many remotes can
> share it.
The signal recevied by the ir receiver contains glitches. Depending on the
receiver there can be quite a few. It is also not trivial to turn the raw
signal sent by the remote into a digital value, even if you know what to
expect. It takes digital signal processing techniques to turn the messy
sequence of inaccurate mark and space lengths into a best guess at what
digital code the remote sent.
It's like turning raw VBI data into decoded ASCII teletext from a simulated
keyboard device, all in the kernel.
> Kernel job is to take the information from device and present it to
> userspace using uniform format, that is kernel does 1:1 translating, but
> doesn't parse the data.
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.
--
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