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

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

  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
    ./setup.sh

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

    then:

    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!

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


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

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

  1. 251
    Mickey Says:

    I am spamming your blog :( . Moving PVR150 to a new PCI slot did not help. Same problem.

    –reset-ir also still does not react.
    —————–
    ivtvctl –reset-ir
    ioctl VIDIOC_INT_RESET failed: Invalid argument
    —————–

    I tried old versions of ivtvctl was not able to recognize itvt device …

    M.

  2. 252
    Yadav Says:

    Hey, how long do you estimate it will be until 2.6.19 support is available? Sorry to bother you, it´s the last thing left until I finish my PC.

  3. 253
    Mickey Says:

    Man … and I think that I hate this PVR …

    It is working again … And I did nothing. I went to sleep yesterday after giving up and today after reboot, that card is working … I got some new messages after modprobe debug=1:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_dev ([-1]): open called
    lirc_dev ([-1]): open result = -ENODEV
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    lirc_pvr150: poll thread started
    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

    And I have a bad feeling about rebooting my computer :) ). I will this PVR a chance until weekend, and if I/you don’t find a working solution to be able always to use it, I get a new one.

  4. 254
    Mickey Says:

    Hi … me again and again and again …

    It worked for two days. But now I booted, and the remote is again not recognized.

    —————————-
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no
    lirc_pvr150: ivtv i2c driver #0: no devices found
    —————————-

    I hope that you find time to help me with this really stupid problem. Thanks a lot. I will send you ssh login data if you have enough time.

    Thanks a lot.

  5. 255
    Mickey Says:

    I am using your homepage as a chat :( . I am really sorry to interrupt you, but I it is working again. I put the computer to sleep (echo mem > /sys/power/state) and I “re-modprobed” the modules and everything was OK.

    –reset-ir still gives the same error:
    ioctl VIDIOC_INT_RESET failed: Invalid argument

    my “offer” to give you a chance to help is still open :) . Thanks.

  6. 256
    Kellen Says:

    Hello,

    Thanks for the driver! It works for a wintv-go card after much fiddling with kernel modules and I was wondering if it is possible to make the ir driver independent of ivtv. ivtv has a nasty habit of destabilizing my system and it would be great if I didn’t have to load it.

    Thanks again for the effort!

  7. 257
    Octavian Says:

    Hi Marc,

    Long time no comment.

    After a lot of trials I’ve concluded that the remote only works after a reset. Looks like trivia section.

    This is very annoying since one has to reset the computer several times until the remote starts working.

    In the past it ALWAYS worked by issuing a ivtvctl –ir-reset. With the latest drivers this is not possible anymore.
    I have tried to write a feature request to the ivtv team biut I could not find the palce. Only developers can write tickets?

    Best regards,
    Octavian

  8. 258
    Octavian Says:

    BTW.
    1. I had to submit the text several times until it got published.
    2. I never mentioned it before, but you give excellent support to the poor users. GOOD JOB

    P.S. One error was:
    WORLD PRESS
    Error: please type a comment.

  9. 259
    deon stoltz Says:

    Hi
    It seems your lircd.conf does not contain the (blaster) cmd for codeset 682 (Dstv) although it is listed in your IRcodesets page (we are lucky!). I am not sure how to add this. Do ou have an updated copy?
    Thx
    Deon
    (ps. second post, got only a black screen last time so not sure if it went thru or not)

  10. 260
    Dave Rose Says:

    Any chance of getting a 2.6.20 kernel to work:

    [root@draco lirc-0.8.1-CVS-pvr150]# modprobe lirc_dev
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    FATAL: Error running install command for lirc_dev
    [root@draco lirc-0.8.1-CVS-pvr150]# modprobe lirc_pvr150
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    WARNING: Error running install command for lirc_dev
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_dev.ko): Invalid module format
    WARNING: Error running install command for lirc_dev
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.20-1.2944.fc6PAE/misc/lirc_pvr150.ko): Invalid module format
    FATAL: Error running install command for lirc_pvr150

    lirc_dev: disagrees about version of symbol struct_module
    lirc_dev: disagrees about version of symbol struct_module
    lirc_dev: disagrees about version of symbol struct_module
    lirc_pvr150: disagrees about version of symbol struct_module

  11. 261
    richard joss Says:

    Mark – what a great set of stuff on your site. I want to try and get the remote and ir blaster that comes with the pvr150 to change channels on my pace 2600N sky digibox. I’m running mythtv on fedora fc6 and have managed to get mythtv to show sky output OK. Also, the haup remote works ok with the PC.

    My question is: The fc6 kernel is 2.6.20-1 and therefore more uptodate than the kernels your stuff relates to. I can do a bit of compiling but not much more than that. Will your files run ok with this kernel, or should I wait for your next updates? It has taken me ages to get mythtv to work and i don’t want to try installing older kernels!

    Can you help?

    Thanks.

    PS – get my remote to change channels on a sky box and you definitely have a contribution on the way .

    Regards

    Richard

  12. 262
    richard joss Says:

    mark

    PS – tried the email address in earlier posts (nspl) but it bounced – probably a bit out of date?

  13. 263
    richard joss Says:

    Sorry Mark, my bad. I sent a copy of the above to your email address in an ealier post but typed it wrongly. Have now resent it.

    Richard

  14. 264
    mark Says:

    Hi Mickey, wrt to the ivtvctl –reset-ir, we are still waiting on a resolution from Hans, the ivtv driver developer, who says it should be straightforward. He’s still out of action for a bit though as he’s moving house.

    Kellen: I am surprised it works for a non PVR-150 card. Does that thing have an IR blaster? What driver is the card using? If ivtv is not in use I can’t see how it would destabilise your system.

    Deon: I have updated the lircd.conf linked above, I missed this the first time around, please download it again.

    To all those using 2.6.20 kernels please try this port. It is linked to in the comments above somewhere, but I am awaiting feedback from somebody to let me know it works before updating the main post text.

    HTH,

    Mark

  15. 265
    Amankhan Says:

    Hi Mark,

    I just tested out the port of your driver for the 2.6.20 kernel, and I’m getting this response when I run the intial ./configure:

    configure: error: no driver specified, try ./configure –help

    Can’t get as far as the choosing of a TV card, h – Hauppauge PVR-150 TV card, etc.

  16. 266
    mark Says:

    The GUI has been renamed to setup.sh, run that instead.

  17. 267
    Amankhan Says:

    Thanks, Mark. That did the trick.

    I completed the rest of the install, and everything is working perfectly now. Thanks again for all your hard work!

  18. 268
    Peter Says:

    Ok, so I am having some issues…obviously J I have a 150 MCE card with an IR Blaster. I can get the remote to send commands and can see them on irw. I have compiled the cvs version of lirc, because I could not get your version to compile. I am running Fedora Core 6 [2.6.20-1.2944]. Should I try to compile the version you made for cecil? I have a Philips STB on Surewest cable.

    Output of dmesg | grep lirc
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_mceusb2: no version for “lirc_get_pdata” found: kernel tainted.
    lirc_mceusb2: Philips eHome USB IR Transciever and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.28 $
    lirc_mceusb2: Daniel Melander , Martin Blatter
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_mceusb2[3]: Topseed eHome Infrared Transceiver on usb1:3
    usbcore: registered new interface driver lirc_mceusb2
    usbcore: deregistering interface driver lirc_mceusb2
    lirc_mceusb2[3]: usb remote disconnected
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_mceusb2: Philips eHome USB IR Transciever and Microsoft MCE 2005 Remote Control driver for LIRC $Revision: 1.28 $
    lirc_mceusb2: Daniel Melander , Martin Blatter
    lirc_mceusb2: debug mode enabled
    lirc_mceusb2: usb probe called
    lirc_mceusb2: acceptable outbound endpoint found
    lirc_mceusb2: acceptable inbound endpoint found
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_mceusb2[3]: Topseed eHome Infrared Transceiver on usb1:3
    lirc_mceusb2[3]: receive request called (size=0×10)
    lirc_mceusb2[3]: receive request complete (res=0)

    Output of dmesg | grep ivtv
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.10.1 (tagged release) loading
    ivtv: Linux version: 2.6.20-1.2944.fc6 SMP mod_unload 686 4KSTACKS
    ivtv: In case of problems please include the debug info between
    ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    ivtv: any module options, when mailing the ivtv-users mailinglist.
    ivtv0: Autodetected Hauppauge card (cx23416 based)
    ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    ivtv0: Encoder revision: 0×02060039
    ivtv0: Autodetected Hauppauge WinTV PVR-150
    tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    cx25840 1-0044: cx25843-23 found @ 0×88 (ivtv i2c driver #0)
    wm8775 1-001b: chip found @ 0×36 (ivtv i2c driver #0)
    ivtv0: Registered device video0 for encoder MPEG (4 MB)
    ivtv0: Registered device video32 for encoder YUV (2 MB)
    ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    ivtv: ==================== END INIT IVTV ====================

    It is not loading the firmware that you made. How can I go about getting it to load. Where does it need to go? Do I need to send a command to ivtv to tell it to use a different firmware?

    When I send a command to the irblaster with irsend it sends successfully but It does not blink.

    Any help would be great!!! Thanks.

  19. 269
    Greg Says:

    Hey Mark-

    Your solution worked great on Ubuntu 7. I only had a few problems because I had previously set it up to just use the receiver. Removing the i2c module fixed it all. The only thing I am wondering now is if I can use this blaster to turn my TV on and off via the remote. Any thoughts on if that is possible, and if so, how?

    Thanks!
    Greg

  20. 270
    greg Says:

    I did a little more playing and see that my TV responds to some of the commands, but only by flashing a green light. I assume this just means it is seeing some sort of IR that it recognizes, but doesn’t know what to do with it. I also set up irw to listen to the current TV remote to see what the power command was. When it listens to the power command, it shows 0x000000000000100C. I was thinking that maybe if I was able to convert this into one of the raw codes that the blaster seems to deal with, maybe it would control the TV. Straight up hex->dec conversion does not seem to work with the blaster. Any ideas on how to get the power code for my TV into the blaster configuration file?

    Thanks again,
    Greg

  21. 271
    Arvedui Says:

    Similar to Amankhan, I am having trouble getting started building the driver. I am running 64-bit Fedora Core 6, kernel version 2.6.20 as root. I have tried ./configure and ./setup.sh, and several other permutations. The errors returned include the path that is being searched and behave like it cannot find the script processor.

    Any ideas?

  22. 272
    mark Says:

    Peter: this is not for the MCE version, I don’t know anything about that.
    Greg: As I’ve repeated many times above, you can only send what’s in the Hauppauge database. If none of the codesets work with your TV, it’s unfortunate, but that’s it, you’re stuffed.
    Arvedui: Can’t tell anything without the error message.

  23. 273
    Peter Says:

    Mark:

    I did get the blaster to work, turns out that I had the ir cable plugged into port 1 instead of port 2…go figure. After a few days it stopped working after I did a cold boot…damn!

    I think that your port of lirc does work with the mce version, I just reinstalled and am trying again. One question still remains in my head unanswered, how does lirc know about the .bin firmware. What loads it and when?

    Anyone else have luck getting the mce version to work?

  24. 274
    mark Says:

    The tarball contains the whole of lirc, there wasn’t any point chopping it out, with the addition of a specific driver for the vanilla PVR-150. lirc_mceusb is a totally different piece of hardware and does not use my driver, full stop. I would suggest a) using the vanilla lirc package and b) asking on the lirc lists about any issues (you want the vanilla package because they almost certainly will not want to support it if you are using some random development snapshot of the driver, which basically you are). Since this piece of hardware is in their main distribution they are _much_ more likely to be able to help you out than I am. I don’t possess an MCE flavour card and so really am not going to be able to diagnose any issues with it.

  25. 275
    Peter Says:

    Mark:

    I will try to emulate my actions that led up to the successful changing of channels on my STB last week. By the vanilla release, I take it you mean the plain distro of lirc? I will let you know I I can get this working tonight. I am really pissed since it was working. I was able to use ircrecord to get the raw codes and the channels were getting changed…

  26. 276
    mark Says:

    Yes, see http://lirc.org.

  27. 277
    Mike Says:

    Mark,

    I have followed your instructions, and everything seems to be working OK except certain codes on the IR blaster.

    The blaster blinks merrily as it works its way through your script, but when it hits certain codes I get errors and the LED does not blink.

    I compiled lirc with the debug assertions enabled. Here is what I get when I try to send one of these codes:

    root@mythtv:/usr/bin# irsend SEND_ONCE blaster 1_125_KEY_POWER
    buffer: -BEGIN-
    buffer: -SEND_ONCE blaster 1_125_KEY_POWER-
    buffer: -ERROR-
    irsend: command failed: SEND_ONCE blaster 1_125_KEY_POWER
    buffer: -DATA-
    buffer: -1-
    buffer: -transmission failed-
    irsend: transmission failed
    buffer: -END-

    This is accompanied by a syslog message like this:

    lirc_pvr150: failed to get data for code 32893, key 10 — check lircd.conf entries

    I am pretty certain my lircd.conf is fine.

    As coincidence would have it, I think one of these codes (1_125) will control my DirecTV set-top box, thus leaving me with a bit of a problem. From reading the Hauppauge site, I think this blaster ought to work OK with DirecTV boxes.

    Can you offer any guidance? My system is a new KnoppMyth install, version R5F1.

  28. 278
    Ziggy Says:

    Hi Mark,

    First off, thanks for all the work you’ve put into this. I’m trying to get the IR blaster to work for the WinTV-PVR-USB2 which i read on mythtv’s website should in theory be able to work just like the PVR-150. Do you know if this is in fact the case? Sorry if someone’s already mentioned this on the replies, but i didn’t notice anything after a quick search.

    Anyway, it looks like the chip is being found, but things still don’t work. Here’s my output from dmesg:

    [ 44.340000] lirc_pvr150: chip found with RX and TX
    [ 44.340000] lirc_dev: lirc_register_plugin: sample_rate: 0
    [ 44.376000] lirc_pvr150: firmware of size 258140 loaded
    [ 44.376000] lirc_pvr150: 654 codesets loaded
    [ 44.400000] lirc_pvr150: i2c_master_send failed with -5

    Is there a way to get more information on what the last line means? Any help would be appreciated. Thanks.

    Ziggy

  29. 279
    Jason Says:

    Just wanted to stop in and say thanks! Your PVR-150 package worked great.

    I hope you don’t mind I wrote up a blog post with some instructions on how to get it to work with MythDora 4.0 and a Scientific Atlanta Explorer 2200. I referred back to your site for the files and module installation instructions and if a different receiver was to be used. I just wanted make it easy for people that want to switch to the new MythDora 4.0 setup. Keep up the good work!!!

    http://charles.hopto.org/blog/?p=24

  30. 280
    Paul Says:

    Greg, could you give more details of how you installed in Ubuntu 7 ( feisty) and removing the i2c module. Thanks

  31. 281
    Jason Says:

    Just wanted to stop in and say thanks! Your PVR-150 package worked great.

    I hope you don’t mind I wrote up a blog post with some instructions on how to get it to work with MythDora 4.0 and a Scientific Atlanta Explorer 2200. I referred back to your site for the files and module installation instructions and if a different receiver was to be used. I just wanted make it easy for people that want to switch to the new MythDora 4.0 setup. Keep up the good work!!!

  32. 282
    Amankhan Says:

    Hi again, Mark.

    Just wanted to let you know that the 2.6.20 version does not work with the new Fedora 7 kernel. (2.6.21-1.3228.fc7). I didn’t exactly expect it to work, but just thought it might be good to let you know that I did attempt it. Here’s the error message I’m getting when trying to modprobe lirc_dev:
    a
    FATAL: Error inserting lirc_dev (/lib/modules/2.6.21-1.3228.fc7/misc/lirc_dev.ko): Invalid module format

  33. 283
    ryan Says:

    I just bought a pvr-150, and I’ve followed all the guides, and at this point, the card works. I can tune in TV, get sound and so on. (has same remote and IR blaster I’ve seen in pictures).

    So I wanted to get the remote to work next. Followed this guide. As far as my problem, everything works except I can’t get any response when using irw. I can see junk appear if I “cat /dev/lirc/0″, or if I use mode2 I can see the codes come up as I hit buttons on the remote. I tried using irrecord, but no matter what I do, it gives me a junk lircd.conf file (the codes in the created file are all 0). None of the lircd.conf files I’ve found anywhere work. Im assuming the problem must be with the configuration somewhere as the computer knows when the remote is being hit.

    dmesg output
    [code]ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.10.1 (tagged release) loading
    ivtv: Linux version: 2.6.18-gentoo-r3 SMP mod_unload gcc-4.1
    ivtv: In case of problems please include the debug info between
    ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    ivtv: any module options, when mailing the ivtv-users mailinglist.
    ivtv0: Autodetected Hauppauge card (cx23416 based)
    ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
    GSI 20 sharing vector 0xD1 and IRQ 20
    ACPI: PCI Interrupt 0000:05:06.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 20
    ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    nvidia: module license 'NVIDIA' taints kernel.
    ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
    ivtv0: Encoder revision: 0x02060039
    tveeprom 2-0050: Hauppauge model 26152, rev E5B2, serial# 10317213
    tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
    tveeprom 2-0050: audio processor is CX25843 (idx 37)
    tveeprom 2-0050: decoder processor is CX25843 (idx 30)
    tveeprom 2-0050: has no radio, has IR remote
    ivtv0: Autodetected Hauppauge WinTV PVR-150
    ivtv0: reopen i2c bus for IR-blaster support
    tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
    ivtv0: Registered device video0 for encoder MPEG (4 MB)
    ivtv0: Registered device video32 for encoder YUV (2 MB)
    ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    tuner 2-0061: type set to 50 (TCL 2002N)
    ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    ivtv: ==================== END INIT IVTV ====================
    ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
    GSI 21 sharing vector 0xD9 and IRQ 21
    ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [APC3] -> GSI 18 (level, low) -> IRQ 21
    PCI: Setting latency timer of device 0000:01:00.0 to 64
    NVRM: loading NVIDIA UNIX x86_64 Kernel Module 1.0-9755 Mon Feb 26 23:16:31 PST 2007
    EXT3 FS on md2, internal journal
    usbcore: registered new driver usbserial
    drivers/usb/serial/usb-serial.c: USB Serial Driver core
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Handspring Visor / Palm OS
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Sony Clie 3.5
    drivers/usb/serial/usb-serial.c: USB Serial support registered for Sony Clie 5.0
    usbcore: registered new driver visor
    drivers/usb/serial/visor.c: USB HandSpring Visor / Palm OS driver
    it87: Found IT8712F chip at 0x290, revision 7
    it87-isa 9191-0290: Detected broken BIOS defaults, disabling PWM interface
    md: md0 stopped.
    md: bind
    md: bind
    raid1: raid set md0 active with 2 out of 2 mirrors
    Adding 1011832k swap on /dev/md1. Priority:-1 extents:1 across:1011832k
    eth0: no IPv6 routers present
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 258140 loaded
    lirc_pvr150: 654 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 2.1.0
    [/code]

    current versions of everything are (this is all on gentoo):
    whatever is on mark’s site
    ivtv 0.10.1-r1
    lirc 0.8.2_pre2 (and 0.8.1)
    kernel 2.6.18r3

  34. 284
    mark Says:

    Mike: the config file is wrong/mismatched with the dump file. Please check what you have got is what is linked above.

    Amankhan: Thanks for the info, I will update it at some point.

  35. 285
    Damian Says:

    Mark : Thanks! I got my feisty set up controlling my BSkyB box nicely.

    I just want to follow up on a previous post and merging your patch with LIRC. You said it was due to the firmware BLOB. Have Happauge not opened this up since? Or what is the situation? It would be great to not have to worry about a recompile every kernel change. All I would need is my lirc.conf! Also does ivtv being included in 2.6.22 make things easier?

    Thanks for all your effort on this.
    D.

  36. 286
    Seth Says:

    I’ve got the LIRC part working, and am even able to control Myth TV using the remote. However, when I try to send a command to my Dish 301 box, it fails. Here is the whole transcription:
    DVR:/home/mythtv# modprobe lirc_dev
    DVR:/home/mythtv# modprobe lirc_pvr150 debug=5
    DVR:/home/mythtv# lircd –device=/dev/lirc0
    DVR:/home/mythtv# exit
    exit
    schuyler@DVR:~$ irw
    00000000000017a1 00 Ch- hauppauge
    00000000000017a1 00 Ch- hauppauge
    00000000000017a0 00 Ch+ hauppauge
    00000000000017a0 00 Ch+ hauppauge
    0000000000001791 00 Vol- hauppauge
    0000000000001790 00 Vol+ hauppauge
    0000000000001790 01 Vol+ hauppauge

    mythtv@DVR:~$ irsend SEND_ONCE blaster 1
    irsend: command failed: SEND_ONCE blaster 1
    irsend: transmission failed

    And here is how it looks in /var/log/lircd:
    Jul 10 18:46:50 DVR lircd: lircd(hauppauge_pvr150) ready
    Jul 10 18:46:57 DVR lircd: accepted new client on /dev/lircd
    Jul 10 18:48:17 DVR lircd: removed client
    Jul 10 18:49:01 DVR lircd: accepted new client on /dev/lircd
    Jul 10 18:49:01 DVR lircd: write failed
    Jul 10 18:49:01 DVR lircd: Protocol error
    Jul 10 18:49:01 DVR lircd: error processing command: SEND_ONCE blaster 1
    Jul 10 18:49:01 DVR lircd: transmission failed
    Jul 10 18:49:01 DVR lircd: removed client

    I checked the permissions:
    DVR:~$ ls -l /dev/lirc*
    crw-rw—- 1 root video 61, 0 2007-07-09 21:49 /dev/lirc0
    srw-rw-rw- 1 root root 0 2007-07-10 18:46 /dev/lircd

    It is frustrating being so close, yet so far. Any ideas?

  37. 287
    phoner Says:

    I\’m trying to get the ir blaster to work with the motorola vip1200 (u-verse stb). The hauppauge software successfully learns the codes, how can I get them for use in lirc?

  38. 288
    Seth Says:

    I followed your instructions, and I’ve been able to get lirc working, but I can’t get the IR Blaster working. This is what I get.
    DVR:/home/mythtv# modprobe lirc_dev debug=1
    DVR:/home/mythtv# modprobe lirc_pvr150 debug=1
    DVR:/home/mythtv# lircd –device=/dev/lirc0
    DVR:/home/mythtv# irsend SEND_ONCE blaster 1
    irsend: command failed: SEND_ONCE blaster 1
    irsend: transmission failed

    I didn’t see any clues in the syslogs, but I’ve included them in case you see something I don’t.
    From /var/log/lircd:
    Jul 15 20:11:57 DVR lircd: lircd(hauppauge_pvr150) ready
    Jul 15 20:21:15 DVR lircd: accepted new client on /dev/lircd
    Jul 15 20:21:15 DVR lircd: write failed
    Jul 15 20:21:15 DVR lircd: Protocol error
    Jul 15 20:21:15 DVR lircd: error processing command: SEND_ONCE blaster 1
    Jul 15 20:21:15 DVR lircd: transmission failed
    Jul 15 20:21:15 DVR lircd: removed client
    From /var/log/messages:
    Jul 15 20:06:30 DVR kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: chip found with RX and TX
    Jul 15 20:09:52 DVR kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: firmware of size 258140 loaded
    Jul 15 20:09:52 DVR kernel: lirc_pvr150: 654 codesets loaded

    Any thoughts?

  39. 289
    Seth Says:

    I’m have a problem that seems related to Andrew Barbaccia’s and Mickey’s.

    I tried the cold reboot and the reset and still got:
    ivtvctl –reset-ir
    ioctl VIDIOC_INT_RESET failed: Invalid argument

    In /var/log/messages I get:
    Jul 28 22:26:04 DVR kernel: lirc_dev: IR Remote Control driver registered, at m\
    ajor 61
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: no version for “lirc_unregister_plugin\
    ” found: kernel tainted.
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: chip found with RX and TX
    Jul 28 22:26:19 DVR kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: firmware of size 258140 loaded
    Jul 28 22:26:19 DVR kernel: lirc_pvr150: 654 codesets loaded

    I think this is why I was getting a protocol error when trying an IRsend.

    The “kernel tainted” and lack of “firmware version 1.3.0″ message is what makes me think it is related, but since I didn’t see a response after a request was put in to Hans, I was wondering if Hans ever got back to you.

  40. 290
    Lance Says:

    Mark, thanks for all your hard work on this site. I feel as though you may be one of the few people who can help me get my PVR-150 remote to work.

    I am having the same issues as Noah. However, I didn’t see where the solution was for him or if it was fixable. I have not however, got the remote to work with a Linux release. I have tried both Ubuntu Edgy and Feisty. I can watch live TV no problem with MythTV in either release.

    Here is everything I have tried:

    Same hardware, different hard drive, the remote works with WinXP. So hardware should be ruled out.

    rmmod ivtv then modprobe ivtv with newi2c=0 and newi2c=1, no go.

    Tried both lirc_i2c and lirc_pvr150. Neither works with newi2c=0 nor newi2c=1.

    i2cdetect, looks the same as Noah’s, nothing appearing for 0×71.

    I have also set the BIOS PCI Latency Timer to 64 and 128. I have also set it at 32 and then overrode ivtv’s desire to set it to 64. No go here either.

    I have also downloaded your lirc-0.8.2-CVS-pvr150.tar.bz2 and tried it as well instead of the Ubuntu packages. No dice.

    Actually I do not need the blaster portion of the PVR-150 at this point. Going to use the built in tuner. I assume I can still use the lirc_pvr150 module.

    Any of the above attempts have all resulted in the usual messages from either lirc_i2c or lirc_pvr150 giving the following message(s):

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_i2c: probe 0x1a @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×18 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×71 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x4b @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×64 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0×30 @ ivtv i2c driver #0: no
    lirc_i2c: probe 0x6b @ ivtv i2c driver #0: no

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0×70 @ ivtv i2c driver #0: no
    lirc_pvr150: probe 0×71 @ ivtv i2c driver #0: no

    I even went to the trouble of adding some of my own debug code to lirc_i2c.c to verify where the issue is. The call to the i2c_master_recv function never returns a successful probe for any of the addresses it is checking.

    Any suggestions on how to get the IR chip to respond?

  41. 291
    Michael Evans Says:

    There is a know issue with kernel 2.6.22 and higher… Something about a structure’s string area becoming truncated and the end of the string over-writing a mutex. I seem to have that same issue and wonder if the pvr150 driver requires a similar patch.

    http://bugs.gentoo.org/show_bug.cgi?id=187822

    It would also be nice to know which patch-set to apply against gentoo’s sources so I could instead create my own portage overlay package with just the additional patch, instead of just saying grab the CVS tarball you’ve prepatched.

  42. 292
    Michael Evans Says:

    I highly suspect that mutex issue mentioned above. I tried configuring it your way, then doing a slightly modified gentoo style ./configure && make && make install. Locks up when I try to modprobe -v lirc_pvr150 . It prints absolutely nothing useful, except for it loading lirc_dev and lirc_pvr150.

    Here’s the ./configure, and the only additional patch I made was the one from the gentoo bugzilla thread linked in my prior post.

    /configure –prefix=/usr –host=x86_64-pc-linux-gnu –mandir=/usr/share/man –infodir=/usr/share/info –datadir=/usr/share –sysconfdir=/etc –localstatedir=/var/lib –localstatedir=/var –with-syslog=LOG_DAEMON –enable-sandboxed –with-kerneldir=/usr/src/linux –with-moduledir=/lib/modules/2.6.22-gentoo-r3/misc –disable-debug –with-x –with-driver=hauppauge_pvr150 –with-transmitter –libdir=/usr/lib64 –build=x86_64-pc-linux-gnu

  43. 293
    Michael Evans Says:

    (Hope this isn’t a duplicate, it seemed to dislike it the other two times.)

    This may also be useful.

    [ 124.698229] ivtv: ==================== START INIT IVTV ====================
    [ 124.698233] ivtv: version 1.0.0 (2.6.22-gentoo-r3 SMP mod_unload ) loading
    [ 124.874633] PM: Adding info for No Bus:pcmC1D2c
    [ 124.874688] PM: Adding info for No Bus:pcmC1D1p
    [ 124.874712] PM: Adding info for No Bus:pcmC1D1c
    [ 124.874735] PM: Adding info for No Bus:adsp1
    [ 124.874757] PM: Adding info for No Bus:pcmC1D0p
    [ 124.874777] PM: Adding info for No Bus:pcmC1D0c
    [ 124.874800] PM: Adding info for No Bus:dsp1
    [ 124.874820] PM: Adding info for No Bus:audio1
    [ 124.874846] PM: Adding info for No Bus:controlC1
    [ 124.874875] PM: Adding info for No Bus:mixer1
    [ 124.892854] ivtv0: Autodetected Hauppauge card (cx23416 based)
    [ 124.893243] ACPI: PCI Interrupt Link [APC1] enabled at IRQ 16
    [ 124.893247] ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [APC1] -> GSI 16 (level, low) -> IRQ 16
    [ 124.893256] ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    [ 124.919298] nvidia: disagrees about version of symbol struct_module
    [ 125.514430] PM: Adding info for No Bus:0000:01:08.0
    [ 125.581285] PM: Removing info for No Bus:0000:01:08.0
    [ 125.592592] ivtv0: loaded v4l-cx2341x-enc.fw firmware (-139637039960496 bytes)
    [ 125.814350] ivtv0: Encoder revision: 0×02060039
    [ 125.814371] PM: Adding info for No Bus:i2c-2
    [ 125.814843] PM: Adding info for i2c:2-0050
    [ 125.863002] tveeprom 2-0050: Hauppauge model 26132, rev F1B2, serial# 10258732
    [ 125.863005] tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    [ 125.863009] tveeprom 2-0050: TV standards NTSC(M) (eeprom 0×08)
    [ 125.863011] tveeprom 2-0050: audio processor is CX25841 (idx 35)
    [ 125.863014] tveeprom 2-0050: decoder processor is CX25841 (idx 28)
    [ 125.863016] tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
    [ 125.863019] ivtv0: Autodetected Hauppauge WinTV PVR-150
    [ 125.863021] ivtv0: reopen i2c bus for IR-blaster support
    [ 125.863030] PM: Removing info for i2c:2-0050
    [ 125.863040] PM: Removing info for No Bus:i2c-2
    [ 125.863063] PM: Adding info for No Bus:i2c-2
    [ 125.863453] PM: Adding info for i2c:2-0050
    [ 125.933426] tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    [ 125.933437] PM: Adding info for i2c:2-0061
    [ 126.108854] cx25840 2-0044: cx25841-24 found @ 0×88 (ivtv i2c driver #0)
    [ 126.108867] PM: Adding info for i2c:2-0044
    [ 126.122467] PM: Adding info for No Bus:2-0044
    [ 126.126518] PM: Removing info for No Bus:2-0044
    [ 129.007925] cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    [ 129.099783] wm8775 2-001b: chip found @ 0×36 (ivtv i2c driver #0)
    [ 129.106546] PM: Adding info for i2c:2-001b
    [ 129.136105] tuner 2-0061: type set to 50 (TCL 2002N)
    [ 129.441627] ivtv0: Registered device video0 for encoder MPEG (4 MB)
    [ 129.441778] ivtv0: Registered device video32 for encoder YUV (2 MB)
    [ 129.441940] ivtv0: Registered device vbi0 for encoder VBI (1 MB)
    [ 129.442007] ivtv0: Registered device video24 for encoder PCM audio (1 MB)
    [ 129.460301] ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    [ 129.460324] ivtv: ==================== END INIT IVTV ====================

  44. 294
    Lance Says:

    Well I solved my own problem. Turns our the IR part of the card was bad in some aspect. For whatever reason, it would work under WinXP on two different PCs, but not under Linux (Ubuntu) on either PC. Got a new PVR-150, put it in and it instantly worked.

    The new and old cards both had the same model and revision numbers as well.

  45. 295
    mark Says:

    long time, no update. Got married, that took some time ;)

    Damian: partly that (the driver cannot go into lirc because of the licensing issues), and partly that lirc is not in the kernel. The ivtv driver has not caused any issues, having it integrated into the kernel just makes it easier for distros to support the hardware, but doesn’t do anything for lirc. Shame, but there you go!
    phoner: it doesn’t learn, you must have a different card?
    Seth: looks like the wrong /dev/lircX?
    Lance: is it an MCE or something? If it can’t talk i2c it’s not going to work, I guess be sure you have the correct chip. Other than that, it could be timing. There are some timing hacks in the newer hauppauge windows drivers but I can’t figure out where the values come from.
    MEvans: I have updated the driver to current LIRC CVS, you can try this one. Apparently they have fixed the overwrite issue already. As patches go, you can get them with something like svn diff svn://svn.blushingpenguin.com/usr/local/svnroot/vendor/lirc/current svn://svn.blushingpenguin.com/usr/local/svnroot/trunk/lirc/ — however if you want a patch against the lirc distribution tarball you are a bit out of luck unless you want to generate your own — I gave up on that as they use a different version of the gnu autotools to me, and that makes larger patches than the tarball!

  46. 296
    Rusty Dog Says:

    Thanks for all of the hard work over the years. And for the update. A small typo that shouldin’t matter. During setup.sh the pvr-150 has moved from h to i

  47. 297
    mark Says:

    Thanks — now fixed.

  48. 298
    Rusty Dog Says:

    Okay, I actually have something to post about! I am sure that I am being a moron somewhere.
    Running gentoo, 2.6.22-gentoo-r5 ivtv-1.0.1
    I get a segfault when I do modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    The system did use to work with older versions so I am pretty sure the hardware is fine.
    Here is the syslog
    Aug 28 17:12:57 mythical lirc_pvr150: chip found with RX and TX
    Aug 28 17:12:57 mythical BUG: unable to handle kernel paging request at virtual address 801f831f
    Aug 28 17:12:57 mythical printing eip:
    Aug 28 17:12:57 mythical c034a5df
    Aug 28 17:12:57 mythical *pde = 00000000
    Aug 28 17:12:57 mythical Oops: 0000 [#1]
    Aug 28 17:12:57 mythical PREEMPT
    Aug 28 17:12:57 mythical Modules linked in: lirc_pvr150 lirc_dev snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq wm8775 cx25840 tuner ivtv cx2341x tveeprom i2c_viapro vt8623fb fb svgalib cfbcopyarea vgastate cfbimgblt cfbfillrect snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore
    Aug 28 17:12:57 mythical CPU: 0
    Aug 28 17:12:57 mythical EIP: 0060:[] Not tainted VLI
    Aug 28 17:12:57 mythical EFLAGS: 00010206 (2.6.22-gentoo-r5 #1)
    Aug 28 17:12:57 mythical EIP is at __i2c_check_addr+0×9/0×33
    Aug 28 17:12:57 mythical eax: 00008122 ebx: dd005852 ecx: 801f831f edx: 00000071
    Aug 28 17:12:57 mythical esi: dd005852 edi: fffffff0 ebp: dddba400 esp: d9be1d48
    Aug 28 17:12:57 mythical ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
    Aug 28 17:12:57 mythical Process modprobe (pid: 14350, ti=d9be0000 task=dcd97530 task.ti=d9be0000)
    Aug 28 17:12:57 mythical Stack: dddba474 c034a656 d9be1dd3 71fe2600 d9be1da8 00000000 00000246 00000001
    Aug 28 17:12:57 mythical dddba474 dddba474 dddba400 e2c0e416 dddba474 e2c0f22e dddba48f e2c0e60c
    Aug 28 17:12:57 mythical e2c0f1f6 e2c0f1dc d9be1da8 00000001 00000001 dd3becd8 00000000 00000000
    Aug 28 17:12:57 mythical Call Trace:
    Aug 28 17:12:57 mythical [] i2c_attach_client+0×24/0x15f
    Aug 28 17:12:57 mythical [] i2c_attach+0×12/0×42 [lirc_pvr150]
    Aug 28 17:12:57 mythical [] ir_attach+0x1c6/0×309 [lirc_pvr150]
    Aug 28 17:12:57 mythical [] ir_probe+0×109/0x12e [lirc_pvr150]
    Aug 28 17:12:57 mythical [] i2c_register_driver+0xad/0xce
    Aug 28 17:12:57 mythical [] init_module+0×46/0x4a [lirc_pvr150]
    Aug 28 17:12:57 mythical [] sys_init_module+0×89/0×133
    Aug 28 17:12:57 mythical [] syscall_call+0×7/0xb
    Aug 28 17:12:57 mythical =======================
    Aug 28 17:12:57 mythical Code: b8 b0 1c 4a c0 c7 85 bc 00 00 00 00 01 10 00 c7 41 04 00 02 20 00 83 c4 1c 5b 5e 5f 5d e9 d1 8d 07 00 53 8b 88 94 01 00 00 89 c3 01 0f 18 00 90 8d 83 94 01 00 00 39 c1 74 16 0f b7 81 76 fe
    Aug 28 17:12:57 mythical EIP: [] __i2c_check_addr+0×9/0×33 SS:ESP 0068:d9be1d48

    Any suggestion about what I am doing wrong?

    Thanks
    Rusty

  49. 299
    mark Says:

    I guess it’s probably the struct IR name length reduction — my names are one byte too long. I have fixed it up and uploaded a new tarball, can you try it and let me know if it helps? If not I will install 2.6.22 on my mythtv box and try to reproduce it.

  50. 300
    Damian Says:

    I see from https://help.ubuntu.com/community/Install_Lirc_Gutsy that they have support for blaster in Lirc. Is this using your patched lirc or what is the difference?

    PS. Congrats (I think!!) on get married!

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

Leave a Reply


5 * = thirty