linux-kernel - Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

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: <E63F6C2B-71FD-440D-B659-DC7BB96BEDF6@wilsonet.com>
Date:	Wed, 25 Nov 2009 23:46:21 -0500
From:	Jarod Wilson <jarod@...sonet.com>
To:	Krzysztof Halasa <khc@...waw.pl>
Cc:	Andy Walls <awalls@...ix.net>,
	Christoph Bartelmus <lirc@...telmus.de>,
	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] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

On Nov 25, 2009, at 2:27 PM, Krzysztof Halasa wrote:

> Jarod Wilson <jarod@...sonet.com> writes:
> 
>> Ah, but the approach I'd take to converting to in-kernel decoding[*]
>> would be this:
>> 
>> 1) bring drivers in in their current state
>>   - users keep using lirc as they always have
>> 
>> 2) add in-kernel decoding infra that feeds input layer
> 
> Well. I think the above is fine enough.
> 
>> 3) add option to use in-kernel decoding to existing lirc drivers
>>   - users can keep using lirc as they always have
>>   - users can optionally try out in-kernel decoding via a modparam
>> 
>> 4) switch the default mode from lirc decode to kernel decode for each lirc driver
>>   - modparam can be used to continue using lirc interface instead
>> 
>> 5) assuming users aren't coming at us with pitchforks, because things don't actually work reliably with in-kernel decoding, deprecate the lirc interface in driver
>> 
>> 6) remove lirc interface from driver, its now a pure input device
> 
> But 3-6 are IMHO not useful. We don't need lirc _or_ input. We need
> both at the same time: input for the general, simple case and for
> consistency with receivers decoding in firmware/hardware; input for
> special cases such as mapping the keys, protocols not supported by the
> kernel and so on (also for in-tree media drivers where applicable).
> 
>> [*] assuming, of course, that it was actually agreed upon that
>> in-kernel decoding was the right way, the only way, all others will be
>> shot on sight. ;)
> 
> I think: in-kernel decoding only as the general, primary means. Not the
> only one.

Okay, I read ya now. I got my wires crossed, thought you were advocating for dropping the lirc interface entirely. I think we're on the same page then. :)

-- 
Jarod Wilson
jarod@...sonet.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/