On Sun, Dec 6, 2009 at 7:12 AM, Christoph Bartelmus <lirc@xxxxxxxxxxxx> 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@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
