MythTV iMON server - alpha release 1

As I mentioned before, I've been working on an LCD server for mythtv in my spare time with the intention of making full use of the iMON LCD's icons. I'm happy to say that I'm ready to release the first alpha version. Its a little rough around the edges, and very basic in functionality at the moment, but it's a decent start.

Note: this application is specifically for the iMON LCD...NOT the VFD. If your display doesn't look like the photos at the bottom of this page, you have the VFD, and this program won't do you a bit of good.

How to get it
First, you will need to download 2 separate archives. The first is the application specific archive, and the second is an archive of perl libraries I've written.

mythimon:
http://www.ronfrazier.net/mythtv/downloads/mythimon.tar.gz

RFLibs:
http://www.ronfrazier.net/mythtv/downloads/RFLibs.tar.gz

Make sure the RFLibs folder exists as a subdirectory of the folder where you put the mythimon files.


Running it

The first thing you want to do is to disable any other software that is outputting to the lcd (including LCDproc). The only thing you want to keep loaded is the lirc imon lcd driver.

Next, the simpler test is to try running testAnimations.pl and make sure you get output on the LCD. If you have the older version of the iMON LCD, you will need to edit the code and change '15c2:0038' to '15c2:ffdc'. Also, if your device is setup somewhere besides /dev/lcd0, modify that setting too. If it works, you are good to go for the next test. If not, check for things like perl libraries, and make sure you are using at least perl 5.8 (needed for the thread support).

Next, you can try the mythimon.pl application. First you need to open it up and setup a few config variables. Specifically, the port numbers for the lcd server and the network control, the location of the frontend log file, the location of the lcd devices, and the iMON version.

If you don't have logging enabled for your frontend, you will need to add logging by adding the necessary paramters to the script that launches mythfrontend (ex "-l /var/log/mythtv/mythfrontend.log"). You will also need to have enabled both the network control port (found under setup->general) and the lcd port (under setup->appearance). You may need to restart the frontend for these changes to take effect.

Once that's all setup, you want to kill the existing instance of the mythlcdserver (so you can steal the port from it) and quickly start up the application. You can do this with the command:

killall mythlcdserver; ./mythimon.pl

You should now be looking at a screen with a clock. Next, you need to wait up to 10 seconds for mythfrontend to connect to the lcdserver port. When it does, you will see the output "FIRST COMMAND RECIEVED FROM MYTHLCDSERVER" appear on the command line (not on the LCD).

Now, when you go to watch TV or listen to music, you should get info on the screen and icons lit up. If not, again, check for perl libraries. Make sure you have the mythtv perl bindings installed.


Known Limitations

Being a work in progress, there is (by definition) a lot of stuff to be added or improved upon. Here are some of the known limitations, and what I plan to do:

Menu Support - This will be added most likely in the next version. I plan to integrate it with the front panel controls of the case via lirc. This way the menu's won't pop up whenever there is a menu change in myth (as mythlcdserver does). Instead, it won't display the menus until you hit the specified button on the front panel to enter menu mode. Then the menu display will override everything else until you hit the specified exit key or you let the menu timeout.

Volume Support - This will be added eventually. I plan to add a bit of configurability here...perhaps with plugin modules. One of the things I want to do for my specific setup is to integrate it with my TV, so it controls the volume via the serial port. I prefer this to adjusting the volume within mythtv. However, that's not going to work for most people, so I'll make it work both ways. With a simple plugin architecture, I'm thinking people could customize it to work with their setup (such as controlling an AV receiver).

Generic Info - This is info like photo names in the photo gallery, etc. Hopefully this will be in the next verison also.

Pausing/Stopping - There are times when myth doesn't send progress updates (like when playing music in the background). As a result, I've taken it upon myself to continuing calculating the progress on the assumption that playback is proceeding as normal. However, since myth sends no pause events, I have no way to track them. Thus, when you pause, my script doesn't know it, and keeps going. A similar problem exists with not knowing when music playback has stopped. I haven't yet figured out an ideal way to handle this. Probably some hack of monitoring the IR codes, cross reference that will the current location as reported by the network control port, etc.


Ideas for future expansion

I welcome feedback on ideas for what other types of things to do. There are some things I'm not sure about:

