Messages in this thread |  | | | Subject | Re: [RFC PATCH 0/4] V3 - Implementation of IR support using the input subsystem | | From | Jarod Wilson <> | | Date | Fri, 10 Oct 2008 17:10:01 -0400 |
| |
On Fri, 2008-10-10 at 10:08 -0400, Jon Smirl wrote: > On Fri, Oct 10, 2008 at 9:42 AM, Jarod Wilson <jarod@wilsonet.com> wrote: > > On Fri, 2008-10-10 at 01:04 -0400, Jon Smirl wrote: > >> On Fri, Oct 10, 2008 at 12:11 AM, Jarod Wilson <jarod@wilsonet.com> 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 jarod@wilsonet.com
|  |