[lkml]   [2009]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] What are the goals for the architecture of an in-kernel IR system?
    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

    > >>> 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?


     \ /
      Last update: 2009-12-08 18:15    [W:0.031 / U:10.860 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site