[mythtv] Question regarding LIRC support and gContext->getCurrentLocation()

Michael T. Dean mtdean at thirdcontact.com
Tue May 30 15:21:16 UTC 2006

On 05/30/2006 09:40 AM, Navaho Gunleg wrote:
> On 5/30/06, Stuart Morgan <stuart at tase.co.uk> wrote:
>> I'd suggest that if changes were made to the lirc support that it would be a
>> good idea to map directly to Myth actions instead of keys.

I agree, but IMHO, it makes sense only if the mapping is done within 
Myth, not within LIRC.  I.e. we link the LIRC identifier string 
(whatever string is specified for the button in the ~/.mythtv/lircrc 
file) to the Myth action.  Many have suggested the opposite 
approach--specifying Myth action names in the lircrc file.  I don't 
think any remote has that many buttons and we shouldn't be specifying 
Myth contexts in the lircrc file.

>>  It's been
>> discussed in the past, I didn't pay much attention at the time but I seem to
>> recall some resistance to that idea. Still it would allow both  keyboard and
>> remote to be configured differently without a making lirc configuration too
>> complicated. It would even be easier to code (he says without actually
>> looking at the current stuff).
>> It would also be nice to see remote key config brought under Myth's own UI,
>> much like MythControls allows now for keyboard config.
>> I'm not suggesting that you do both these things, I'm just raising them for
>> discussion. I might even do it myself when I've finished my other tasks.
> Indeed -- I have also been pondering 'native' LIRC support -- but not
> using the lirc client libraries,

why not?

>  but like the 'irw' utility does,
> using the LIRC socket.

LIRC simply sends strings to registered clients.  The strings can be 
anything the user wants to specify in the config line (i.e. not 
necessarily "key" names).  Therefore, you could just specify a "logical 
name" for your button in the lircrc.  Then, if you get a new remote, you 
can just create a lircrc that maps the new button names to the logical 
names you had already defined/configured.  This would be far more 
configurable than listening for and interpreting remote codes.  (And, 
why re-invent the LIRC anyway? ;)

>  This would require *major* modifications and,
> at the moment, my understanding of both LIRC and especially such a big
> project as MythTV just isn't good enough to accomplish this. The other
> hack was pretty straight-forward really.
> Complete integration would be the /most/ elegant solution; imagine
> MythControls itself accepting the "Menu/i", "Play", "SkipForward"
> identifiers from the LIRC socket. That would really be awesome. ;)

Or mapping the LIRC config string "Red" to the "MENURED" action in the 
"Teletext Menu" context and to the "DELETE" action in the "TV Frontend" 
context.  That way, we get the same capability, but it's much easier to 


More information about the mythtv-dev mailing list