Uses for icons/display features - Anything interesting I can do with the top progress bar, other than just duplicating the bottom progress bar? When I add menu support at a later time, I was thinking I could use it to track progress through the menu (like a scrollbar on the side of your browser). How about the spinning disk, and the tray icon right below it? And the vol and time icons (one use is obvious, but also kind of pointless)? How about the source icons? I've taken advantage of TV and HDTV, but not SRC/SRC1/SRC2/FIT (and while we are at it...what the heck is FIT for anyway?).

Any good way to get the recording status out of the backend for the rec icon? I could also try monitoring the backend log, but that won't always be available on the remote frontend.

Anyone know a way to get codec data out of the music player to light up those icons?

How about getting weather data out of mythweather?

Is there any easy way to get spectrum analyzer data out of myth or the linux audio system?


Custom Fonts

I've created 2 different fonts for the application. The first is a normal font, 16 pixel tall (currently used for the clock). The other is an 8 pixel tall font with small caps instead of lowercase letters. OK...technically I made a 3rd font, but it only consists of 1 charachter (space), and is only meant as a vertical spacer in the display.


If you would like to make your own fonts, you can use this utility
http://www.ronfrazier.net/mythtv/imon_fontedit.html

If you come up with some good fonts, please feel free to share them with me.


Screenshots

Developng an iMON client for MythTV

Over the last few weeks I haven't posted anything here. I've been using whatever time I could to work on developing an iMON client that can interface with MythTV. I've been making some decent process, and although I have a lot of features I still want to implement, I think I might be ready to release a limited-functionality alpha version in a few days. For now, I just want to discuss why I'm developing it and what it has to offer over the standard mythlcdserver.


Why not use mythlcdserver

The iMON LCD device has a lot of new capabilities. It's not just a standard 16x2 (or whatever) text display. It goes way beyond that. It's actually a 96x16 pixel display (1-bit each). In addition to displaying text, it can display arbitrary graphics. This gives it a lot of options. You can use custom bitmapped fonts of any size. You can draw symbols on the display. Really, anything you can imagine. The only real limitation (other than size and bit depth) is that, like a lot of inexpensive LCDs, the response time is a bit slow, so animations don't work well (it kind of blurs together).

In addition, the iMON also supports custom icons. You can turn on icons for different a/v formats (mp3, divx, dts, etc), icons to represent the number of audio channel, and a bunch of others.

