2009-06-16, 10:02 PM
Sorry, but this is a long and boring post, so feel free to stop reading immediately 
I've been playing with LIRC for the PCH/NMT. For those of you who don't know, lirc is the Linux Infrared Remote Control software that is used by lots of linux applications to interface with many supported remote controls.
The PCH has a vastly cut down implementation of lirc built in and Martin Vallevand has successfully amended it to support an additional (Hauppauge) remote. Unfortunately because of the stripped out version of lirc supplied for the NMT, this can only be done by coding and recompiling for every new remote.
I thought it would be nice if any of the long list of supported remotes could be added as they are in 'proper' lirc by adding editable config files into the home directory. That would also allow us to tweak what buttons do what to suit are own preferences. I downloaded the current CVS of lirc and set to work.....
After some time - and not a little rummaging through long forgotten programming skills (or lack of them), I have managed to get to the point that CVS lirc compiles and runs on the NMT. However (I much prefer that word to but), I have now reached a point where I want to integrate into the Gaya and mvpmcx2 applications. Unfortunately, neither app is currently designed to handle the output from the CVS implementation; they use a far simpler, but less configurable method.
CVS lirc work like this...
The signal from IR receiver is decoded by the lirc hardware code based on rules found in /etc/lircd.conf. The details of what key has been pressed on what remote and for how long are then passed to a linux socket in a long human readable string. The user application (irexec, mplayer, mythtv etc) then reads the string from the socket and decides what to do with it using the standard lirc libraries and the contents of the ~/.lircrc file.
The NMT lirc reduces this to...
The signal from IR receiver is decoded by the (fixed) lirc hardware code. That is interpreted by hard coded rules and the output is placed on a linux socket as a short hexadecimal code. That is then used by the application (Gaya or mvpmcx2) with no reference to a .lircrc file.
I can see some merit in having standard CVS lirc on the NMT. It will certainly make it easier to port any apps that use lirc. I am specifically interested in mvpmcx2 here though. To make it work properly, Martin Vallevand would have to rewrite part of the application to include the lirc_client libraries. I don't know how he feels about that, but even if he did, gaya would still not work and I can't see it getting amended in the near future.
To avoid that, I can deviate from the CVS and build a translation into the hardware decoder that still uses part of the .lircrc file to decide its translations, but outputs the hex code directly. That will work for gaya and mvpmcx2, but will make it non portable to other apps.
The alternative is that I write a buffer program that reads the human readable data and translates it using .lircrc and then dumps it onto the socket again for mvpmcx2 and gaya to collect. The down side to that is complication and another daemon running on the poor little NMT's cpu.
I am putting this long and rambling text up here to see if anyone is remotely :eek: interested in me pursuing this further. My wife already thinks I've left her!
Any feedback gratefully received.
Martyn.
I've been playing with LIRC for the PCH/NMT. For those of you who don't know, lirc is the Linux Infrared Remote Control software that is used by lots of linux applications to interface with many supported remote controls.
The PCH has a vastly cut down implementation of lirc built in and Martin Vallevand has successfully amended it to support an additional (Hauppauge) remote. Unfortunately because of the stripped out version of lirc supplied for the NMT, this can only be done by coding and recompiling for every new remote.
I thought it would be nice if any of the long list of supported remotes could be added as they are in 'proper' lirc by adding editable config files into the home directory. That would also allow us to tweak what buttons do what to suit are own preferences. I downloaded the current CVS of lirc and set to work.....
After some time - and not a little rummaging through long forgotten programming skills (or lack of them), I have managed to get to the point that CVS lirc compiles and runs on the NMT. However (I much prefer that word to but), I have now reached a point where I want to integrate into the Gaya and mvpmcx2 applications. Unfortunately, neither app is currently designed to handle the output from the CVS implementation; they use a far simpler, but less configurable method.
CVS lirc work like this...
The signal from IR receiver is decoded by the lirc hardware code based on rules found in /etc/lircd.conf. The details of what key has been pressed on what remote and for how long are then passed to a linux socket in a long human readable string. The user application (irexec, mplayer, mythtv etc) then reads the string from the socket and decides what to do with it using the standard lirc libraries and the contents of the ~/.lircrc file.
The NMT lirc reduces this to...
The signal from IR receiver is decoded by the (fixed) lirc hardware code. That is interpreted by hard coded rules and the output is placed on a linux socket as a short hexadecimal code. That is then used by the application (Gaya or mvpmcx2) with no reference to a .lircrc file.
I can see some merit in having standard CVS lirc on the NMT. It will certainly make it easier to port any apps that use lirc. I am specifically interested in mvpmcx2 here though. To make it work properly, Martin Vallevand would have to rewrite part of the application to include the lirc_client libraries. I don't know how he feels about that, but even if he did, gaya would still not work and I can't see it getting amended in the near future.
To avoid that, I can deviate from the CVS and build a translation into the hardware decoder that still uses part of the .lircrc file to decide its translations, but outputs the hex code directly. That will work for gaya and mvpmcx2, but will make it non portable to other apps.
The alternative is that I write a buffer program that reads the human readable data and translates it using .lircrc and then dumps it onto the socket again for mvpmcx2 and gaya to collect. The down side to that is complication and another daemon running on the poor little NMT's cpu.
I am putting this long and rambling text up here to see if anyone is remotely :eek: interested in me pursuing this further. My wife already thinks I've left her!
Any feedback gratefully received.
Martyn.
Server: Ci5 2500k, 3GB, Windows Server 2012, nPVR 3.5.7. 2xWinTV-DVB-T USB, 1xWinTV-DVB-T PCI, 2 x BlackGold DVB-T, 1xPCTV290E and 1xPCTV460E on Astra 28.2 E.
clients: RPI2, Acer R3700, PCH-A110, NUC, 3xSamsung Smart TV
