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: <m3638k6lju.fsf@intrepid.localdomain>
Date:	Sun, 06 Dec 2009 18:48:21 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	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,
	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?

Mauro Carvalho Chehab <mchehab@...hat.com> writes:

>> 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

Which device? It was about a remote controller, not the receiver. The IR
receivers are frequently coupled with a DVB etc. receiver. There is
absolutely no problem supporting almost any remote if the hardware is
compatible with the receiver (i.e. IR to IR, the carrier frequency is
not 36 vs 56 kHz, the receiver supports the protocol etc).

I don't say we need to support in-kernel decoding for arbitrary
protocols.

>> (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).

Very hypotetical, indeed :-)

Most (all?) home-made receivers don't need polling, they use IRQs
instead ("the" home-made receiver is based on serial port and uses IRQ).
They are hardly the "obscure hardware" that nobody has.

The "more advanced" receivers using shift registers may use polling.

> 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.

Agreed, I think nobody argues we should support such things in the
kernel.

Once again: how about agreement about the LIRC interface
(kernel-userspace) and merging the actual LIRC code first? In-kernel
decoding can wait a bit, it doesn't change any kernel-user interface.
-- 
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/