These sort of features are completely absent from mythlcdserver. They aren't something that would work with a small tweak. They would require a complete overhaul of the application. It would also require some changes to the way myth itself works, since currently myth doesn't provide any of this data to mythlcdserver. In the end, it would be a huge change, which presents 2 obstacles. First, getting a change that major into myth would be a bit difficult (I've had significantly smaller changes in there for months without anybody accepting/rejecting or even commenting on it). The second is that, even if it were to get included, it would require a myth recompile for people, or would make people wait until the changes made it into the next release of mythtv (or mythbuntu, knoppmyth, etc).

In summary, it just seemed to me to be better to do it in a new application.


What cool things can be done?

The first obvious thing that can be done is to support the iMON's 40+ icons. The next thing you can do is to use the 4 horizontal lines as progress bars, instead of wasting an entire row of the display on the progress bar. This gives you more space for display info while still having the progress bar visible at all times.

As I already mentioned, the bitmapped LCD gives a lot of options for bitmapped fonts. Not only can you do half height text (8 pixel) or full height (16 pixel), but you can do any size you want. Perhaps a slightly bigger 11 pixel font on top and a tiny 5 pixel font on the bottom. Or instead of the 5 pixel font, you can display icons across the bottom for the functionality of the front panel buttons (pause, rewind, etc).


How does it get the data

The correct way to get the data would be explicitly from myth. However, as I already stated, this data isn't readily available, and making it available would require a wide range of modifications to mythtv. Instead, I'm going the quick and dirty route. I collect the data from a variety of sources. I pretend to be the mythlcdserver program and monitor port 6545. I scrape data from log files. I gather data from the network control on port 6546. I watch for IR commands. I then weave all of this data together to get a coherent picture of what is going on in myth. It's not 100% perfect, but it works well enough to make me happy.

Getting iMON 0038 LCD working with LCDproc

Yesterday I discussed how to get the iMON display working in LIRC. The next step after that is to get the LCD display working. The most popular program for controlling the LCD is probably LCDproc. As it turns out, once you've got LIRC running the LCD properly, it's relatively easy to get LCDproc going too.

Once again, these instructions are specific to the 0038 version of the iMON LCD. Other versions may need slightly different instruction. Check over at the codeka.com forums for details.


Step 1 - Making sure your LIRC installation is good

LCDproc relies on the lirc_imon driver that is part of LIRC. If that isn't properly configured and installed, you have little hope of getting LCDproc going. Well, I've heard it's possible to have LCDproc control the LCD directly without LIRC, but I haven't tried it so I don't know if it's true, and even if you were to do so you'd lose its IR and front panel button capabilities. For this reason, LIRC is really the right way to go.

To test if your LIRC installation is correct, you can run the following command:

perl -e 'print pack "H*", "80000000091e0088"' > /dev/lcd0

When you run this command you should see the LCD clear itself and then display a clock with the time "AM 09:30" (in an ugly font, where the 4's look like 9's, and are only different by a single pixel, but I digress). If that's what you get, then lirc_imon is configured fine. You can proceed to step 2 after resetting the LCD with the following command:

perl -e 'print pack "H*", "4000000000000088"' > /dev/lcd0


If you weren't so lucky, then you might have a problem. First thing you want to do is make sure the driver is loaded:

lsmod | grep lirc_imon

You should get back a few lines of text that contain the lirc_imon driver and some other drivers (lirc_dev, usbcore, etc). If you get back nothing, try loading the driver manually:

modprobe lirc_imon

Then try running the command to set the clock again. If it works now, you may need to find a way to load the lirc_imon driver automatically (possibly by putting lirc_imon in /etc/modules). After that, you can proceed to step 2 (turn off the clock, first).

If it STILL isn't working, go back again and test whether the iMONs IR and/or front panel buttons are still working with LIRC. If not, somehow you don't have LIRC built correctly, with the correct patches, so you need to fix that first. Check out yesterday's post on that topic. However, if it does work, then my best guess is that LIRC thinks you have the VFD rather than the LCD and built the lirc_imon module for that device.

If you configured LIRC for only a single device (the Soundgraph iMON IR/LCD), then it should have handled everything for you. However, if you are like me, and have a separate IR receiver that you are using, and thus need to install LIRC with multiple drivers, you probably configured it something like:

./configure --with-driver=all

As I covered in an update to my post on setting up LIRC with multiple devices, the --with-driver=all option will configure it to use the VFD rather than the LCD. You will need to change config.h so that the line:
/* #undef LIRC_IMON_LCD */

becomes:
#define LIRC_IMON_LCD 1

and then recompile and reinstall LIRC. Then unload and reload the lirc_imon driver. Then once again try the perl command to set the clock. It should now work (once again, be sure to turn off the clock before proceeding). If you still have problems...I have no clue. You are on your own. Try posting over at the codeka.com forums.

Step 2 - Configuring LCDproc

This is actually a much simpler process than it was configuring lirc. Once again, you will want to follow the basic instructions post by Dean at the codeka.com forums. However, you will want to make the following changes.

1) Instead of using dean's lcdproc-0.5.2-imonlcd-0.3.patch patch, download my slightly modified version. I've made a few tweaks where he forgot to set an icon flag or set the wrong icon flag.

2) After running automake but before running configure, you will want to download my slightly modified version of madCoder's patch for the 0038 model, and apply it by running

patch -p1 <../lcdproc-imon_0038-v2.patch

3) When you get to the part about modifying the /usr/local/etc/LCDd.conf file, rather than changing the file manually, you might want to start by downloading my patch for the conf file and applying it with:

patch /usr/local/etc/LCDd.conf ../LCDd.conf.patch

This saves you from the error prone process of modifying it manually, especially since it's easy to leave off the leading or trailing slash on the DriverPath setting (in fact, deans instructions even left off the trailing slash).

