linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B1B99A5.2080903@redhat.com>
Date:	Sun, 06 Dec 2009 09:46:45 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	hermann pitton <hermann-pitton@...or.de>,
	Jon Smirl <jonsmirl@...il.com>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com, khc@...waw.pl,
	kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Dmitry Torokhov wrote:
> Hi,
> 
> On Sun, Dec 06, 2009 at 04:36:33AM +0100, hermann pitton wrote:
>> Hi,
>>
>> Am Freitag, den 04.12.2009, 19:28 -0500 schrieb Jon Smirl:
>>> On Fri, Dec 4, 2009 at 6:01 PM, Christoph Bartelmus <lirc@...telmus.de> wrote:
>>>> BTW, I just came across a XMP remote that seems to generate 3x64 bit scan
>>>> codes. Anyone here has docs on the XMP protocol?
>>> Assuming a general purpose receiver (not one with fixed hardware
>>> decoding), is it important for Linux to receive IR signals from all
>>> possible remotes no matter how old or obscure? Or is it acceptable to
>>> tell the user to throw away their dedicated remote and buy a universal
>>> multi-function one?  Universal multi-function remotes are $12 in my
>>> grocery store - I don't even have to go to an electronics store.
>> finally we have some point here, IMHO, that is not acceptable and I told
>> you previously not to bet on such. Start some poll and win it, and I'll
>> shut up :)
>>
> 
> Who would participate in the poll though?
> 
>> To be frank, you are quite mad at this point, or deliver working other
>> remotes to __all__ for free.
>>
> 
> I do not believe you are being realistic. Sometimes we just need to say
> that the device is a POS and is just not worth it. Remember, there is
> still "lirc hole" for the hard core people still using solder to produce
> something out of the spare electronic components that may be made to
> work (never mind that it causes the CPU constantly poll the device, not
> letting it sleep and wasting electricity as a result - just hypotetical
> example here).
> 
> We still need to do cost-benefit analysis and decide whether supporting
> the exotic setups _in kernel_ makes sense if it encumbers implementation
> and causes issues to the other 95% people.

Fully agreed. The costs (our time) to add and keep supporting an in-kernel
driver for an IR that just one person is still using is higher than 
asking the user to get a new IR. This time would be better spent adding a new
driver for other devices.

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/