On Thu, Nov 26, 2009 at 10:08:29PM -0500, Jon Smirl wrote: > On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson <jarod@xxxxxxxxxxxx> wrote: > >> No, at present we expect 1:1 button->event mapping leaving macro > >> expansion (i.e. KEY_PROG1 -> "do some multi-step sequence" to > >> userspace). > > > > Hm. So ctrl-x, alt-tab, etc. would have to be faked in userspace somehow. > > Bummer. > > That is scripting. Scripting always needs to be done in user space. > > In the code I posted there is one evdev device for each configured > remote. Mapped single keycodes are presented on these devices for each > IR burst. There is no device for the IR receiver. A LIRC type process > could watch these devices and then execute scripts based on the > keycodes reported. > > The configfs model is very flexible. You could make a "remote" that > translates the UP/DOWN buttons of several different remotes into > KEY_UP/DOWN. That lets several different remotes control the same > app. > > Sure it is clunky to play with IR hex codes and keycodes in the > configfs mapping dir. If you don't like it write a GUI app for > manipulating the codes. GUI would then generate a script for udev to > run which builds the configfs entries. > > Maybe I should rename those directory entries to "app" instead of > "remote". They contain the mappings from IR hex codes to keycodes that > an app is interested in. Usually there is a 1:1 correspondence between > remote and app but there doesn't have to be. > Maybe we should revisit Jon's patchset as well. Regretfully I did not have time to do that when it was submitted the last time. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