4) Dean mentions changing the RENDER_FREQ from 8 to 1. You might want to experiment with other values in between (2 to 4). While I found 8 to be too fast, 1 update per second was too slow for my tastes. If you decide to play around with it, you will need to recompile each time (it would be better to move this to the config file, but I didn't find it important enough to waste the effort on). After making a change, you do NOT need to rerun configure or any of the previous commands. Just make and make install.

Step 3 - Testing LCDproc

This part is quite easy. Just run the following command:

LCDd -f -r 4

The display should light up with some text from LCDproc. If not...well, I really don't know what could have went wrong. Just make sure you carefully followed all of the instructions in the proper order (are you sure you ran the command to turn off the clock in step 1)?


Thats it!

See, it was quite easy. In fact, if you take a look at my instructions, you'll see that there was more detail involved with debugging your lirc_imon setup than there actually was getting LCDproc going.

You can now go on to configure your other applications to interface with LCDproc. Sorry, I have no advice on that part yet. I'm actually working on my own interface program at the moment (it seems I've got more things going on than I have time to write about). I'm sure I'll talk about that at some point.

Getting iMON 0038 LCD working with LIRC

As I mentioned before, getting the iMON display working was a bit troublesome. However, I managed to get it all working. Since it was so problematic, I'd like to share details of how I did it.

Before continuing on, I have to give huge thank you to Dean Harding for setting up the codeka.com forums and for all the work he did with the iMON. Also, thanks to many of the people in those forums who provided followup info and helped troubleshoot/patch things to work with newer versions of the hardware (especially madCoder for his patch for the 0038 model).

Also, I just want to say that, while the following instructions may seem a bit long, it really doesn't take that much work. A lot of this will just be verbose text. I'm trying to provide as thorough instructions as possible and describe whats going on, so that if you run into problems (ex: your configuration is a bit different), hopefully you will understand what needs to be done and figure out how to work around it.


Step 1 - Determine which version of the iMON you have

First, you need to get the ID of your iMON device. Run the lsusb command and look for a line that says Soundgraph. Before that will be the ID string. In my case, it's 15c2:0038, with the 15c2 being the vendor ID and the 0038 the product ID. If this is the version you have, then the rest of the instructions on this page should hopefully get you up and running.

If you have the 15c2:ffdc version, you have the original, and you can probably just follow Deans instructions from codeka.com. If you have another version number, then that means either Soundgraph has changed the device again, or you don't actually have the LCD (perhaps you have the VFD, which is a very different device). In either case, you can have a look around at the codeka.com forums and see someone has figured it out.


Step 2 - Determine if usbhid is controlling the iMON

Originally, the instruction I found for setting up the iMON display didn't work. I followed them to the letter, but had no luck. Well, as it turns out, it seems newer versions of the kernel (I'm running Debian 2.6.24) have support for the iMON in the usbhid driver. That means when the usbhid driver starts, it takes control of the iMON. Later, when the lirc_imon module loads, it's unable to take over the device.

So the first step necessary in setting up the iMON is to make sure the usbhid driver hasn't taken control of it. Run "cat /proc/bus/usb/devices". The output of this will be 1 block of info for each USB device in on the system. You want to find the block(s) that has Vendor=152c and ProdID=0038. Then look down a few lines further in the block and look for the line that contains "Driver=". That will tell you what driver is loaded for that device. If the driver is "usbhid", you need to continue on to disable it. If it's "(none)", you can just skip step 3. If you see lirc_imon, then you already have the proper driver loaded. Anything else and you are on your own.

---------------------------------------------------
Edit: It has come to my attention that /proc/bus/usb/devices doesn't exist on all systems. Apparently not every distribution has usbfs mounted. You can run the command

mount -t usbfs none /proc/bus/usb

to mount it, and then /proc/bus/usb/devices should exist.
---------------------------------------------------

Step 3 - Prevent usbhid from controlling the iMON

Assuming the usbhid driver has been loaded, you now need to disable that. You probably don't want to completely disable the usbhid driver, because that can prevent other devices from working properly (such as usb keyboards and mice). Instead, you want to tell the driver to ignore your particular device. The following instruction work for the 2.6.24 kernel under Debian.

1) Edit /etc/modprobe.d/usbhid (create it if it doesn't exist) and add the following line. The first hex code is the vendor ID, the second is the product ID, and the 0x0004 means ignore this device.

options usbhid quirks=0x15c2:0x0038:0x0004

2) Run the command: depmod -ae
3) You need to rebuild your initrd. If you are running a typical installation, you can do this by running:

update-initramfs -u


In my case, I'm doing a diskless boot over NFS, so I had to do it slightly different. Edit /etc/initramfs-tools/initramfs.conf and make sure BOOT is set to nfs. The run "mkinitramfs -o initrd.img.netboot". Finally, copy the new initrd.img.netboot over to the appropriate location on the tftp boot server (and rename it if you are using a different filename in your setup).

Once this is all done, a reboot should use the new settings and stop loading usbhid for your iMON. Run the "cat /proc/bus/usb/devices" once again. This time, the driver should be listed as (none). If it is still usbhid, do NOT continue on with these instruction until you've figured out how to deal with it for your particular distribution.


Step 4 - Installing LIRC

The basic installation instruction come from this post in the codeka.com forums. The patches to deal with the 0038 model come courtesy of this post by madCoder. In addition, I've made a few small changes to the patch to deal with the iMON pad remote and the front panel buttons on the Thermaltake DH-101 case. Other cases with front panel buttons likely require this same patch. If you don't have this case, I don't really see any harm in using my patch anyway.

You can get detailed info from the above 2 posts, but I'll summarize it below to help you keep things in order between both posts. Also, I'll provide links to actual patch files you can download, because copying and pasting the patch files from the forum are likely to get you "malformed patch" errors because of formatting issues.

Also, before beginning, you'll want to make sure you don't already have an installation of LIRC by running "apt-get remove lirc"

1) Make sure you have the prerequisites for LIRC installed as listed on this page. In my case, I was able to do that through apt-get:

apt-get install libtool automake1.9 autoconf

2) Download the current version of LIRC from CVS.
3)

UPDATE:

With the latest version of lirc (as of sometime in early 2009) all the necessary patches have been included into the CVS version of lirc. It is now possible to get full iMon support without applying any patches to the CVS branch (at least until SoundGraph decides to create a new iMon device with different control codes :)

Anyway, I'm crossing out the info that is no longer needed (but I'm leaving it here in case anyone has any use for it)

The 0038 version of the iMON hardware requires you to patch the LIRC code first. Download this patch and then install it by running the following command from within your LIRC directory:

patch -p1 < lirc-imon_0038-v2.patch

UPDATE:

The code in CVS has changed slightly, and a critical part of the patch no longer applies automatically. Until I get a chance to update the patch, you will need to do the following AFTER applying the patch:

1. Edit drivers/lirc_imon/lirc_imon.c


2. Find this line:
   
   { USB_DEVICE(0x15c2, 0xffdc) },


3. Add this line after it:
   
   { USB_DEVICE(0x15c2, 0x0038) }, /* IR & LCD */

Then you can continue with the next step

UPDATE 2:

It looks like cvs has been updated to handle the new version of the imon. However, from what I've heard, it appears that the patch applied to cvs wasn't as comprehensive as the patch I applied, and some of the buttons on the pad remote as well as some of the case front panel buttons might not work.

I haven't yet had a chance to look at the new version to see what it takes to get it going. In the mean time, if you would like to try with the old version from CVS, you can download the version I used from:
http://ronfrazier.net/mythtv/downloads/lirc-cvs.tar.gzip

4) Run autogen.sh and setup.sh. This will give you the configuration dialog. Choose the following sequence:

Driver Configuration -> USB Devices -> Soundgraph iMON IR/LCD

Save configuration & run configure

5) Run make, make install, and then modprobe lirc_imon.

With the 0038 version, you should have devices setup for /dev/lcd0, /dev/lcd1, /dev/lirc0, and /dev/lirc1. In addition, you are also going to have a device for /dev/lirc, but thats not really important. The actual devices we need are lirc0 and lirc1.

Notice to Ubuntu users: I received an email from Sascha Zucca who said that after following these instructions, he did not get all of the appropriate devices showing up under /dev. After working through the problem with him, he discovered that Ubuntu was loading its modules from a different directory than the lirc installer was putting the compiled files in. As a result, even after installing the new modules, lirc was loading the old version without the iMON fixes. Here is how he told me he fixed it:

i had to
mv /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/lirc_imon.ko{,.OLD}
and
ln -s /lib/modules/2.6.24-16-generic/misc/lirc_imon.ko /lib/modules/2.6.24-16-generic/ubuntu/media/lirc/lirc_imon/

I've since received a half dozen emails from other users who encountered the same problem. Performing the same fix worked for each of them (taking into account that the path will be slightly different for different versions of Ubuntu). Also, take note of the line wrapping. Those are actually only 2 commands.


FYI - Why are there 2 LIRC devices?

