LIRC Standard Namespace - Implementation Logistics

[Matthew B. <li...@in...>]

Hi All -

  I've been having some off-list discussions with several groups (Ubuntu
related mostly) about implementing the LIRC standard namespace since we
created the online LIRC Config and have database of button names and
mappings. 

  To recap the current situation (and bring anyone up to speed):
lircd.conf's
- defines what buttons events are generated by each remote
- irrecord'ed for each remote
- no standard naming of standard buttons (play, pause, vol+, etc)

lircrc's
- defines what button events are accepted by each program
   - eg: "prog = mythtv", "config = Left" 
- also maps which lircd.conf event should trigger an lircrc program
   - eg: "button = vol+"

  ** The exponential problem is every lircd.conf needs a custom lircrc
to correctly map its non-standard button names to non-standard events.

  To recap what's been proposed for the standard namespace:
lircrc's
- define standard events

lircd.conf's
- use standard button names for standard events (to prevent vol+ vs
VOLUME_UP mismatched lircrc configurations) 

  ** Doing this will make the vast majority of remotes and buttons names
match program events, and thus work with LIRC programs "out of the box",
without any manual configuration.  

/end recap

  So we would need standard lircrc's for all LIRC compatible programs
like:
https://wiki.ubuntu.com/MediaCenter/RemoteSupport?action=AttachFile&do=get&target=lircrc.elisa

  And an easy way to 'upgrade' hundreds of lircd.conf remotes, or at
least provide end-users any easy way to upgrade their lircd.conf. 

  The Ubuntu people are maintaining a 'conversion standard' here:
http://d.gardon.free.fr/vase/lirc/light/nns_light.txt

  So it appears that it would be a good idea for us to add the following
to our online LIRC Config (http://lircconfig.commandir.com/ ):
  - Add the new standard lircrc's
  - Add JOINing lircd.conf buttons (already in our DB tables) with the
above nns_light.txt mapping to generate new standard lircd.conf's


Questions:
  Any thoughts / comments on this?  
  Have I correctly recapped and summed up the situation?  
  Are program devs (MythTV, FreeVo, VDR, Xine, Mplayer, VLC etc) all on
board with setting a standard, since they would need to support it? 
  Is anyone else already doing this?  

Matthew
Systems Design
InnovationOne Applied Technology