[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B155534.6060907@redhat.com>
Date: Tue, 01 Dec 2009 15:41:08 -0200
From: Mauro Carvalho Chehab <mchehab@...hat.com>
To: Patrick Boettcher <pboettcher@...nellabs.com>
CC: Devin Heitmueller <dheitmueller@...nellabs.com>,
Jon Smirl <jonsmirl@...il.com>,
Maxim Levitsky <maximlevitsky@...il.com>, awalls@...ix.net,
dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
jarod@...sonet.com, khc@...waw.pl, linux-input@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
lirc-list@...ts.sourceforge.net, superm1@...ntu.com,
Christoph Bartelmus <lirc@...telmus.de>
Subject: Re: [RFC v2] Another approach to IR
Patrick Boettcher wrote:
>> The fact that the driver currently uses the same lookup table for both
>> types of remote controls however, was perhaps not the best design
>> choice. It really should be separated out, and merged with the
>> regular ir-functions.c. I just never got around to it.
>
> I did not follow all the discussion, still I have a comment:
>
> I will soon work on a device where it is the driver who is doing the
> decoding of the IR-frames. It is (maybe, I'm still missing some pieces
> to be sure) possible to receive different protocols at the same time
> with this hardware.
That's good news! Needing to pass a modprobe parameter to select the protocol
is not nice, and, while an ioctl will be needed to select IR protocols
(as there are some hardwares where this is not possible at all), the better
is to auto-detect the protocol.
Cheers,
Mauro.
--
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