[lkml]   [2009]   [Dec]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
Christoph Bartelmus 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%.

True. Yet, cases like IR devices made by someone's own use is something
that we don't need to care to have an in-kernel driver.

> 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.
> 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 don't see any reason why not supporting STB protocols. Several such
hardware use Linux, anyway. So, eventually the STB manufacturers may send
us decoders that work with their IR's.


 \ /
  Last update: 2009-12-08 00:53    [W:0.237 / U:0.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site