What are the goals for the architecture of an in-kernel IR system?
in [Kernel]
|
Prev: backlight: tdo24m: ensure chip select changes between transfers
Next: 2.6.31.5 x86-64 KVM: 'emulation failed (pagetable) rip 7fb49335da7b 66 0f 7f 07'
From: Dmitry Torokhov on 8 Dec 2009 12:20 On Tue, Dec 08, 2009 at 09:58:53AM -0200, Mauro Carvalho Chehab wrote: > Dmitry Torokhov wrote: > > On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote: > > >>> What about capabilities of the receiver, what frequencies? > >>> If a receiver has multiple frequencies, how do you report what > >>> frequency the data came in on? > >> IMO, via sysfs. > > > > We probably need to think what exactly we report through sysfs siunce it > > is ABI of sorts. > > Yes, sure. > > Probably, the exact needs will popup only when we start to actually writing that > part of the core. > > My intention for now is to just create a /sys/class/irrcv, with one node > per each IR receiver and adding a protocol enumeration/selection node > there, and add some capabilities for the in-kernel decoders and lirc_dev > to create new nodes under that class. > > When the decoders/lirc_dev patches popup, we'll need to review those sysfs > API's. > > >>> What about multiple apps simultaneously using the pulse data? > >> IMO, the better is to limit the raw interface to just one open. > >> > > > > Why woudl we want to do this? Quite often there is a need for "observer" > > that maybe does not act on data but allows capturing it. Single-user > > inetrfaces are PITA. > > That should work fine as well, but I'm not sure how we'll detect overrun with > several kfifo readers. > Push the data into readers so they can do te decoding at their own pace. Some can do it in interrupt context, some will need workqueue/thread. They can also regilate the depth of the buffer, according to their needs. > >>> How big is the receive queue? > >> It should be big enough to receive at least one keycode event. Considering that > >> the driver will use kfifo (IMO, it is a good strategy, especially since you > >> won't need any lock if just one open is allowed), it will require a power of two size. > >> > > > > Would not it be wither driver- or protocol-specific? > > Probably. > > > > >>> How does access work, root only or any user? > >> IMO, it should be the same requirement as used by an input interface. > >> > >>> How are capabilities exposed, sysfs, etc? > >> IMO, sysfs. > >> > >>> What is the interface for attaching an in-kernel decoder? > >> IMO, it should use the kfifo for it. However, if we allow both raw data and > >> in-kernel decoders to read data there, we'll need a spinlock to protect the > >> kfifo. > >> > > > > I think Jon meant userspace interface for attaching particular decoder. > > I don't think we need an userspace interface for the in-kernel decoders. All > it needs is to enable/disable the protocol decoders, imo via sysfs interface. > > >>> If there is an in-kernel decoder should the pulse data stop being > >>> reported, partially stopped, something else? > >> I don't have a strong opinion here, but, from the previous discussions, it > >> seems that people want it to be double-reported by default. If so, I think > >> we need to implement a command at the raw interface to allow disabling the > >> in-kernel decoder, while the raw interface is kept open. > > > > Why don't you simply let consumers decide where they will get their data? > > How? > You end up with N evdev devices. Let application (MythTV) say "I want to use /dev/input/event1" (well, it will need persistent udev rule, but that's a detail). Another application will chose another event node. User can decide she'd rather use lircd - and so configire applications to use event5. Any maybe turned off the in-kernel decoders if they are of no use and there is a concern that they consume too mcuh resoures. Won't this work? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dmitry Torokhov on 8 Dec 2009 12:30 On Tue, Dec 08, 2009 at 02:57:15PM +0100, Krzysztof Halasa wrote: > Dmitry Torokhov <dmitry.torokhov(a)gmail.com> writes: > > > Why woudl we want to do this? Quite often there is a need for "observer" > > that maybe does not act on data but allows capturing it. Single-user > > inetrfaces are PITA. > > Lircd can work as a multiplexer. What this has to do with my statement? Did you mean retransmitter of sorts? Also I may explicitely not want the data stream to be multiplexed... > IMHO single-open lirc interface is ok, > though we obviously need simultaneous operation of in-kernel decoders. Why is the distinction? -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 12 Dec 2009 21:40 On Sat 2009-11-28 21:21:57, Krzysztof Halasa wrote: > Jon Smirl <jonsmirl(a)gmail.com> writes: > > > We have one IR receiver device and multiple remotes. How does the > > input system know how many devices to create corresponding to how many > > remotes you have? There is no current mechanism to do that. You need > > an input device for each remote so that you can do the EVIOCSKEYCODE > > against it. Some type of "create subdevice" IOCTL will need to be > > built. > > Thinking about it, I'm not sure. Why do we want multiple remote devices? > (not multiple remotes, that's clear). Computer in the basement, one ir receiver + usb speakers in kitchen, second ir receiver + speakers + monitor in living room. 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 15 Dec 2009 07:00
> > 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-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |