News
Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)
HOWTO
- This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.
- Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.
- Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)
- You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).
- Unpack the patched lirc:
cd /usr/src
tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2
cd lirc-0.8.3-CVS-pvr150-2
./setup.sh
Choose:
TV card
i – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configurethen:
make && make install. - IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.
Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).
- Check everything is working so far:
modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1Check the syslog output. This should report something like:
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX, ok]
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX, ok]
Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0’
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 302355 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 743 codesets loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.
- You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.
- Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run
ls -l /dev/lirc*. If you don’t see a/dev/lirc0or similar, then trymknod /dev/lirc0 c 61 0if the steps below fail.modprobe lirc_dev && modprobe lirc_pvr150 debug=1
lircd --device=/dev/lirc0
- You can now check if the remote is working using
irw. Run this, and press buttons on the remote. You should see some output like0000000000001795 00 Down Hauppauge_350. - Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.
Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.
Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.
If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
database too. - Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key” so should be pretty easy to find. I also gave the keys standard names (0-9).
- To get mythtv to work, configure a channel change script for your device. There’s one here that should work out of the box if you
rename the number keys. - If you’re happy, you can always send me beer money. If not, add comments at the bottom 🙂
That’s it, good luck!
Packaging
The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.
I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:
svn co http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc lirc
and you can get the changes I made to the CVS revision of lirc with:
svn diff http://svn.blushingpenguin.com/svn/vendor/lirc/current http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc
Marc, I am having exact same issue as post # 349 by Francisco. Irblaster works great with the test script, but IRW does not work at all. I am running Fedora, btw.
Hope this isn’t a dup, as my last comment didn’t seem to show up.
I noticed that there’s a new IRBlasterWizard on the Hauppauge website as of Oct 2007 that claims to support 50 new devices, and since I can’t seem to get my BEV 4100 to work, I was wondering if we can get those new codesets? My card (actually an HVR1600) is in a Linux-only box at the moment, but if neccessary, I might be able to find some windows hardware to move it to and help the process…
Thanks in advance,
Steve
For anyone else who is having problems with this under OpenSuSE 11.0, I’ve gotten it working!
The instructions are at:
http://blog.jasonantman.com/2008/09/lirc-and-hauppauge-pvr-150-on-opensuse.html
Hi Mark,
Thanks for the great work on this driver. It’s worked beautifully for me on a Debian 2.6.22 system. However, I now upgraded to 2.6.26 (on an AMD64, stock debian kernel), and the latest version from your site wouldn’t compile until I included the patch at http://svn.debian.org/viewsvn/pkg-lirc/lirc/trunk/debian/patches/20_kcompat-2.6.26.patch
With the modifications from that patch I was able to compile, but the module won’t load. modprobe lirc_pvr150 gives:
[ 2686.524689] lirc_pvr150: no symbol version for lirc_register_plugin
[ 2686.524691] lirc_pvr150: Unknown symbol lirc_register_plugin
Trying to force the load with modprobe -f gives:
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Invalid module format
Am I missing something? Or does this require some more work on the source?
Thanks so much!
Mark,
Thanks so much for your work on this. The lirc_pvr150 module has been working flawlessly for me on a stock Debian 2.6.22-amd64 kernel.
However, I recently upgraded to the stock 2.6.26-amd64 kernel and haven’t been able to get the module to work since.
It wouldn’t compile, until I made the changes described in this patch: http://svn.debian.org/viewsvn/pkg-lirc/lirc/trunk/debian/patches/20_kcompat-2.6.26.patch
After that, it compiles, but doesn’t let me load the driver.
modprobe lirc_pvr150 gives:
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
(and the system log shows
[44272.757096] lirc_pvr150: no symbol version for lirc_unregister_plugin
[44272.757102] lirc_pvr150: Unknown symbol lirc_unregister_plugin
[44272.757503] lirc_pvr150: no symbol version for lirc_register_plugin
[44272.757505] lirc_pvr150: Unknown symbol lirc_register_plugin )
Trying to force the load over the unknown symbols with
modprobe -f lirc_pvr150 results in
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.26-1-amd64/misc/lirc_pvr150.ko): Invalid module format (no additional entry in the system log)
Am I missing something or is this something that needs to be fixed in the driver code?
Thanks again!
Dear Mark,
I’ve been using your pvr150 module for months, and it’s great, but after an update to kernel 2.6.26, I can’t get it to compile anymore. It complains about a missing autoconf.h, due to a different kernelsource layout??
Any chance you could help me?
I was wondering if the ir-blaster firmware has been updated to include all of the codes that are in the ir-blaster setup version 6 from hauppauge? If not, is there any way to get the codes from this version?
Hi, Mark,
Any plans to update for the latest 2.6.26 kernels ?
Compiling on Fedora8 2.6.26.5-28.fc8, I receive the error, related to a bug described here http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg551064.html
I have updated the driver to 2.6.27 kernels.
Sorry for the massive delays in getting around to this, I’ve been quite a bit side tracked. The good news is that work is being done to get lirc+this driver in the mainline kernels, so hopefully things will all work out of the box for people in future.
In terms of the ‘firmware’, I’ve not updated it in a while, I will try and do it in the next couple of weeks. I assume it’s probably been updated since the last revision.
Not sure the right place for this, but I’m hoping you can point me in the right direction. My running Mythbuntu 8.10, trying to get lirc running with my pvr-150. Actually, I got it working, sending and receiving, except…
My satellite receiver is a Dish Networks 3xx. That means the codes used for the blaster start at 2156396544. These codes cause lircd to segfault at startup. When I use a code less than 2147483648 (2^31), it works fine; once I pass 2^31, I get a segfault trying to start lircd.
I don’t even know where to report this bug. 🙂 Is it with the lirc folks, with the Ubunut folks, or here?
Anyway, a year ago, I had everything working fine on a “Myth on Fedora” install hand-patching with your code. Am I going to break things, make things better, or have no change if I take your tarball and install it?
Thanks.
tj
Try it I guess. Sounds like a really old bug that was fixed some time ago, but it might have got reintroduced somewhere along the way.
Sci-Atlanta Explorer 4250 – codeset 41 works as long as the emitter is directly over the receiver. If it\’s off by 1mm it will not work.
it’s an led on the end of the wire, not an ir transmitter, so the range is short. 1mm is surprisingly short but at high frequencies the distance will be shorter. In summary, it’s not something i can do anything about — it’s just hauppauge using dirt cheap components!
I am having problems installing this with Ubuntu 8.10 and kernel 2.6.27-9-generic
Following instructions and running modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1 gives this output
FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.27-9-generic/kernel/ubuntu/lirc/lirc_pvr150/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
based on messages 231 233 I ried commenting out the line(s) with ivtv_reset_ir_gpio in lirc_pvr150.c (Had to comment out 3 lines for the compile to work)
but I still get the same module load failure
dmesg | grep lirc gives
449.106114] lirc_pvr150: disagrees about version of symbol ivtv_reset_ir_gpio
[ 449.106121] lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio
lirc fails to load already a process running.. how do I stop the other instance of lirc running? I thinh Mythbuntu 8.10 loads lirc, however my pvr150 would’nt work out of the box. this is the message I get when I run modprobe lirc_pvr150 debug=1
Feb 7 02:30:50 mythbuntu kernel: [ 2412.417405] lirc_dev: IR Remote Control driver registered, major 61
Feb 7 02:30:50 mythbuntu kernel: [ 2412.639299] bttv: driver version 0.9.17 loaded
Feb 7 02:30:50 mythbuntu kernel: [ 2412.639317] bttv: using 8 buffers with 2080k (520 pages) each for capture
Feb 7 02:30:51 mythbuntu kernel: [ 2412.839785] cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
Feb 7 02:30:51 mythbuntu kernel: [ 2412.870248] lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
Feb 7 02:30:51 mythbuntu kernel: [ 2412.870992] lirc_dev: lirc_register_plugin: sample_rate: 10
Feb 7 02:30:51 mythbuntu lircd-0.8.3[7312]: lircd(userspace) ready
Feb 7 02:30:51 mythbuntu kernel: [ 2413.133587] Error: Driver ‘i2c ir driver’ is already registered, aborting…
Any sugeestions?
Thanks 🙂