Filed Under (Random) by mark on 15-01-2006


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
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)


  1. 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.
  2. 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_.
  3. 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)
  4. 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).
  5. 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

    TV card
    i – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
    Save configuration & run configure


    make && make install.

  6. 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).

  7. Check everything is working so far:

    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    Check 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.0

    This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.

  8. 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.
  9. 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/lirc0 or similar, then try mknod /dev/lirc0 c 61 0 if the steps below fail.

    modprobe lirc_dev && modprobe lirc_pvr150 debug=1
    lircd --device=/dev/lirc0

  10. You can now check if the remote is working using irw. Run this, and press buttons on the remote. You should see some output like

    0000000000001795 00 Down Hauppauge_350.

  11. 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.

  12. 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).
  13. 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.
  14. If you’re happy, you can always send me beer money. If not, add comments at the bottom 🙂

That’s it, good luck!


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

366 Responses to “LIRC PVR-150 IR blaster support, version 3”

Pages: « 1 [2] 3 4 5 6 7 8 » Show All

  1. 51
    mark Says:

    Yup, that would certainly help. Feel free to mail me with details (mark@npsl.co.uk) — I should be able to get around to it tomorrow as I have the next few days off.

  2. 52
    Dave Rose Says:

    Mark, when you say:

    “there is as yet no lirc release that supports the 2.6.16 kernel.”

    I’m a bit confused, I am running lirc-0.8.1 on a 2.6.15/16 kernel now, I got my RPM from:


    They have a source RPM there if it helps…of course it does not contain any of your code.

  3. 53
    mark Says:

    It must be based on a CVS snapshot. See:


    lirc-0.8.1 is not yet released.

  4. 54
    Dave Rose Says:

    Account information has been sent to you…good luck.

  5. 55
    mark Says:

    Now fixed (& fixed package uploaded). Thanks for the help!

  6. 56
    Adam Says:

    The new package works great, thanks Mark.

  7. 57
    Dave Rose Says:

    Just trying it now, don’t know if you noticed, but the configure script spewed out a few things right at the beginning for me:

    checking whether build environment is sane… yes
    /usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/missing: Unknown `–run’ option
    Try `/usr/local/src/lirc/lirc-0.8.1-CVS-pvr150/missing –help’ for more information
    configure: WARNING: `missing’ script is too old or missing
    checking for gawk… gawk

  8. 58
    Dave Rose Says:

    Hmm, compiles fine, but after the install I get:

    [root@draco modules]# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.16-1.2069_FC4smp/misc/lirc_dev.ko): Invalid module format

  9. 59
    Dave Rose Says:

    Ugh, my fault.

    I am using an SMP kernel, but I didn’t have the kernel-smp-devel RPM installed. Thus the vermagic was not right.


  10. 60
    Julius Says:


    I have the light going on the IRblaster, (and irw getting the Hauppauge remote keys) but I don’t know which codeset to use. I have a lirc file though which is supposed to work for the STB (Pace DSR620-GM) from:

    Can you tell me which codeset is associated with this STB?

    Thanks for the howto; the comments are useful too!

  11. 61
    mark Says:

    Dave/Adam: great, thanks!

    Julius: That lirc configuration file won’t work with the PVR-150.
    Please use the lircd.conf above and follow step #9 with the send_power_new script.


  12. 62
    Dave Rose Says:

    The only codeset in the list that says Pace is 101…try that 🙂

    Also, instead of editing the lircd.conf and removing the unwnated entries and renaming things, I just prepended the code set to the irsend line…here is the script I use. Since I really only care about the digits…

    # Quick and dirty change channel script
    # Dave Rose (drose@drcsDOTca)

    $remote_name = “blaster”;
    $prepend = “1_28_KEY_”; # put your codeset here
    $enter = “1_28_KEY_ENTER”;

    sub change_channel {
    my($channel_digit) = @_;
    system (“$irsend SEND_ONCE $remote_name $prepend$channel_digit”);
    sleep 1;


    if ($channel =~ /power|select/) {
    } elsif (length($channel) > 2) {
    } elsif (length($channel) > 1) {
    } else {
    system (“$irsend $options SEND_ONCE $remote_name $enter”);

  13. 63
    Julius Says:

    Sweet as. I’ll give it a crack and see when the STB’s power goes off/on and watch the numbers on the screen at the same time. (Unfortunately I don’t have the STB at my place so I’ll post in a few days).

    Thanks for the help!

  14. 64
    Julius Says:

    Unfortunately it didn’t work. I tried it in XP too with the latest IRblaster config tool. I have asked techsupport at hauppauge.com to see if they don’t support the STB and if they’ll send an update to me, but I’m not holding my breath. Does anyone know if it is likely to happen?

    Also, let’s say the following lircd.conf file is correct (http://lirc.sourceforge.net/remotes/pace/RC-30) for the STB I’m wanting to control, would I just replace all info between (and including) “bits” and “endcodes” in the section with the name blaster? Or does the blaster firmware require codes that have been created by hauppauge in a special format?

  15. 65
    mark Says:

    Unfortunately it requires specially formatted data so no other lirc configuration will work. If you can get it working under XP, it will be possible to get it to work under linux as well, but if not unfortunately there’s little to be done.

    Might be worth making sure you had the LED in the right place on the STB — it has a very short range. It’s also not always where the LED is that lights up when you press the remote (if any) — you need to look for receiver module with a torch generally as they are typically behind a filter.



  16. 66
    Julius Says:

    Yeah I might try a third time. I tried it in two places. There are currently two other blaster like devices which control the STB so I’m pretty sure where to put it. I also did the torch thing. The other blaster devices are from: a VHS video player/recorder and cabling from around the house so other sky remotes can change the channel in other locations.

    Interestingly the IR transmitter’s “bulb” didn’t light up when looking through my camera. I could see the blaster “bulb” next to the LED (closer to where the wire connection than the LED) so I could figure out where to put it but it doesn’t look good. I wish I could use an irw program to test it is working. The only thing is if the LED is blinking, I guess it can’t be broken, unless it’s wired in parallel and broken inside the little plastic piece (unlikely I think!)

    Thanks for all the help. I’ll let you know if I get it going of hauppauge go good. If you know of another way to control it, using another IR blaster device (my shuttle has a serial port) I might give it a go.

    Thanks again.

  17. 67
    Sebastiaan Says:

    Hi Mark,
    I have a issue with this lircd.conf for the ir blaster. If i use your suplied lircd.conf file (placed in /etc/lircd.conf) i get following error when starting the lircd:

    lircd -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid

    lircd: error in configfile line -2147483648:
    lircd: Segmentation fault

    I tried removing all codes, only leaving the 0_0_KEY like:
    begin raw_codes
    name 0_0_KEY_0
    end raw_codes

    with this lircd.conf the blaster works, no error and the led on the blaster lites up when i do a
    irsend -d /dev/lircd1 SEND_ONCE blaster 0_0_KEY_0

    I assume there is a mismatch between with my firmware and the lircd.conf you supplied.
    When loading the drivers my syslog says:
    Apr 23 13:09:19 verena kernel: lirc_pvr150: firmware of size 248009 loaded
    Apr 23 13:09:19 verena kernel: lirc_pvr150: 637 codesets loaded
    Apr 23 13:09:19 verena kernel: lirc_pvr150: 01 60 00 01
    …. lots of numbers…..
    Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    so this seems ok with the only difference of the 637 codesets loaded compaired to 575 and the different file size of the firmware compaired to the listings you provide above

    Is there a way to create a lird.conf which fits to my firmware?


  18. 68
    mark Says:

    Julius: there are stacks of other IR blaster devices, see http://lirc.org/ + the lirc list for more details.

    Seb: that’s a lirc userland daemon bug (which is actually just the standard lirc code). Can you compile lirc with debug turned on, then run it in gdb and mail me the backtrace?

    Thanks, Mark.

  19. 69
    Sebastiaan Says:

    I compiled lirc with debug turned on:
    ./configure –enable-debug –with-driver=hauppauge_pvr150
    make && make install

    then I runned lircd in gdb:
    verena:/dev# gdb /usr/local/sbin/lircd
    GNU gdb 6.4-debian
    Copyright 2005 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-linux-gnu”…Using host libthread_db library “/lib/libthread_db.so.1”.

    (gdb) set args -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid
    (gdb) show args
    Argument list to give program being debugged when it is started is “-n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid”.
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n –device=/dev/lirc1 –output=/dev/lircd1 –pidfile=/var/run/lirc1.pid
    lircd: error in configfile line -2147483648:
    Program received signal SIGSEGV, Segmentation fault.
    0x00002aaaaac364b0 in strlen () from /lib/libc.so.6

    does this mean anything to you?? I doesn’t tell me a thing 😉

  20. 70
    Alex Says:

    Thanks!! Worked great for the Hauppauge PVR 250!

  21. 71
    Tommy Says:

    I was so excited when everything just worked so smoothly until step 9. Unfortunately it does not seem that my Scientific Atlanta Explorer 1850 is supported as this time (verified with an installation on winxp). I will try to bother Hauppauge for support. Oh well…it was fun while it lasted. Though it didn’t work for me I really appreciate the efforts that you put into this. I will let you know if I get some kind of response from Hauppauge.

    If anyone knows of any alternative method to make IR blaster work with my cable box, I would be very interested to know. I’ve done a lot of searches on google and websites but I have not been successful so far. Thanks.

  22. 72
    Mike S. Says:

    What are the chances of having a blown IR LED?

    I have successfully installed everything and get no errors when running the “send_power_new” script, but I get no blinking light on the transmitter. Should the light emitted from the transmitter be visible?

    The IR receiver, however, works fine with the PVR-150 remote (model 1045). I pulled the plastic end apart on the blaster and checked the voltage. I *do* get a small voltage increase while the script runs, but don’t see any light and can’t turn on my Motorola DCT-2224. So my conclusion is the actual LED is busted. Anyone have any advice?

    Another question: If I’m satisfied at least the software is working, how do I load this on startup. On Fedora Core 5, I’ve placed the startup script in /etc/init.d and configured it to start when booting, but what do I put in the /etc/modprobe.conf file to load the lirc kernel module on startup? Any help?

  23. 73
    Xavier Says:

    I come here only when I have a problem, sorry about that 🙂
    I change my kernel (yum automatic 🙁 )
    I compile again the pre-patched lirc 0.8.1 CVS as of 2006-04-13 but i still have the same problem:
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.16-1.2122_FC5/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)
    I have the devel for 2.6.16-1.2122 only…
    any idea

  24. 74
    Ryan Says:


    Thanks for the tutorial and the code – I was on a roll…

    After getting all of this configured, while I was running your power on/off script my light was blinking (albeit very faintly… is that normal?), and now it’s not blinking any more at all… should I take this to mean that the hair-thin wire that leads to the ir blaster has broken? Or should I stick with it? If it’s broken, should I bust it open to fix it or just give up?


  25. 75
    Xavier Says:

    forget me, yum forgot to update ivtv-kdml ….

  26. 76
    Bill Says:

    I’ve installed KnoppMyth version R5C7 on my system, and am attempting to use these steps to get the IR blaster on my PVR 150 card working. I’m getting to step 4 and failing. Here is what my syslog output is:

    Jun 12 00:20:26 backend kernel: kobject_register failed for i2c ir driver (-17)
    Jun 12 00:20:26 backend kernel: [kobject_register+54/96] kobject_register+0x36/0x60
    Jun 12 00:20:26 backend kernel: [bus_add_driver+64/160] bus_add_driver+0x40/0xa0
    Jun 12 00:20:26 backend kernel: [driver_register+66/80] driver_register+0x42/0x50
    Jun 12 00:20:26 backend kernel: [pg0+273991046/1067881472] i2c_add_driver+0x46/0xc0 [i2c_core]
    Jun 12 00:20:26 backend kernel: [pg0+276901162/1067881472] init_module+0x5a/0x60 [lirc_pvr150]
    Jun 12 00:20:26 backend kernel: [sys_init_module+338/528] sys_init_module+0x152/0x210
    Jun 12 00:20:26 backend kernel: [syscall_call+7/11] syscall_call+0x7/0xb

    That’s what comes up as a result of the “modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1” command.

    Anything you can suggest? I believe this version of KnoppMyth has IVTV .4.4 builtin. So I didn’t do anything for step 1. I just skipped right ahead to step 2. I haven’t rebooted or anything at any point in these steps, there was no directions indicating I needed to reboot or anything for a certain step to take effect, is this correct? Anything you can offer is muchly appreciated.


  27. 77
    Kels Says:

    Hey Man you RULE! I’ve been using this patch and the instructions you provided. It works great with on my Slackware Mythbox. Thanks for taking the time to do this. I’ll send you beer money soon 🙂

  28. 78
    Simon Baxter Says:

    Hi – I’ve been following all the above, have built LIRC from the lirc-0.8.1-CVS-pvr150.tar.bz2.

    IVTV 0.6.3 loads fine, but I still can’t see the IR hardware:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found

    I tried:
    [root@media firmware]# ivtvctl –reset-ir
    ioctl IVTV_IOC_RESET_IR ok

    but still the same.

    I’ve tried pulling the card, cold reboots, everything.

    Can anyone help??

  29. 79
    Simon Baxter Says:

    Any chance I’m using the wrong version of the card hardware?

    [root@media firmware]# ls -l
    total 812
    -rw-r–r– 1 root root 248009 Mar 28 05:14 haup-ir-blaster.bin
    -rw-r–r– 1 root root 376836 May 26 13:19 v4l-cx2341x-enc.fw
    -rw-r–r– 1 root root 155648 Jun 2 07:49 v4l-cx2341x-init.mpg
    -r–r–r– 1 root root 16382 May 26 13:19 v4l-cx25840.fw
    -r–r–r– 1 root root 16382 May 26 13:24 v4l-cx25848.fw

    ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)

    i2c-1 i2c ivtv i2c driver #0
    i2c-0 smbus SMBus Via Pro adapter at 5000
    [root@media firmware]# i2cdetect 1
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-1.
    I will probe address range 0x03-0x77.
    Continue? [Y/n] Y
    0 1 2 3 4 5 6 7 8 9 a b c d e f

    [root@media firmware]# i2cdump 1 0x61
    No size specified (using byte-data access)
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-1, address 0x61, mode byte
    Continue? [Y/n] Y
    0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
    00: fc 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ?|||||||||||||||
    10: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    20: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    30: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    40: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    50: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    60: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    70: 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c 7c ||||||||||||||||
    80: 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c 3c

  30. 80
    raj Says:

    I did installed the package and while checking the output of the command :
    modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    it is giving an error message like
    FATAL :can’t find PVR_150…………….

    So let me know what I have to do now.

    Thanks alot!

  31. 81
    raj Says:

    Hi Mark,
    linux:~ # modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1

    given me the following error message……..

    FATAL:Module lirc_pvr150 not found…..

    Please suggest me regarding!

  32. 82
    Xavier Says:

    Sorry to bother you again. I installed again my computer after my harddrive died.
    But I can’t use lirc_pvr150
    when i load lirc_dev, I get:
    lirc_dev: IR Remote Control driver registered, at major 61
    but when i try to load lirc_pvr150, I’ve got no error but nothing at all as well 🙁
    the device /dev/lirc* doesn’t exist.
    with lirc_i2c, everything work well, but I definitly need the IR Blaster.
    I try to dig for few days now without any clue.
    I use ivtv-0.7-115.rhfc5.at and lirc-0.8.1-cvs20060325_58.rhfc5.at. I can’t remove lirc’s rpm because of the dependance however I installed the “pre-patched lirc 0.8.1 CVS as of 2006-04-13”

  33. 83
    Duane Says:

    I recently upgraded from time warner analog cable and already have pvr-150’s but wasn’t using the IR because when I first tried it, it was so bodgy, the remote would work for 10 seconds or so then require a cold boot to start working again…

    So anyways upgraded yesterday to directv and while I had a perfectly working mythtv setup, I didn’t have a way to change the channels short of some voo doo magic using usb to serial boxes null modem cables and pci serial card at large expense on top of my existing setup.

    Then I remembered the IR ports/cables for the PVR 150’s and started googling about and thankfully came across your website and I can’t thank you enough (will send you beer money next pay cheque)…

    I use ubuntu and because of updates to hal and other systems ivtv and haupage firmware needs to go into /lib/firmware/`uname -r`/

  34. 84
    Kels Says:

    Hey Xavier,
    The patch for ivtv-.7xx is broken I beleive until Mark updates them.
    I tried upgrading too but now I’m going back to a older version of kernel and ivtv just to get back support.

  35. 85
    raj Says:


    I have followed all the steps mentioned, I still seem to have problems running irw command, somtimes it says directory not found, and some times “Connnection Refused” , Not sure what’s going on. I copied your
    lircd.conf file owerwriting my existing lircd.conf file.
    I think I have successfully completed all steps till Step 7, Step 8 does not seem to be working.

    Here is my demsg:

    irc_dev: module not supported by Novell, setting U taint flag.
    lirc_dev: IR Remote Control driver registered, at major 60
    lirc_pvr150: module not supported by Novell, setting U taint flag.
    lirc_pvr150: no version for “ivtv_reset_ir_gpio” found: kernel tainted.
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    SFW2-OUT-ERROR IN= OUT=eth0 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=20328 DF PROTO=TCP SPT=21036 DPT=80 WINDOW=8360 RES=0x00 ACK FIN URGP=0
    SFW2-OUT-ERROR IN= OUT=eth0 SRC= DST= LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=20330 DF PROTO=TCP SPT=21036 DPT=80 WINDOW=8360 RES=0x00 ACK FIN URGP=0
    Warning: /proc/ide/hd?/settings interface is obsolete, and will be removed soon!

    Here is my ps command output

    oot 6584 1 0 09:00 ? 00:00:00 [lirc_pvr150]
    root 6901 6245 0 09:24 ? 00:00:04 kio_file [kdeinit] file /tmp/ksocket-root/klauncherU8x7ac.slave-socket /tmp
    root 7033 1 0 09:48 ? 00:00:00 lircd –device=/dev/lirc0
    root 7034 6538 0 09:48 pts/1 00:00:00 ps -eaf

    which shows that lircd is loaded and running.

    Please help.

    Thank You

  36. 86
    raj Says:

    Mark ,

    One more thing, I am using Hauppage PVR-150 on Suse Linux

  37. 87
    mark Says:

    Right, so I haven’t been at this since April! Work, holidays & decorating have been consuming all of my spare time, plus having to deal with the hundreds of spam comments has kind of been putting me off 😉 So I expect most of this is out of date, but I’ll reply to everybody in order.

    Sebastiaan: I think that’s a AMD64 specific lirc bug that’s been fixed in later releases. You can try http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2 if you like, that’s a sync with the latest lirc for Cecil of knoppmyth fame to test.
    Alex: cool, but mainline lirc should do just as well, this driver is really for supporting the IR blaster device that comes with the PVR-150.
    Tommy: bothering hauppauge is the best you can do. Since the data is encrypted I can’t support new devices, I can only copy what the hauppauge driver does.
    Mike S.: The light is visible, it’s just a standard LED (not an IR one, that’s why it has got such short range). I would make sure that the jack is fully in and if so connect a multimeter across the LED (the case should pop apart easily enough). If you are getting voltages on it then the LED is screwed and you should be able to get a new one from Hauppauge.
    Xavier: glad you got it sorted!
    Ryan: The light should blink — if it was going, it should carry on doing so. Try sticking a multimeter across it and making sure there is voltage on it as above.
    Bill: Can you recompile the driver with debug enabled and send the dmesg output then?
    Kels: great, glad it works for you!
    Simon: If it can’t find the IR chip, it won’t work. Best thing to do is try it in under Windows/and or in a machine with a different motherboard to confirm that the hardware is working.
    raj: driver not installed properly, did you do make install?
    Xavier: you’ll have to remove the rpms I’m afraid. You can only have one version of lirc, and if you want the IR blaster to work it has to be this one. I’d try the link higher up if you are using a 2.6.17 kernel (or go back to a 2.6.16 one.
    Duane: great!
    Kels: try the link at the top if you want to bump the kernel, that’s a resync with the latest lirc CVS
    raj: looks ok, but lircd isn’t playing. Check that it has created /dev/lircd and check the lirc log file to see what is going on. It’s possible it’s just shown up as /dev/lircd1 or some such, in which case you just need to run irw /dev/lircd1 or whatever.

  38. 88
    Xavier Says:

    I removed all the rpm of lirc except lirc-libs which should not be a problem.
    ty for your answer. which version of ivtv do you actually use ?

  39. 89
    chutzpah Says:

    I have a gentoo ebuild of this (I’m a gentoo developer) if anyone else is interested in it, I can set up an overlay and post it.

    The best way to reach me is to send me an email (just stick @gentoo.org after my handle)

  40. 90
    Simon Baxter Says:

    Thanks Mark – yip, looks like I had a faulty PVR-150 (or at least, the IR chip). Hauppauge in NY has replaced the card under RMA.

  41. 91
    Bill Says:

    “Bill: Can you recompile the driver with debug enabled and send the dmesg output then?”

    I don’t actually know how to do this. Plus, I’ve picked up another IR blaster elsewhere and have it working (A serial port blaster). I’m not so much worried about getting this one off the ground and working at this point, thanks anyways.


  42. 92
    Simon Baxter Says:

    Hi – HOORAY – the new card from Hauppauge seems to work, for IR receive anyway.

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    lirc_dev: lirc_register_plugin: sample_rate: 10

    …and all buttons on the remote work.

    IR-Blaster doesn’t seem to work though:

    irsend -d /dev/lircd SEND_ONCE blaster 1_680_KEY_POWER
    irsend: command failed: SEND_ONCE blaster 1_680_KEY_POWER
    irsend: hardware does not support sending

    This is a new machine, with fresh everything.

    Any ideas?

  43. 93
    mark Says:

    Xavier: what’s in dmesg? Does the module load properly? Can you build it with debug enabled and send the output with modprobe lirc_pvr150 debug=1?

    Simon: you are using the wrong driver — lirc_i2c vs lirc_pvr150.

  44. 94
    Xavier Says:

    ok, I build it with debug mode.
    lsmod | grep lirc : no output

    modprobe lirc_dev
    dmesg output:
    lirc_dev: IR Remote Control driver registered, at major 61

    modprobe lirc_pvr150 debug=1
    dmesg: nothing more

    lsmod | grep lirc :
    lirc_pvr150 19264 0
    lirc_dev 15524 1 lirc_pvr150
    ivtv 175760 1 lirc_pvr150
    i2c_core 22209 12 lirc_pvr150,nvidia,wm8775,via686a,cx25840,tda9887,i2c_isa,tuner,ivtv,i2c_algo_bit,i2c_viapro,tveeprom

    I build it with debug mode enabled…

    rpm -qa | grep ivtv:

    uname -r:

    I don’t really want to go back to 2.6.16 because i use atrpm, where this kernel is not available anymore and antway, it’s a nithgmare with other stuff

  45. 95
    mark Says:

    The only way that I can see that you would get no further output when loading lirc_pvr150 is if ir_probe doesn’t get called with the right i2c adapter id, as per this test:

    #ifdef I2C_HW_B_CX2341X
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848) ||
    adap->id == (I2C_ALGO_BIT | I2C_HW_B_CX2341X))

    Can you add:

    dprintk(“adapter id %\n”, adap->id);

    to the top of ir_probe to see what adapter ids it is being called with?

    Otherwise I can have a poke around via SSH if you want.

  46. 96
    Xavier Says:

    I might stole your time, as i don’t seem to have the same source as you:
    I2C_HW_B_CX2341X is not in my source (i use the link above http://www.blushingpenguin.com/mark/lmilk/lirc-0.8.1-CVS-pvr150.tar.bz2 )
    so at the top of ir_probe, i’ve got :
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848))
    anyway by adding the dprintk, dmesg said:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 65568
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 0
    lirc_pvr150: adapter id 0

    Is there any change to have lirc_pvr150 added in lirc cvs ?
    could you reply on maxpower44 at tiscali.fr ? should be easier for both of us.
    thx for your help.

  47. 97
    mark Says:

    Try this one:


    It’s a sync with the current lirc CVS which should support 2.6.17+ kernels. If it works for you I will bump the version linked to in the article.



  48. 98
    Kels Says:

    Thanks for the new work. I’ll report once i recompile 2.6.17 again.

    I’m using IVTV 0.6.2 with kernel on Slackware 10.2


  49. 99
    Xavier Says:

    seems to work pervectly with ivtv 0.7 and kernel 2.6.17-1.2139.
    thanks a lot 🙂 again

  50. 100
    Raghu Says:

    I was having the same problem with lirc_pvr150 not creating the /dev/lirc0 device. The problem is in ir_probe function in lirc_pvr150.c the condition for probing the pvr150 has changed with the kernel 2.6.17 and ivtv 0.7.0-117. Replace the the following line
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848))
    with the ones below
    if (adap->id == (I2C_ALGO_BIT | I2C_HW_B_BT848) ||
    adap->id == (I2C_ALGO_BIT | I2C_HW_B_CX2341X))
    That has fixed my i2c_pvr150.

    Thanks for all the work on this module.

Pages: « 1 [2] 3 4 5 6 7 8 » Show All

Leave a Reply