[mythtv-users] One way to use multiple lirc drivers simultaneously, such as hauppauge & serial

[jds]

scott,

regarding using an IR blaster in conjunction with a PVR-x50 LIRC setup,
see also my howto writeup at:

http://losdos.dyndns.org:8080/public/mythtv-info/MythTV_DISH_IR_LED_TX_via_Modified_LIRC.html
or mirror
http://mirror.mmdsi.com/losdos.dyndns.org/public/mythtv-info/MythTV_DISH_IR_LED_TX_via_Modified_LIRC.html

ps
you may want to heed my "IMPORTANT NOTE #2" in stage 5 if you find that
your setup is occasionally dropping digits when changing channels.

jds

> Date: Sun, 28 Nov 2004 00:18:39 -0800
> From: Scott Alfter <mythtv-dontspamme at dontspamme-salfter.dyndns.org>
>
> While getting a new 27" LCD working with my MythTV box, I figured I'd have
> another crack at getting lirc to work with both the receiver on my PVR-350
> and a homebrew transmitter of the type described at lirc.org.  While lirc
> doesn't appear to let you build support for multiple device types in one
> shot, the kernel modules it builds tend to pile up.  By straightening out
> your init scripts and paying attention to what goes into /dev, you can get
> both the PVR-x50 IR receiver and an RS-232 IR transmitter working.
>
> (I'm runnning Gentoo on an Athlon XP 2400+ on an nForce2 motherboard (an
> FIC
> AU13, more specifically).  I'm using a vanilla Linux 2.6.9 kernel, with
> the
> built-in ALSA driver and added-in ivtv (0.1.9) and nVidia kernel modules.
> I
> use udev to manage /dev, since devfs has been deprecated.  I use a PVR-350
> and an M179 for input, and I'm looking at moving my digital-cable box from
> my TiVo to my MythTV box.  All software is generated with the Gentoo
> ebuilds...there's no need to hand-compile anything.)
>
> Assuming that you already have your PVR-x50 working for recording stuff
> (and
> for playing it back, if you have a PVR-350 and you want to use its onboard
> MPEG decoder), here's a rough outline of what you need to do.  These steps
> are for Gentoo, but you can probably figure it out for other distros.
>
> 1)  Make sure your Portage tree is reasonably current.
>     (lirc-0.7.0_pre7-r1.ebuild should be under
> /usr/portage/app-misc/lirc.)
> 2)  Build lirc with PVR-x50 support:
>     ACCEPT_KEYWORDS=~x86 LIRC_OPTS="--with-driver=hauppauge" emerge lirc
> 3)  Build lirc with RS-232 support:
>     ACCEPT_KEYWORDS=~x86 LIRC_OPTS="--with-driver=hauppauge
> --with-driver=serial --with-transmitter" emerge lirc
>     (yes, you should leave "--with-driver=hauppauge" in)
> 4)  Check /lib/modules/$KERNEL_VERSION/misc and verify that it has the
>     following modules:
>     lirc_dev.ko
>     lirc_i2c.ko
>     lirc_serial.ko
>     The timestamp on lirc_i2c.ko will be a little bit older than the other
>     two.  This is OK.
> 5)  Edit /etc/modules.d/ivtv so that it loads the lirc modules...it should
>     have lines in it like these:
>     alias char-major-61-0 lirc_i2c
>     alias char-major-61-1 lirc_serial
>     options lirc_serial type=0 io=0x3F8 irq=4
>     add above ivtv lirc_dev lirc_i2c lirc_serial
>     (Set the I/O and IRQ options for lirc_serial to whatever's appropriate
>     for your system; my transmitter is plugged into COM1:.)
>     Run modules-update to commit the changes.
> 6)  Copy /etc/init.d/lircd to /etc/init.d/lircd-hauppauge and to
>     /etc/init.d/lircd-serial.  They need to be modified so they won't
>     interfere with each other.
> 7)  In /etc/init.d/lircd-hauppauge, the line that starts lircd needs to
>     be changed to read as follows:
>     start-stop-daemon --start --quiet -p /var/run/lircd-hauppauge.pid -a
> -a /usr/sbin/lircd -- -o /dev/lircd0 -d /dev/lirc0 -P
> /var/run/lircd-hauppauge.pid
>     The line that stops lircd needs to be changed to read as follows:
>     start-stop-daemon --stop --quiet -p /var/run/lircd-hauppauge.pid
> 8)  In /etc/init.d/lircd-serial, the line that starts lircd needs to be
>     changed to read as follows:
>     start-stop-daemon --start --quiet -p /var/run/lircd-serial.pid -a -a
> /usr/sbin/lircd -- -o /dev/lircd1 -d /dev/lirc1 -P
> /var/run/lircd-serial.pid
>     The line that stops lircd needs to be changed to read as follows:
>     start-stop-daemon --stop --quiet -p /var/run/lircd-serial.pid
> 9)  If you built MythTV with its internal lirc support (instead of using
>     irxevent), it wants to connect to /dev/lircd, which won't have a
> daemon
>     running it (if it even exists).  Append the following to
>     /etc/conf.d/local.start so that a symbolic link to /dev/lircd0 is
>     regenerated at boot time:
>     /bin/ln -sf /dev/lircd0 /dev/lircd
> 10) Make sure local, lircd-hauppauge, and lircd-serial get started at boot
>     time:
>     for i in local lircd-hauppauge lircd-serial; do rc-update add $i
> default; done
> 11) Create /etc/lircd.conf.  You can crib the Hauppauge remote codes from
>     /usr/share/doc/ivtv-0.1.9-r4/lircd-g.conf.gz.  You can get codes for
>     many cable boxes and satellite receivers from
>     http://lirc.sourceforge.net/remotes/.
> 12) Restart local and start lircd-hauppauge and lircd-serial:
>     /etc/init.d/local restart
>     /etc/init.d/lircd-hauppauge start
>     /etc/init.d/lircd-serial start
> 13) Test your Hauppauge remote:
>     irw /dev/lircd0
>     Press some buttons on the remote; you should see the names of the
> buttons
>     scroll by.  Press Ctrl-C to exit.
> 14) Test your transmitter.  The exact parameters to irsend will vary
> according
>     to the device, but this switches my cable box (a Scientific-Atlanta
>     Explorer 2100) on and off:
>     irsend -d /dev/lircd1 SEND_ONCE SA2000 POWER
>
> You might also consider knocking together a shell script that'll change
> channels, since MythTV will need that.  With the Explorer 2100, I found I
> got the fastest channel change by sending SELECT and C after the digits,
> so
> here's my channel-changing script (saved as /usr/local/bin/chchannel):
>
> #!/bin/sh
> if [ $# != 1 ]
> then
>   echo Usage: `echo $0 | sed "s/.*\///g"` channum
>   exit -1
> fi
> for i in `echo $1 | sed "s/\(.\)/\1 /g"` SELECT C
> do
>   irsend -d /dev/lircd1 SEND_ONCE SA2000 $i
> done
>
> The only error-checking done is to make sure there's one parameter; it
> doesn't check to see if that parameter is numeric.
>
> A quick check of the archives didn't turn up anything useful on the
> subject,
> but it's possible I missed an earlier post.  Hopefully this will save
> someone else the time involved in reinventing this wheel.