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]

Date:	Sat, 28 Nov 2009 11:45:51 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	Krzysztof Halasa <khc@...waw.pl>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	Christoph Bartelmus <christoph@...telmus.de>,
	jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
	j@...nau.net, jarod@...hat.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] What are the goals for the architecture of an in-kernel IR 
	system?

On Sat, Nov 28, 2009 at 10:35 AM, Maxim Levitsky
<maximlevitsky@...il.com> wrote:
> On Sat, 2009-11-28 at 16:25 +0100, Krzysztof Halasa wrote:
>> Maxim Levitsky <maximlevitsky@...il.com> writes:
>>
>> >> And that's good. Especially for a popular and simple protocol such as
>> >> RC5.
>> >> Actually, it's not about adding the decoder. It's about fixing it.
>> >> I can fix it.
>> >
>> > This is nonsense.
>>
>> You forgot to say why do you think so.
>
> Because frankly, I am sick of this discussion.
> Generic decoder that lirc has is actually much better and more tolerant
> that protocol specific decoders that you propose,

Porting the decoder engine from lirc into the kernel is also a possibility.

I'm asking to have an architecture design discussion, not to pick one
of the various implementations. This is something that we have to live
with for twenty years and it is a giant pain to change if we get wrong
initially.

> You claim you 'fix' the decoder, right?
> But what about all these lirc userspace drivers?
> How they are supposed to use that 'fixed' decoder.

Some of that user space hardware belongs in the trash can and will
never work reliably in a modern system. For example - sitting in a
tight user space loop reading the DTS bit from a serial port or
parallel port and then using the system clock to derive IR timings.
That process is going to be inaccurate or it is going to make video
frames drop. Big banging from user space is completely unreliable.

If you really want to use your microphone input as a DAC channel, run
a little app that reads the ALSA input and converts it to a timing
stream and then inject this data into the kernel input system using
uevent.

Both of these are hobbyist class solutions. They are extremely cheap
but they are unreliable and create large CPU loads.  But some people
want to use a $300 CPU to eliminate $2 worth of IR hardware. This type
of hardware will continue to work via event injection. But neither of
these solutions belong in the kernel.

What are other examples of user space IR drivers?

-- 
Jon Smirl
jonsmirl@...il.com
--
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/