On Sun, Dec 06, 2009 at 09:34:26PM +0100, Krzysztof Halasa wrote: > Jon Smirl <jonsmirl@xxxxxxxxx> writes: > > >> Once again: how about agreement about the LIRC interface > >> (kernel-userspace) and merging the actual LIRC code first? In-kernel > >> decoding can wait a bit, it doesn't change any kernel-user interface. > > > > I'd like to see a semi-complete design for an in-kernel IR system > > before anything is merged from any source. > > This is a way to nowhere, there is no logical dependency between LIRC > and input layer IR. > > There is only one thing which needs attention before/when merging LIRC: > the LIRC user-kernel interface. In-kernel "IR system" is irrelevant and, > actually, making a correct IR core design without the LIRC merged can be > only harder. This sounds like "merge first, think later"... The question is why we need to merge lirc interface right now, before we agreed on the sybsystem architecture? Noone _in kernel_ user lirc-dev yet and, looking at the way things are shaping, no drivers will be _directly_ using it after it is complete. So, even if we merge it right away, the code will have to be restructured and reworked. Unfortunately, just merging what Jarod posted, will introduce sysfs hierarchy which is userspace interface as well (although we not as good maintaining it at times) and will add more constraints on us. That is why I think we should go the other way around - introduce the core which receivers could plug into and decoder framework and once it is ready register lirc-dev as one of the available decoders. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
