[mythtv-users] Programming remote button bindings (WAS: What major features are planned for 0.27?)

[Michael T. Dean]

On 11/30/2012 12:08 PM, Michael T. Dean wrote:
> On 11/28/2012 06:08 PM, Simon Hobson wrote:
>> Michael T. Dean wrote:
>>>>> I still don't get why people think doing this (and repeating it with
>>>>> each upgrade--and on each system) is easier than creating (or, 
>>>>> likely,
>>>>> downloading) a single LIRC configuration file for the remote
>>>>> (lircd.conf) and a LIRC configuration for MythTV (~/.lircrc) and any
>>>>> other application you want to use with the remote, which can then be
>>>>> backed up with your other configuration files and just dropped in 
>>>>> place
>>>>> whenever you upgrade your distro or set up a new system or...
>>
>> Since there is now in-kernel support, using an extra package/layer is 
>> as sensible as having an extra package/software layer to make (say) a 
>> keyboard work.
>
> Yeah, that would be crazy...
>
> http://kbd-project.org/ ( ftp://ftp.kernel.org/pub/linux/utils/kbd/ )
> http://freedesktop.org/wiki/Software/XKeyboardConfig ( 
> ftp://ftp.x.org/pub/individual/data/xkeyboard-config/ )
>
> I suppose really, all we need is a kernel and drivers.  I have no clue 
> why so many developers create applications...
>
> In truth, the /only/ differences are a) keyboards are standardized and 
> b) distros have excellent tools for configuring the keyboard properly 
> for users (thanks, primarily, to a--the standardization I already 
> mentioned).  Just because you don't know the details of GNU/Linux and 
> X architecture doesn't mean you should assume keyboards are simple.  
> This is what I've been saying over and over--the GNU/Linux and X 
> keyboard architecture is almost identical to the LIRC architecture in 
> terms of its abstraction (and no one seems to question that keyboards 
> work well and the architecture is good).  Remotes are just /very/ much 
> less standardized than keyboards and, therefore, are in even greater 
> need of abstraction than keyboards.

Hehe, perhaps there's one more difference, too.  There's no 
built-in-to-X support for LIRC.  So, maybe there needs to be X 
integration, too, along with kernel integration, for things to be at the 
point where we could say, "no need for LIRC, now" (though I'd have to 
assume that the X integration would basically be the integration of 
what's left of LIRC, now that the LIRC remote drivers are now integrated 
into the kernel).

Before, LIRC was a set of remote drivers and configuration tools and a 
daemon program for communication.  Now, the remote drivers are all 
distributed with the kernel, so all that's left of LIRC are the 
configuration tools and daemon.  I'd assume that X integration would 
entail architecting some daemon (or X child) process and then creating 
an X module that ships the configuration tools (for those who want to 
create their own lircd.conf files or whatever).

Mike