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:	Sun, 6 Dec 2009 11:38:55 -0500
From:	Jon Smirl <jonsmirl@...il.com>
To:	Christoph Bartelmus <lirc@...telmus.de>
Cc:	awalls@...ix.net, dmitry.torokhov@...il.com, 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,
	mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel IR 
	system?

On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus <lirc@...telmus.de> wrote:
> Hi Jon,
>
> on 04 Dec 09 at 19:28, Jon Smirl 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
> [...]
>> Of course transmitting is a completely different problem, but we
>> haven't been talking about transmitting. I can see how we would need
>> to record any IR protocol in order to retransmit it. But that's in the
>> 5% of users world, not the 90% that want MythTV to "just work".  Use
>> something like LIRC if you want to transmit.
>
> I don't think anyone here is in the position to be able to tell what is
> 90% or 5%. Personally I use LIRC exclusively for transmit to my settop box
> using an old and obscure RECS80 protocol.
> No, I won't replace my setup just because it's old and obscure.

There are two groups, technically oriented people who can handle
messing around with IR protocols and everyone else.  I'm not proposing
to remove any capabilities from the first group. Instead I'd like to
see the creation of a "just works" option for the other group. We
don't know the size of the everyone else group yet because that option
doesn't exist. In general non-technical people way out number the
technical ones in broad user bases. For example I had to use LIRC to
get my remotes working, but I would have rather been in the everyone
else group and not had to learn about IR.

> Cable companies tend to provide XMP based boxes to subscribers more often
> these days. Simply not supporting these setups is a no-go for me.

I suspect what we categorize as "just works" will expand over time.
The in-kernel support can start small and add protocols and maps over
time. Support for XMP can start in LIRC and migrate into the kernel
after we fully understand the protocol and know that enough people are
using it to justify the effort of maintaining it in-kernel.  Adding
in-kernel support for a protocol is not going to make LIRC disappear.

The critical part is getting the initial design of the in-kernel IR
system right. That design is very hard to change after it gets into
everyone's systems and apps start depending on it. Writing up use
cases, modular protocols, figuring out how many bits are needed in
fields, how are maps written, can they be autoloaded, transmitting,
etc, etc. These are the important things to be discussing. LIRC users
obviously have a lot of knowledge in this area to contribute.

PS - another area we need to be thinking about is radio remotes like
the new RF4CE devices. The button presses from these remotes will come
in on the 802.15.4 networking stack and need to get routed into the
input subsystem somehow.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