Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Jon Smirl <jonsmirl@gmail.com>]

On Thu, Nov 26, 2009 at 9:28 PM, Jarod Wilson <jarod@wilsonet.com> 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@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html