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. -- Jon Smirl jonsmirl@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
