> > 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. > > > > I've committed already some IR restruct code on my linux-next -git tree: > > http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git > > The code there basically moves the input/evdev registering code and > scancode/keycode management code into a separate ir-core module. > > To make my life easy, I've moved the code temporarily into drivers/media/IR. > This way, it helps me to move V4L specific code outside ir-core and to later > use it for DVB. After having it done, probably the better is to move it to > be under /drivers or /drivers/input. Well, -next is for stuff to be merged into 2.6.34. You are quite an optimist. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
