[lkml]   [2008]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH 0/4] V3 - Implementation of IR support using the input subsystem
    On Fri, 2008-10-10 at 10:08 -0400, Jon Smirl wrote:
    > On Fri, Oct 10, 2008 at 9:42 AM, Jarod Wilson <> wrote:
    > > On Fri, 2008-10-10 at 01:04 -0400, Jon Smirl wrote:
    > >> On Fri, Oct 10, 2008 at 12:11 AM, Jarod Wilson <> wrote:
    > >> > On Thu, 2008-10-09 at 14:03 +0200, Pavel Machek wrote:
    > > [...]
    > >> >> > How should multiple remotes be handled? Split them out into
    > >> >> > individual input devices, or group them onto a single IR device? I
    > >> >> > can implement either.
    > >> >>
    > >> >> Individual input devices, I'd say... so that app can only listen for
    > >> >> 'its' remote.
    > >> >
    > >> > I don't quite get it. How can we tell there are multiple remotes to set
    > >> > up multiple input devices when the system comes up? All we can know
    > >> > about at driver init time is the receiver(s), no? Or would this be keyed
    > >> > off a config file? Or ______ ?
    > >>
    > >>
    > >> We could create a sysfs attribut named ir_config. For each config file
    > >> you copy to it it creates a new input device. The config files have
    > >> lists of map this protocol, device, command tuple to this key. When a
    > >> remote button is pressed the raw codes are fed to the in-kernel
    > >> protocol engine. That engine turns the raw codes into tuples. Tuples
    > >> are matched against the configs that have been loaded until a hit is
    > >> found. If no hit they get sent out the catch-all device.
    > >
    > > Okay. I presume the catch-all device would simply note that it saw
    > > something, and not actually take any action beyond that.
    > The catch-all device is an device in /dev/input. It gets the input
    > tuples in protocol/device/command form sent to it. I should probably
    > send all IR input to this device, and flag the events that were
    > translated and sent to another input device.

    Sounds sane.

    > > Also, a minor clarification: If its config file based, then its not so
    > > much one input device per remote, its one input device per config file,
    > > so one could set up two separate config files that are actually commands
    > > from the same remote, but have them listened to by different apps, or
    > > one could group together commands from multiple remotes in a single
    > > config so that multiple remotes would all control the same thing. Sounds
    > > good to me, provides for a reasonable amount of flexibility.
    > That is how it works.

    Cool. Still getting this all straight in my head... :)

    > > Of course, this suggests a receiver wouldn't be able to do anything
    > > until the user provided a key mapping table of some sort. Would it make
    > > sense to provide a default IR-to-key mapping for each receiver type? A
    > > bit difficult to provide a sane default for something like a home-brew
    > > serial IR receiver, but you could certainly provide sane defaults for
    > > things like mceusb and imon (i.e., mappings for the remotes typically
    > > bundled with those receivers).
    > Receivers can process the raw tuples using the catch-all device.
    > You could write a little app like udev that listens to the catch-all
    > device and then search the config files for untranslated tuples. When
    > you match on an untranslated tuple, load that config file into the
    > kernel.

    That's just the sort of thing I *don't* want though -- I can imagine my
    receiver picking up all the signals intended for my other AV devices and
    loading up a bunch of configs, thinking it should do something with
    these signals. Seems you'd want a training/pairing mode you could put
    the driver in to set this stuff up.

    > I'm taking the kids on their first trip to Disneyworld next week so I
    > won't be able to work on this for a while.

    Have fun! In the mean time, I've got a bit of porting to try out still,
    as well as some remaining review clean-ups...

    Jarod Wilson

     \ /
      Last update: 2008-10-10 23:13    [W:0.029 / U:95.324 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site