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 17:44:30 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	Stefan Richter <stefanr@...6.in-berlin.de>,
	Jon Smirl <jonsmirl@...il.com>,
	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?

Maxim Levitsky <maximlevitsky@...il.com> writes:

>> Actually, it is not the case. Why do you think it's better (let alone
>> "much better")? Have you at least seen my RC5 decoder?
> Because userspace decoder is general, it doesn't depend on exact timing,
> as long as pulses vary in size it can distinguish between keys, and that
> is enough.
> I didn't use your decoder, so in that particular case I don't know.

I thought so.
FYI: a sane RC5 decoder doesn't depend on exact timing. Even seen
a multi-function remote can control many different devices like TV,
VCR, DVD and so on? From different manufacturers etc.

> Unless you put it againt an inaccurate decoder....
> Ask the lirc developers.

Not sure what do you mean.

> I have a VCR remote, ok?
> I have a pulse/space decoder in my notebook, I have created a config
> file for that, and I did a lot of customizations, because this remote
> isn't supposed to be used with PC.

There is no such thing as "being supposed to be used with PC".
A space/mark receiver can receive data from any remote.

> Now, I also have a desktop.
> I don't have a receiver there, but someday I arrange some sort of it.
> I have an IR dongle in the closed, its raw IR diode.
> Probably with few components I could connect it to soundcard (and I have
> 3 independent inputs, of which only one is used)
> And then I will use alsa input driver.
>
> Now I had ended up with 2 different configurations, one for the kernel,
> another for the lirc.
> Great, isn't it?

If you want such setup - why not?
If you don't - you can use lirc in both cases.

> The point is again, I *emphasize* that as long as lirc is used to decode
> all but ready to use scancodes, everything is kept in one place.
> Both decode algorithms and configuration.

Then keep it that way and let others use what they think is best for
them.

Now how hard is it to understand that?

> Also, I repeat again, that this discussion *IS NOT* about userspace api,
> its about who decodes the input, kernel or lirc.

That could be the case if you were limited to "or". But we can do both.
-- 
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/