Messages in this thread | | | Date | Tue, 15 Dec 2009 12:50:11 +0100 | From | Pavel Machek <> | Subject | Re: [RFC] What are the goals for the architecture of an in-kernel IR system? |
| |
> > 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
| |