The iMON pad remote acts like a mouse/keyboard in addition to a remote. In the old version, it was my understanding that this was all handled through one LIRC device. However, the 0038 version splits it into 2 devices. All of the mouse/keyboard related keys come through the lirc0 device (the directional pad, left click, enter, the number button, ect....however NOT including the Mouse/Keyboard toggle button). Everything else comes through the lirc1 device (play, eject, colored buttons, zoom, etc...plus the Mouse/Keyboard toggle button). Finally, if you have front panel button, they will also come through the lirc1 device (at least they do on the DH-101).

If you have no plans to use the included remote, and plan to use a separate LIRC receiver with a different remote, you might think you can just skip the lirc0 part and use lirc1 for the front panel buttons. However, that may not work. Even if you don't use the iMON's IR receiver, it will still pick up some of the IR signals from certain remotes. When it does you will run into a problem. The iMON buffers up the inputs from each device separately, but maintains the sequence of events between the 2 buffers. If you only run the lirc1 device, everything will work fine until the iMON picks up an IR signal that it decides to put in the lirc0 buffer. When that happens, the lirc1 buffer will appear to have locked up and will not generate any more events. In reality, it's just maintaining the event sequence, and the next event is waiting to be removed from the lirc0 device. Until you do that, you will see no more events coming from the lirc1 device.

Now, on to the testing.


Step 5 - Testing and using LIRC

First you are going to need a lircd.conf file. For the pad remote, you can download this file. For the Thermaltake DH-101, you can download this file. If you want to use them both, you can just combine them into the same file. Whichever file you use (or both files combined), you will need to put that file in /etc/lircd.conf.

Once lircd.conf is in place, you can do the actual testing of LIRC. You need to get both devices up and running. The way to do this it to run 2 copies of lircd. The first one needs to listen to a socket and output its events there. The second one connects to the remote socket, gets events from there, and combines those with its own events. Each of the 2 processes will be listening to a different iMON device. Run the following 2 commands:

/usr/local/sbin/lircd --driver=default --device=/dev/lirc0 --pidfile=/var/run/lirc0.pid --listen=8765
/usr/local/sbin/lircd --driver=default --device=/dev/lirc1 --pidfile=/var/run/lirc1.pid --output=/dev/lircd --connect=localhost:8765

Now you can run the irw program and start pressing buttons on the remote and/or front panel, and you should see the event output on the screen. If you have a different case and don't get output from the front panel buttons, you will need to record a custom configuration file for it using irrecord.

First, you need to kill off the lircd processes (kill `pidof lircd`). Then you need to run irrecrd, but you need to point it at the right LIRC device:

irrecord --device=/dev/lirc1 frontpanel-lircd.conf

Follow the instructions to create your config file. When it's done, you will want to add the contents of frontpanel-lircd.conf to your /etc/lircd.conf file. Then restart both lircd processes and try irw again. Everything should be fine (hopefully)



Congratulations

If you made it this far, then you must have got everything working. Now you probably want to do something useful with the LCD. The most common program to control it is LCDproc. I've covered getting LCDproc setup with the iMON in this post.

If you have any questions or problems, be sure to leave a post in the comments below, or email me (you can find my email address through the "My MythTV Patches & Add-ons" link at the top of the right hand column). Or you can post about it in the iMON forum over at codeka.com

Setting up LIRC with multiple devices

In the process of building my latest mythbox, I've been doing a lot of adhoc experiments with a various things over the last few weeks. I thought it was time I start putting some of them together to start moving towards a working system. One of those things I needed to do was get all 3 of my lirc devices working together. The process turned out to be a bit trickier than I expected, but I got it done, and thought I'd share the details of a couple of the trickier spots


Why three lirc devices?

I wish I could say I only needs one device, but unfortunately that's not the case. First of all, my new Thermaltake DH-101 case has a set of front panel buttons, and the driver handles those buttons by treating them like IR codes and sending them through LIRC. I certainly would like those buttons to work, so that's one device.

In addition, as I discovered in my driver writing experiment, the iMON (which handles the front panel buttons) will block the input queue if it receives certain IR signals. The only way to unblock it is to remove those signal events from the queue, and the way that gets done is by exposing a second lirc interface. So, I need to have that interface working if I want my front panel buttons to continue working.

Finally, since the iMON can only receive a very limited subset of IR signals, it is pretty much worthless as a general purpose IR receiver. Therefore, I have a separate receiver...the IRA-3 (which appears to lirc as an Irman).


