Re: Proposal for reporting remote control button presses to userland

["Andrew Gillham" <gillham%gmail.com@localhost>]

On Wed, Oct 8, 2008 at 6:53 AM, Jared D. McNeill 
<jmcneill%invisible.ca@localhost> wrote:
> Ok, I think I have a plan. Is this cool with everybody?
>
>
> I'd like to add a wsremote(4) device that uses its own wsmux. Add new
> WSCONS_EVENT_REMOTE_UP/DOWN event type definitions, and feed struct
> wscons_events for button presses/releases.
>
> We'll deliver raw keycodes to userland, and a 'wsremoted' service that can
> run which loads a buttonmap (it's going to be different for each remote,
> lets use /usr/pkg/share/wsremote/ati_tv_wonder_600.plist as an example) and
> can translate raw button codes to cooked ones on a socket, lets say
> /var/run/wsremoted.sock. Message format can be something like:
>
>  <?xml version="1.0" encoding="UTF-8"?>
>  <plist version="1.0">
>  <dict>
>    <key>source</key>
>    <string>wsremote0</string>
>    <key>event</key>
>    <string>button-pressed</string>
>    <key>command</key>
>    <string>volume-up</string>
>  </dict>
>
> An application can then listen on that socket for button presses and do
> whatever it feels like (application might be MythTV, lirc, mplayer, etc).


My first comment would be to avoid the early mistakes of LIRC where
there was not an event name space and everyone was forced to provide
their own raw -> cooked mapping and naming.  As a result the cooked
values were "Play" or "PLAY_BUTTON" or whatever.  Subsequently
everyone also had to configure mythtv to know that "Play" was 'P' and
for mplayer "Play" was 'speed_set 1'.

Needless to say a simple standard stating the play button on a remote
should always generate event "play-pressed" would allow applications
like mythtv to use "play-pressed" to perform the obvious function.
Default configuration files from pkgsrc would just work as expected
once the correct remote was selected.

Check out these two links for more interesting information.
https://wiki.ubuntu.com/RemoteControls
http://d.gardon.free.fr/vase/lirc/full/html3.html

I don't particularly care for their key names, but ultimately the
cooked events need to have a standard name, regardless of the remote
hardware.  At least for the core buttons that are common to 90% of the
remotes out there.  The LIRC guys did some statistical analysis
(detailed in the above links) and came up with the most common
buttons.

Also the question about identifying the correct remote was mentioned
and you suggested the serial number of the IR receiver, or the pci id
etc.  At the basic level I don't care as much how the IR event got to
the wsremoted as I care which remote generated the event.  E.g. if I
have two remotes configured, I want to be able to differentiate
between them, but use the same IR receiver hardware.  Or if I have IR
hardware accepting input from two rooms I will want to differentiate
by hardware & remote.

So I would like to have events more like this:
 <?xml version="1.0" encoding="UTF-8"?>
 <plist version="1.0">
 <dict>
 <key>class</key>
 <string>wsremote</string>
 <key>location</key>
 <string>family-room</string>
 <key>remote</key>
 <string>ati-tv-wonder-600</string>
 <key>event</key>
 <string>button-pressed</string>
 <key>command</key>
 <string>volume-up</string>
 </dict>

Now I can have an application that is interested in remote events of
any kind listen for class wsremote events.  If I want to differentiate
between my two remotes I look for class wsremote events and remote
ati-tv-wonder-600 specifically.  If I want to have multiple remotes
and different behavior for each remote in each room, that is easy
enough, just key on class, locatio, remote.  Later an IR keyboard + a
remote might be interesting which is why I suggest the class
differentiation.

-Andrew