Compiling LIRC to support both drivers

The 2 iMON interfaces use the lirc_imon kernel driver (via the lirc default driver), while the IRA-3 uses the irman driver. Therefor, I need to get both drivers installed. However, thats one are where lirc is a bit troublesome.

The suggested approach is to configure/make/install lirc once for each individual driver, and then configure again with the --with-driver=all flag. This will configure lirc to make and install every supported lirc driver available. That's not exactly ideal, but it works. However, when I tried that, I got errors during the build complaining the the necessary bttv libraries were not installed and it couldn't continue. Now, it seemed silly to have to install dependancies for drivers I never even planned to use, so I was determined to find a better way.

I tried every way I could think of to run configure: with individual --with-driver parameters (one for each driver), as well as using a single flag and specifying both drivers (space separated, comma separated, quoted, etc). Nothing I could come up with would work. After searching and finding no resolution, I started trying to hack the configure script (which got me nowhere). However, I eventually found a trick that worked...hack the generated makefile.

The trick here was to configure it with --with-driver=all, and then edit the drivers/Makefile script. In here, there are 3 parameters to be edited. Each parameter contains a list of all the lirc drivers. You want to remove any drivers from that list you aren't interested in. The three parameters in that file you want to edit are: lirc_driver, DIST_SUBDIRS, and SUBDIRS. Once you've modified those lines to remove the extra drivers, just run the make and make install.

-----------------------------------------------
Edit: Well, a few days later, I get to work trying to setup my lcd display and realize it's not working. It seems that compiling lirc for all drivers makes it pick and choose between some mutually exclusive settings. One of those setting was whether the lirc_imon driver is built for the LCD or the VFD. It picks the VFD. In order to fix this for the iMON LCD, after running configure you need to edit the config.h file (in addition to the drivers/Makefile). Change config.h so that the line:
/* #undef LIRC_IMON_LCD */

becomes:
#define LIRC_IMON_LCD 1

Then continue on with the make and install. You may find a similar issue occurs with some of the other hardware.
-----------------------------------------------

Getting all 3 devices working

Now that I had lirc installed with all the drivers, I needed to get the 3 lirc devices functions. First steps was to test them out individually using irw and then merge them together. Unfortunately, I had an odd bug which I was able to resolve, but can't explain. My lircd.conf file has definitions for 4 remotes (my hauppauge remote, my wife's tivo remote, the iMON Pad's IR codes, and the case's front panel butons). For some reason, the Tivo/Hauppauge remotes would work no matter which order they were in, but the, but the other 2 wouldn't work with the TiVo and hauppage remotes defined first. I had to switch the order to get all 4 to work.

As far as I can tell, they are all valid definitions, and they all work. I was able to pinpoint the problem more specifically. If the earlier definition had the post_data_bits attribute definited, the iMON and front panel button definitions failed to work. Commenting it out fixed the problem with the lower definition (though it broke that one). Curiously enough, each of the 4 definitions has a post_data_bits attribute set, yet they all work fine when in the correct order. I can't seem to make sense of it.


Getting them working together

Now that I had each one working individually, I needed to get them working together through a single interface. I found documentation specifying how to use the listen and connect parameters to connect multiple lircd instances together. I tested, and that worked well enough for 2. However, as soon as I added the third, only one of the 3 would work.

It turns out that lircd has its client/server model a bit different that what I'd expect and would believe is the normal way to do it. Normally, when you have multiple processes connected together by sockets, you have one server that listens on the port and then multiple clients that connect to the one socket. And indeed, if you attempt this with lirc, it works perfectly. The one server will happily establish connections with multiple clients, but it won't actually do anything.

Instead, what you need to do is have all but 1 instance of lircd running as a server (ie: listening), and then have a single client connect to all of the servers, aggregate their data, and output it all on the single interface. Once I figured that out, it worked like a charm.

Just for reference, in case you'd like to see the actual commands I used:

lircd --driver=irman --device=/dev/lirc --pidfile=/var/run/lirc.pid --listen=9988

lircd --driver=default --device=/dev/lirc1 --pidfile=/var/run/lirc1.pid --listen=9987

lircd --driver=default --device=/dev/lirc0 --output=/dev/lircd --pidfile=/var/run/lirc0.pid --connect=localhost:9988 --connect=localhost:9987