LIRC PVR-150 IR blaster support, version 2

Final update
I have forward ported the code to the latest lirc release, fixed some bugs, and the i2c fixes have been merged into the ivtv-0.4.2. Please see this separate post, where I have removed all of the irrelevant history and only describe steps that are currently useful.

All new update
I’ve updated the ‘firmware’ file to include the new codesets recently released by hauppauge. This was a bit of a pain, as I had to disassemble my myth box to do it (bah, closed source). I hope they don’t do this too often in future! If anyone has got a spare PVR-150 or is willing to stick it in a windows machine and run wacky software then that would be nice the next time around 🙂 Alternatively you can bribe me I guess!

Update
Quick update: I have been working with the ivtv driver to see if I can resolve the root cause of the problem with the IR chip locking up and needing to be reset. I think that I have done so, but I can’t be sure until I get more testing feedback. I’ve updated the howto below to point at this post which contains the details of how to install the patch to ivtv. If you’ve followed all of the steps below and are still experiencing intermittent remote drop-out issues (as a couple of people have noted), you might want to try this out. I realise that this is quite a long and complicated procedure, so I’m working towards getting all fixes into the release versions of ivtv & lirc eventually. Obviously I’ll keep this updated as things progress. Slight update: up to about 28 hours now with no remote issues. Very encouraging. Further update: it works. Has been for months, and for others too. It’s in the 0.4.2 candidate release, so hopefully this issue should just die at some point. It also looks like hauppauge have put this in their mainline driver, which was updated some time in October. I’ve not disassembled it to check yet though 🙂

I’ve uploaded a slightly newer patch/package correcting two bugs. The first is not to reset the IR chip if you try and send an invalid code (by messing with lircd.conf!) since this clearly isn’t necessary. The second is a stack overrun bug spotted by Pascal Brisset, which could have had nasty consequences. I guess since I’ve not seen it the way I use lirc it’s only sending one code at a time to the driver. btw, this stuff is in my SVN repository, under trunk/3rdparty/lirc, if you want to do development on it.

The old stuff
OK, I’ve been playing with this off the back of the basic problem that seems to have been encountered by a lot of people, myself included — after a while the IR chip on the PVR-150 locks up, and hence the remote/blaster stop responding. (This happens with release versions of lirc/ivtv, so is definitely not related to what I’ve been doing with the IR blaster). This problem is pretty difficult to reproduce (i.e. I can’t do it on demand), but only seems to happen if you are using the encoder on the card at the time. I tried reproducing it with the Windows software, but I couldn’t manage it. I might not have tried hard enough; google search show that quite a few people have got this to fail, or it might be that hauppauge fixed the problem at some point. I don’t really know anything about this chip (it’s some software running on a fairly general purpose CPU, so it would be hard to without explicit information from hauppauge or some reverse engineering of that code, which is beyond me at this point in time), so I’m not sure why it happens. If anyone from hauppauge wants to step up and provide me with some information I’d be very happy!

There does exist a sort of solution for this: ivtvctl provides an ioctl that resets the IR chip on the card. Some people have this running every minute from a cron script, whilst that’s not a great solution it is a workable one. My issue with that is if you reset the IR chip, you have to send the boot block again to the IR blaster, so if I’d adopted the cron script I wouldn’t be able to change channel any more.

So after all that, I’ve adopted a delightful solution — detecting when the IR chip has locked up (i.e. stopped responding to i2c traffic), and resetting it in the driver. It’s messy, but it works, and as I do it in the driver, I can transparently retry IR blaster sends, which saves me from recording the wrong channel. Anyway, that was a bit long, so here’s a changelog:

– Split the code out into a new lirc driver, lirc_pvr150.
– TX and RX portions are treated as a single device. This makes good sense as you then only have one lirc socket that supports both receiving and sending (if the TX hardware is actually found).
– The RX device is ‘polled’ in the same way that the windows driver appears to. This is a good place to detect whether it has died or not.
– IR device is reset on failure and operations are retried (needs ivtv patch)
– A local copy of the ‘firmware’ data is made and release_firmware() is called. This prevents a hotplug timeout that I used to see (the script expects that firmware is released when loading is finished).
– Merge with lirc-0.72 release (rather than pre2)
– Module is reference counted properly
– Module has parameters disable_rx and disable_tx. You can use, e.g. modprobe lirc_pvr150 disable_tx=1 if you are not interested in setting up the IR blaster device.

Here’s the updated HOWTO for this version:

1. Get the pre-patched lirc 0.7.2 (or just the patch should you prefer).
2. Unpack the patched lirc (or apply the patch)


cd /usr/src
tar xfj lirc-0.7.2pvr150.tar.bz2
cd lirc-0.7.2pvr150
./configure

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

then:

make && make install.

3. Note that this step is no longer necessary with ivtv >= 0.4.0 (the current stable release series), which is recommended — the export symbol patch was included. Skip right on to step 5 if you’ve grabbed the latest stable release, or go to 3a if you are having ‘remote stops responding’ issues (doesn’t seem to affect everyone).
3a As an alternative to the below, see this post. Don’t do both. I’ll update this if that patch proves to solve problems for people. I am hoping it might, it’s working very well for me so far.
3b Patch your ivtv driver and rebuild it. This step is necessary to be able to reset the IR chip. Download the patch here. Note that this patch does not apply to some versions of ivtv. I’m currently using 0.3.7a, so it should apply cleanly to that. If you want to use a later driver, the change is actually pretty trivial, we just need to export an extra symbol. In drivers/ivtv-driver.c, you need to add:

#include “ivtv-gpio.h”

near the top of the file after the rest of the #include lines, and

EXPORT_SYMBOL(ivtv_reset_ir_gpio);

right at the bottom of the file where all the other EXPORT_SYMBOL lines are. All this does is export that symbol for use by other modules, it does not change the functionality of the driver in any way. If you have trouble with this then drop me a line and I will create a patch for the version of ivtv you want to use.


cd /patch-to-ivtv-driver (e.g. cd /usr/src/ivtv-0.3.7a)
cd driver
patch < ivtv-driver.c.patch cd .. make && make install

4. Unload & reload the new ivtv driver. If lucky, rmmod ivtv && modprobe ivtv, otherwise either
kill everything that might be using the driver/unload all dependent modules or just reboot if you can’t be bothered with that.

5. 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 200K) so this makes the driver quite large.
(I have no plans to sort this out, memory is cheap).

6. 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 20927 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 575 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.

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

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

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

10. 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 (575 at present).

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 and took me a couple of goes to get right. Some people have reported needing
to have the device attached back to front.

If you can’t get this to work:

a) My software doesn’t work properly
b) The device you are trying to control is not supported (please check against the Windows stuff if possible)
c) You didn’t get the device in the right place — did I mention it was touchy?

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

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

That’s it, good luck!

This entry was posted in Random. Bookmark the permalink.

226 Responses to LIRC PVR-150 IR blaster support, version 2

  1. Paul Sutherby says:

    Mark – thanks, tried that and got further – on ./configure I now get the install menu – selected the PVR card and hit save and run configuration, a load of dependencies were checked but it had a configure error – c++ preprocessor “/lib/cpp” fails sanity check.

    Any ideas?

  2. mark says:

    Can you post or email me the output of confiig.log? I’d guess something like you haven’t got gcc installed, but I can’t really say without more information (gcc -v to test).

  3. Paul Sutherby says:

    Thanks again Mark:

    I think I do have gcc installed – gvv -v gives:

    Using built-in specs.
    Target: i386-redhat-linux
    Configured with: ../configure –prefix=/usr –mandir=/usr/share/man –infodir=/usr/share/info –enable-shared –enable-threads=posix –enable-checking=release –with-system-zlib –enable-__cxa_atexit –disable-libunwind-exceptions –enable-libgcj-multifile –enable-languages=c,c++,objc,java,f95,ada –enable-java-awt=gtk –with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre –host=i386-redhat-linux
    Thread model: posix
    gcc version 4.0.1 20050727 (Red Hat 4.0.1-5)

    Here is my config.log output:

    cpp: installation problem, cannot exec ‘cc1plus’: No such file or directory

  4. mark says:

    Chopped the relevant bit out of config.log. You are missing some of the gcc toolchain. Try installing gcc-c++, or probably better is to use redhat-config-packages or whatever the FC4 general package selection tool is. If you can find the GUI package selection tool you should pick the development tools group that includes gcc, this should install all the needed dependencies.

  5. Paul Sutherby says:

    Thanks Mark – that got it working – have completed the make and make install steps.

    Going to call it a day at that for today, but will see if I can get the rest to complete tomorrow night – will let you know how I get on!

    Thanks again

    Paul

  6. Paul Sutherby says:

    hmm – couldnt resist a late look at it – and got another error…

    when running modprobe lirc_dev && modprobe lirc_pvr150 debug=1
    no error comes out in the shell, but syslog reads… any ideas?

    Oct 31 23:35:09 localhost nmbd[2446]:
    Oct 31 23:35:09 localhost nmbd[2446]: *****
    Oct 31 23:35:09 localhost kernel: Device not ready. Make sure there is a disc in the drive.
    Oct 31 23:35:40 localhost last message repeated 70 times

  7. mark says:

    Try looking in /var/log/[dmesg, messages, etc]. I guess redhat isn’t putting klog output in syslog.

  8. Ted in Atlanta says:

    Monday Oct 31
    Hi guys
    My Fedora FC4/Mark/PVR150 is working well… recorded a 1 hour show with no mishaps. My remote is working fine in MYTHTV and wondering if it is possible to get more than 1 action to happen per a single key press. For instance. I would like to display the EPG with 1 (one) key press. At the moment I press GUIDE which brings up the guide menu…. I would like this one button to also press the OK button (enter) to display the guide. I would use a different button to bring up the guife menu for further action.

    Cheers

  9. mark says:

    For this case, simply map the appropriate button press in your .lircrc to S (probably set to I at present). For all of the possible mythtv key bindings, look in the keybindings table in the mythconverg database. You can also change the keylist column in this table to whatever key you want to map the remote button to.

    I don’t think it is possible to get multiple button presses, but there are quite a lot of actions and it is likely that they cover most of the cases you want.

  10. Paul Sutherby says:

    Mark – it is working! Thanks ever so much for your help.

    If I run the following 3 lines, then I can receive my hauppage remote codes in irw, and if I run the send_power_new script then I can see the blaster happily flashing away

    modprobe lirc_dev
    modprobe lirc_pvr150 debug=1
    lircd –device=/dev/lirc0

    Over the coming weekend I will move my box back to my pc and have another bash at getting the correct codes in the lircd.conf to see if that gets it working – should be on the home straight now!

    Thanks Mark

    Paul

  11. Brian says:

    Hi,

    I have everything installed and my IR blaster is blinking. However, my Expressvu receiver is not responding to any of the code. I have tried move the LED as close to the IR receiver in my set-top box as possible.

    I have attached the output from my kernel log and would appreciate any pointer you can give.

    Thanks,
    Brian

    Nov 1 21:20:52 vernon lirc_dev: IR Remote Control driver registered, at major 61
    Nov 1 21:20:53 vernon lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    Nov 1 21:20:53 vernon lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    Nov 1 21:20:53 vernon lirc_pvr150: chip found with RX and TX
    Nov 1 21:20:53 vernon ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    Nov 1 21:20:53 vernon ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    Nov 1 21:20:53 vernon lirc_dev: lirc_register_plugin: sample_rate: 0
    Nov 1 21:20:53 vernon lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    Nov 1 21:20:53 vernon lirc_pvr150: poll thread started
    Nov 1 21:20:56 vernon lirc_pvr150: firmware of size 209327 loaded
    Nov 1 21:20:56 vernon lirc_pvr150: 575 codesets loaded
    Nov 1 21:20:56 vernon lirc_pvr150: 01 60 00 01 bflirc_pvr150: 05 02 00 22 1alirc_pvr150: 09 fe 06 0e 43lirc_pvr150: 0d 98 2e 56 53lirc_pvr150: 11 6e 99 94 5dlirc_pvr150: 15 46 70 30 6alirc_pvr150: 19 be 6e a3 56lirc_pvr150: 1d ab 4d 0d 67lirc_pvr150: 21 a6 72 0d 0flirc_pvr150: 25 ee 68 fa 47lirc_pvr150: 29 fa 36 01 0flirc_pvr150: 2d 8b 7b fb 6clirc_pvr150: 31 b2 74 ef 05lirc_pvr150: 35 bd 63 af 35lirc_pvr150: 39 fb 5d 22 2alirc_pvr150: 3d 38 58 49 31lirc_pvr150: 41 50 6b fd 5flirc_pvr150: 45 5e 02 f0 1flirc_pvr150: 49 48 67 84 66lirc_pvr150: 4d b5 08 66 23lirc_pvr150: 51 b3 6c 1e 2dlirc_pvr150: 55 99 1d e8 62lirc_pvr150: 59 e6 0a 45 39lirc_pvr150: 5d 67 6c 9f 76lirc_pvr150: 61 00 00 00 76lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): open called
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x80046900)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x40046911)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x40046912)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): write called
    Nov 1 21:22:49 vernon lirc_pvr150: 01 60 a3 ee ablirc_pvr150: 05 4d 0d 67 a6lirc_pvr150: 09 72 0d 0f eelirc_pvr150: 0d 68 fa 47 falirc_pvr150: 11 36 0b dc 8elirc_pvr150: 15 75 f9 8e b2lirc_pvr150: 19 74 ef 05 bdlirc_pvr150: 1d 63 af 35 fblirc_pvr150: 21 5d a0 2a 49lirc_pvr150: 25 29 38 40 22lirc_pvr150: 29 1a 8c 2e 2flirc_pvr150: 2d 73 81 6e 39lirc_pvr150: 31 16 f5 17 75lirc_pvr150: 35 8b 99 dc 4clirc_pvr150: 39 93 e1 d2 66lirc_pvr150: 3d e2 17 9d 19lirc_pvr150: 41 f5 5c a9 54lirc_pvr150: 45 b2 f2 98 59lirc_pvr150: 49 8d f2 f0 11lirc_pvr150: 4d 97 05 b8 05lirc_pvr150: 51 c9 fe f0 74lirc_pvr150: 55 84 04 93 4dlirc_pvr150: 59 8b 10 fa 42lirc_pvr150: 5d 9c 50 64 b3lirc_pvr150: 61 00 00 00 b3lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
    Nov 1 21:22:49 vernon lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
    Nov 1 21:22:49 vernon lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
    Nov 1 21:22:49 vernon lirc_pvr150: sent code 32811, key 10
    Nov 1 21:22:49 vernon lirc_pvr150: key (0x00/0x00)
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll called
    Nov 1 21:22:49 vernon lirc_pvr150: poll result = 0
    Nov 1 21:22:49 vernon lirc_dev (lirc_pvr150[0]): close called
    Nov 1 21:22:49 vernon lirc_pvr150: key (0x00/0x00)

  12. Paul Sutherby says:

    Mark – 1 last problem – got this working, and the IR Blaster flashing away when running the send_power_new script, but the box does not seem to turn off.

    I also tried the command irrecord to create a lirc.conf file but after being asked to press enter and then hold a key on the remote control, it then said that no gap was found and nothing was recorded – it seems that lirc does not work with my stb remote control – any ideas what I might be doing wrong?

    thanks again

    Paul

  13. Paul Sutherby says:

    Hmm – strange – irrecord works for a different remote control, but not the one for my stb – does this mean that I can not use lirc to control my stb??

  14. mark says:

    If it doesn’t turn it off, there’s nothing I can do. The driver is limited to replaying the same data to the chip that the windows software provides. irrecord will not work. If possible, you might want to check if the hauppauge windows software is capable of turning the box off. If not, then it definitely won’t work. If it does, please tell me what settings turn the box off in Windows and I can update the captures.

  15. mark says:

    Brian: the answer to your question is unfortunately the same as above! If it works in Windows, I’ve missed something, and it’s reasonably trivial to get the extra data. If not, then there’s not much that I can do about it unfortunately.

  16. Paul Sutherby says:

    ok, thanks for letting me know Mark – will see if I can get this on a windows install and try it out.

    Is this specific to the hauppage blaster then – would a different lirc blaster (like the serial ones you can get) be able to work with a wider range of stbs?

    thanks again

    Paul

  17. Brian says:

    Thanks for the replay Mark. After some further investigation it was working (the Expressvu 4100 is code 1_28), I just have the orientation of the IR Blaster wrong. It appears that the ir comes from the top (opposite the cable), but I though it was coming out the front. Thanks for your great work on this project.

    Brian

  18. Kris says:

    Well I can’t even get the darn driver to compile… here’s where I start seeing problems when I do a make:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `poll’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:997: warning: ISO C90 forbids mixed declarations and code
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `ioctl’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1020: warning: ISO C90 forbids mixed declarations and code
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c: In function `ir_probe’:
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: `I2C_ALGO_BIT’ undeclared (first use in this function)
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: (Each undeclared identifier is reported only once
    /root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.c:1366: error: for each function it appears in.)
    make[5]: *** [/root/lirc-0.7.2pvr150/drivers/lirc_pvr150/lirc_pvr150.o] Error 1
    make[4]: *** [_module_/root/lirc-0.7.2pvr150/drivers/lirc_pvr150] Error 2

    Previous to me finding this site on making the TX work for the card, I had to patch the plain ole lirc-0.7.2 source to get it to compile, however this patch doesn’t work with your already patched source. I believe that this has to do with me running a 2.6.14 kernel. I don’t know if I should post the patch I found or what. Any ideas?

  19. mark says:

    Yes, it’s your kernel. Try this patch — apply to drivers/kcompat.h.

  20. bob says:

    Went back to 0.3.8 as 0.4.0 was causing problems. Got this in /var/log/messages:

    Nov 3 23:23:59 tuse lirc_dev: IR Remote Control driver registered, at major 61
    Nov 3 23:23:59 tuse lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Nov 3 23:23:59 tuse lirc_pvr150: ivtv i2c driver #0: no devices found
    and …..
    Nov 3 23:20:17 tuse lircd-0.7.2[7796]: lircd(hauppauge_pvr150) ready
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: accepted new client on /dev/lircd
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: could not open /dev/lirc0
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: default_init(): No such device
    Nov 3 23:20:20 tuse lircd-0.7.2[7796]: caught signal

    i2cdetect gave:
    i2c-1 unknown SMBus Via Pro adapter at 5000 Algorithm unavailable
    i2c-0 unknown ivtv i2c driver #0 Algorithm unavailable

    The i2c.patch did not apply cleanly to 0.4.0 as two hunks failed. Any others with the same problem? Running Linux 2.6.12-gentoo-r9.

    Have others got 0.4.0 to work?

  21. Kris says:

    YEA! Thanks Mark, that patch fixed the make problem for the 2.6.14 kernel. 🙂

  22. Ryan says:

    Hi Mark,

    I’ve run into a problem that I haven’t seen mentioned here yet.

    I am running Gentoo AMD64, and I modified the current ebuilds for ivtv-0.4.0 with your patches, and your pre-patched version of lirc-0.7.2. Going through all of these replies, I got almost all of the problems ironed out, but now I’ve hit a road block.

    The lirc_pvr150 module appears to load fine, and the firmware appears to be loaded properly. However, an error gets logged when I start lircd. I am using the lircd.conf file you provided at http://www.blushingpenguin.com/mark/lmilk/lircd.conf. It doesn’t seem to like some of the codes.

    Here is the part of my syslog that shows the lirc_pvr150 driver loading successfully:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 209327 loaded
    lirc_pvr150: 575 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    …and here is what appears in my syslog when I start lircd:

    lircd-0.7.2pvr150[5952]: caught signal
    lircd-0.7.2pvr150[7034]: error in configfile line 58:
    lircd-0.7.2pvr150[7034]: “2147483648”: must be a valid (lirc_t) number
    lircd-0.7.2pvr150[7034]: reading of config file failed
    lircd-0.7.2pvr150[7035]: lircd(hauppauge_pvr150) ready

    At this point, irw doesn’t show anything, and irsend LIST “” “” “” doesn’t list any remotes.

    If I use another lircd.conf file with the grayHauppauge remote in it, I don’t get any errors and I am able to see codes from the Hauppauge remote with irw. I still can’t send commands with irsend though.

    Any ideas?

  23. Tyler Bartel says:

    Mark

    I thought i would bring this off the lirc list as it seems to be getting more and more specific to my troubles. I have updated my ivtv to 0.4.0 installed your patched lirc and continued with instructions and hit another stumbling block when I modprobe lirc_pvr_150 debug=1 the output of my dmesg is as follows:

    ivtv0: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    lirc_dev: IR Remote Control driver registered, at major 61
    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 haup-ir-blaster.bin not available (-2)
    lirc_pvr150: poll thread ended
    lirc_dev: plugin lirc_pvr150 unregistered from minor number = 0
    lirc_dev (lirc_pvr150[0]): cleaning up

    seems to me the module cant find the haup-ir-blaster.bin firmware file which i downloaded and verified was in /lib/modules (I’m tunning FC4)

    something else of note is that I was unable to run lircd as it was not put to my /usr/local/bin directory during the install which I thought strange. as apps like irw and irrecord were there (though they may have been there from a previous lirc install) so I copied lircd manually from the source directory.

    Thanks again for your time

    TYler

  24. Tyler Bartel says:

    I have found the answer within the comments here. turns out I had to copy the haup-ir-blaster.bin file to /lib/firmware that is now the only file in there so thats probably what threw me for a loop so that seems to be the answer for FC4.

    I added the following to /etc/rc.d/rc.local:

    /sbin/modprobe lirc_dev
    /sbin/modprobe lirc_pvr150
    /sbin/lircd –device=/dev/lirc0 –output=/dev/lircd
    /usr/local/bin/irexec

    (the output is bucause of a problem i had with irexec not liking the default device, it seems it’s default socket is /dev/lirc0 on my machine anyway)

    My output of dmesg is now as follows:

    lirc_dev: IR Remote Control driver registered, at major 61
    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 209327 loaded
    lirc_pvr150: 575 codesets loaded
    lirc_pvr150: 01 60 00 01 bflirc_pvr150: 05 02 00 22 1alirc_pvr150: 09 fe 06 0e 43lirc_pvr150: 0d 98 2e 56 53lirc_pvr150: 11 6e 99 94 5dlirc_pvr150: 15 46 70 30 6alirc_pvr150: 19 be 6e a3 56lirc_pvr150: 1d ab 4d 0d 67lirc_pvr150: 21 a6 72 0d 0flirc_pvr150: 25 ee 68 fa 47lirc_pvr150: 29 fa 36 01 0flirc_pvr150: 2d 8b 7b fb 6clirc_pvr150: 31 b2 74 ef 05lirc_pvr150: 35 bd 63 af 35lirc_pvr150: 39 fb 5d 22 2alirc_pvr150: 3d 38 58 49 31lirc_pvr150: 41 50 6b fd 5flirc_pvr150: 45 5e 02 f0 1flirc_pvr150: 49 48 67 84 66lirc_pvr150: 4d b5 08 66 23lirc_pvr150: 51 b3 6c 1e 2dlirc_pvr150: 55 99 1d e8 62lirc_pvr150: 59 e6 0a 45 39lirc_pvr150: 5d 67 6c 9f 76lirc_pvr150: 61 00 00 00 76lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    I still have to get the sending tested but I wated to report my success before anyone has to start helping me troubleshoot

    Happy Lirc-ing (fingers crossed)

    Tyler

  25. Tyler Bartel says:

    Mark

    Sorry to continue being such a bother but I now have the irblaster working, I can tell because when i run your send_power_new script I can see the light blinks. Unfortunately after several tries, it seems that my reciever must not be supported by the driver. It is a STB that was created specifically by ASE for the Cable Company I subscribe to and is not one that I have ever seen with any other company (I actually work for that cable company).

    I have gone as far as creating a lircd.conf file from the findings of irrecord (irw understands the output of the remote) but it will not cause the light to blink on the blaster. The output of the ASE remote for the numbers actually uses the same codes as the grey hauppauge remote does strangely enough.

    My question is if there is any way I can help get this codeset supported by the driver?

    Thanks

    Tyler

  26. mark says:

    bob: Can you send me the output from the ivtv module when you load it? What problems was 0.4.0 causing? The stable release ought to be fine.

    Ryan: it’s a bug in lirc to do with 64-bit support. Try asking the lirc list for help. Somebody had a fix for this and I asked them for it so I could forward it to you, but so far they haven’t responded. It’s just something trivial to do with the lirc file parser.

    Tyler: You might like to find out what remote standard they are using (since you work there!). Also check that the transmitter really is correctly placed over the receiver (usually holding a torch up to the plastic allows you to find it, also note that if you have an LED on the STB that lights up when you press a button on the remote, that is _not_ the receiver and they are often in different locations). Other than that, try it in Windows and if it doesn’t work there you’d have to bug Hauppauge about it. I don’t have any way of generating extra codes unfortunately.

  27. Ryan says:

    Hi Mark,

    Thanks for pointing me in the right direction. Not being much of a programmer, I just went into the code and removed the if-then block that validates lirc_t numbers. After recompiling, I don’t receive the error message any more, and my IR blaster blinks when I run the send_power_new script!

    I know, that’s hardly a fix, but it got me going. Hopefully I’ll be able to get that fix someone else came up with, or see the fix in a new version.

    I haven’t had a chance to check if those codes actually work with my satellite receiver, and don’t have time at the moment…but soon enough, I will. 🙂

    Thanks for your excellent work!

  28. Bob says:

    I’ve recently upgraded my system to use udev and my blaster seems to have stopped working. Everything loads and looks like it is working, but I cannot see the ir blaster blinking anymore and isn’t sending a signal. I tried to reinstall the lircd package from your site, but it would not install. It had an error:

    Making install in drivers
    make[1]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers’
    Making install in lirc_dev
    make[2]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[3]: Entering directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    test -c /dev/lirc || (/tmp/lirc-0.7.2pvr150/install-sh -d /dev && /usr/bin/mknod /dev/lirc c 61 0)
    /usr/bin/mknod: `/dev/lirc’: File exists
    make[3]: *** [mkdev] Error 1
    make[3]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[2]: *** [install-am] Error 2
    make[2]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers/lirc_dev’
    make[1]: *** [install-recursive] Error 1
    make[1]: Leaving directory `/tmp/lirc-0.7.2pvr150/drivers’
    make: *** [install-recursive] Error 1

    I have manually copied the drivers over to the kernel directory and modprobed them. My dmesg after loading the modules:

    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 209327 loaded
    lirc_pvr150: 575 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0

    I have configured my lircd to use the device that my udev rules create (/dev/lircd/0) and I can recieve commands just fine from the remote. If you have any ideas, please let me know.

    Cheers,

    Bob

  29. mark says:

    How are you running lircd? And how are you trying to send?

  30. bob says:

    Mark,
    Thanks for your response. I seem to have solved my problem but a new issue has creeped up. I change tv provided and the cable unit that i have received is a Scientific Atlanta Explorer 2000. The send_power_new script does not seem capable of controlling this STB. Any suggestions?

  31. Bob says:

    Mark,

    I hope you were responding to me. I’ve been running lircd from my startup script, and I’ve started it by hand. I’ve been using a change_channel script that I found for mythtv, but for all my testing I use “irsend SEND_ONCE blaster power” and have not seen any response.

    Cheers,

    The other Bob

  32. mark says:

    Hmm, ok. I’m somewhat confused here.

    To Bob with the Scientific Atlanta Explorer 2000: Firstly make sure that the IR transmitter is very close to the receiver — it only has a range of a few cm. This is generally _not_ where the LED that lights up when you press the button on the remote is located. I usually find that a torch is helpful in locating the receiver under the coloured plastic covers that are common. If that doesn’t help, then try it under windows if possible. If it doesn’t work under windows then then there’s nothing I can do with it (see other questions and responses). If it works under windows but not with lirc_pvr150 then it should be simple to fix.

    To the second bob: try wiggling the cable and make sure it is seated properly, looks like the driver is loaded ok. If that doesn’t help load lirc_pvr150 with modprobe lirc_pvr150 debug=1 and send me the output after an irsend or two.

    Thanks,

    Mark

  33. Ryan says:

    Hi Mark,

    I have success! Once I had that AMD64 file parsing bug out of the way, everything else fell into place.

    A important note about the IR blaster… It appears to only have one LED inside it, and it is a plain red one — not an IR one. That would explain why the range is so short. I believe IR receivers are capable of picking up wavelengths creeping up into the red spectrum.

    The flat backside of my blaster had a white layer on it. Peel it off, and beneath it is one side of clear 2-sided sticky tape. With this you stick it right onto the IR window of your STB. If anyone is wondering what those two IR blaster-shaped white scraps are that came in the same bag — those are spare sticky tapes. 🙂

    Cheers!

  34. bob (first bob) says:

    Mark,

    Thanks for the reply. That was it exactly. I hadn’t realized how weak the IR Blaster was. Someone in another forum suggested a certain code for the SA 2000 and I literally taped the IR blaster to the window on the STB and it worked.

    Another thing I noticed is the remote for the PVR 150 is not that responsive, just wondering if others noticed this. I will try to lower the repeat in the .lircrc file. Any other suggestions?

    Thanks for all the good work.

  35. mark says:

    Great! I’m glad that sorted you out. The remote isn’t very responsive, but this is the same situation as with the old lirc_i2c driver and is the same on . all the PVR-X50 cards I haven’t got around to addressing it yet but it is on my TODO list. I’ll let you know when I get somewhere with it.

  36. ktraglin says:

    after compiling and loading the modules, this is all I got on Ubuntu 5.10

    Nov 14 11:20:48 mediaserv kernel: [4297203.757000] lirc_dev: IR Remote Control driver registered, at major 61
    Nov 14 11:20:48 mediaserv kernel: [4297203.767000] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
    Nov 14 11:20:48 mediaserv kernel: [4297203.821000] lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    Nov 14 11:20:48 mediaserv kernel: [4297203.823000] lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    Nov 14 11:20:48 mediaserv kernel: [4297203.823000] lirc_pvr150: ivtv i2c driver #0: no devices found

  37. mark says:

    It can’t find the IR chip. First off I’d try:

    – Making sure that lirc_i2c isn’t present/doesn’t get loaded (this driver would cause a conflict)
    – Testing again from a cold boot. To do this, turn off the PC, remove the power cord, press the on button a few times with the power cord removed, wait 30s and then plug it back in again (it’s really necessary for a proper reset as the PVR-150 stays powered from the motherboard trickle power)

    If that doesn’t help, can you confirm that you have a PVR-150 with an IR blaster and that it has a Zilog Z8F0811 CPU on it if possible? To do the latter, you need to look at the card, the chip should be near the bottom left of the device.

    Also, can you send me the output of running i2cdetect? You need to modprobe i2c-dev, then run i2c-detect to find the ivtv bus. When you’ve found it run i2c-detect -a [bus number] and post or email me the output.

    Thanks,

    Mark

  38. Chris Wray says:

    Hi Mark,

    Firstly, thanks for the excellent guide. Im almost there now…
    Ive got the driver installed and it seems to be running fine, I can transmit certain codes and receive from the hauppauge remote.
    Howeve, I have a echostar (bell expressvu 3100) set top box and I cant pick up or receive the signals for that remote.
    If I select TV on the remote and go into mode 2 it will pick up the signals fine but ‘Sat’ doesnt receive anythinig. The remote definitely works.

    I used this as the lircd.conf to test irsend and it works fine (just not with my box)

    begin remote
    name blaster
    bits 32
    flags RAW_CODES
    eps 0
    aeps 0
    plead 0
    gap 333333
    repeat_bit 0

    begin raw_codes
    name 0
    2149253120
    name 1
    2149253121
    name 2
    2149253122
    name 3
    2149253123
    name 4
    2149253124
    name 5
    2149253125
    name 6
    2149253126
    name 7
    2149253127
    name 8
    2149253128
    name 9
    2149253129
    name POWER
    2149253130
    name CH_UP
    2149253135
    name CH_DOWN
    2149253136
    name CH_PREVIOUS
    2149253139
    name GUIDE
    2149253147
    name AV
    2149253161
    name ENTER
    2149253163
    end raw_codes

    end remote

    However, the echostar codes look different,

    begin remote

    name 3100
    bits 16
    flags SPACE_ENC
    eps 30
    aeps 100

    header 400 6100
    one 400 1700
    zero 400 2800
    ptrail 400
    gap 6200
    min_repeat 4
    toggle_bit 0

    frequency 56000

    begin codes
    power 0x0000000000000800
    0 0x0000000000004400
    1 0x0000000000001000
    2 0x0000000000001400
    3 0x0000000000001800
    4 0x0000000000002000
    5 0x0000000000002400
    6 0x0000000000002800
    7 0x0000000000003000
    8 0x0000000000003400
    9 0x0000000000003800
    up 0x0000000000006800
    cancel 0x0000000000004800
    end codes

    end remote

    When I do ‘irsend SEND_ONCE 3100 1’ I get:
    irsend: command failed: SEND_ONCE 3100 1
    irsend: transmission failed

    and the system log says :
    Nov 29 10:54:32 mythtv kernel: lirc_pvr150: failed to get data for code 0, key 400 — check lircd.conf entries

    I am really stuck as to what is going on and am wondering if its a firmware issue. The hauppauge website mentions that the new drivers for the IR blaster support my set-top-box but how do I go about generating the firmware file from them.

    Any advice you can give me will be a great help.

    Also, I just recompiled my kernel with the HZ defined as 1024 to try to get mode2 or irrecord to pick up the echostar remote, how can I verify that this is now in effect

    Kindest Regards

    Chris Wray

  39. mark says:

    You are misunderstanding how it works — the driver is only capable of sending the codes listed in the giant configuration file linked to above. Other lirc configuration files won’t work You have to run the send_power_new script having carefully positioned the blaster over the receiver on your STB and wait until it turns off — see step #10 above for more details. You might want to add a -x to /bin/bash at the top of the script so that you can see what it is doing (alternatively load the module with debug=1 and check the log output).

  40. Chris Wray says:

    Thanks for the quick reply Mark. Ill try this tonight.
    Just for the sake of my sanity, does this mean that mode2 will never be able to pick up the signals from my satellite remote?

  41. mark says:

    Correct — see the mode2 man page:

    “Of course this program won’t work with hardware that decodes the signals itself like e.g. TV cards or the Irman.”

  42. Frank says:

    has anyone had any luck getting the pvr150 remote (with or without ir blaster) working in gentoo linux.

    nexus@localhost ~ $ uname -a
    Linux localhost 2.6.14-gentoo-r3 #2 SMP Tue Nov 29 00:04:31 CST 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux

    i’ve tried using your patched lirc with the kcompat.h.patch but no sucess

    see dmesg out put below i’m getting the same output as

    ktraglin said,
    November 14, 2005 at 5:24 pm

    and i tried i2c-detect but it’s not present yes i did modprobe i2c-dev
    first

    any help would be great
    thanks

    localhost nexus # dmesg | grep ivtv ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.4.0 (tagged release) loading
    ivtv: Linux version: 2.6.14-gentoo-r3 SMP gcc-3.4
    ivtv: In case of problems please include the debug info
    ivtv: between the START INIT IVTV and END INIT IVTV lines when
    ivtv: mailing the ivtv-devel mailinglist.
    ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
    ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
    tveeprom: ivtv version
    ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
    ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
    ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    ivtv0: loading /lib/modules/ivtv-fw-enc.bin
    ivtv0: Encoder revision: 0x02050032
    ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    tuner: type set to 50 (TCL 2002N) by ivtv i2c driver #0
    ivtv0: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    lirc_pvr150: ivtv i2c driver #0: no devices found

  43. Chris Wray says:

    Just a follow up Mark. I finally got my blaster working, thanks for the help.
    I do have a suggestion though, perhaps the send_power_new script could echo the current code to stout so its a bit easier to determine which code powers the box off.

  44. Jim says:

    Mark,

    Thanks for the great work! After following your explicit instructions, the remote seemed to work fine. However, with the fix applied I started getting random video glitches during mythtv. This seemed related to the card and/or IR chip somehow as it would only clear after a cold boot (much like the original IR symptoms). Has anybody else encountered this?

    Thanks again,
    Jim

  45. Jim says:

    Thanks for the great patches and help! After getting everything related to the remote to work w/o locking up, I seem to get random video glitches in mythtv with all the patches applied. I banged my head over the configs for a while and finally, after restoring unpatched driver code, could get normal video only after a cold boot of the machine (of course, resetting all the state info on the pvr card). Anybody else have this problem?

    -Jim

  46. Jim says:

    Ugh, sorry, didn’t mean to duplicate remarks there. Please remove duplicates as you wish.

  47. mark says:

    Frank — that’s a bit weird. You could try a proper cold reboot, that seems to help in some cases. Otherwise, you might want to try the i2c patch and see if that helps. I don’t really know what else to suggest: if the driver can’t find the chip on the card then there’s not much it can do. I guess the standard lirc_i2c doesn’t find it either?

    Chris: it’s a fair point, I’ll update the script when I get chance. I think I used the debug log output to see what it was doing, but it’s a one off process so I haven’t thought about it since!

    Jim: I’ve not seen this. If you don’t load lirc_pvr150 or lircd, does it still happen? It seems pretty odd as i2c is only used during setup and polling the device. I’d like to know it’s definitely related to polling the device (if it happens without the module loaded, then I would guess that something else is going on).

    p.s. sorry for the slow responses, work gets in the way sometimes!

    Thanks,

    Mark

  48. Fergal Daly says:

    Hi Mark,

    I downloaded your patch but had some trouble applying it to the FC4 source rpm. The versions of automake/autoconf that you ran are much newer than the ones that are used for lirc and they caused lots of diffs in the autogenerated files. So I stripped all of the autogenerated files from the original patch, applied that and ran autoconf-2.13 and automake-1.5 and the result is ~90k instead of 2M. It still doesn’t compile for the latest FC4 kernel (as you point out above) and gcc is a bit picky about mixing code with variable declarations, this second patch handles that.

    For anyone running FC4 they can get a condensed version of what’s necessary here. I hope this helps any fellow FC4 sufferers!

    Any idea when this is going into the mainline version or lirc?

    Fergal

  49. Chad Davis says:

    I too can not get it to find the remote…Here is my dmesg after:

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

    [17183023.452000] ivtv: ==================== START INIT IVTV ====================
    [17183023.452000] ivtv: version 0.5.1 (tagged release) loading
    [17183023.452000] ivtv: Linux version: 2.6.15-8-386 preempt 486 gcc-4.0
    [17183023.452000] ivtv: In case of problems please include the debug info between
    [17183023.452000] ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    [17183023.452000] ivtv: any module options, when mailing the ivtv-users mailinglist.
    [17183023.452000] ivtv0: Autodetected WinTV PVR 150 card (cx23416 based)
    [17183023.452000] ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 209
    [17183023.452000] ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
    [17183023.460000] tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    [17183023.460000] ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    [17183023.484000] cx25840 1-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
    [17183024.760000] cx25840 1-0044: loaded v4l-cx25840.fw firmware (14264 bytes)
    [17183024.844000] ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
    [17183024.844000] wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
    [17183024.856000] ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
    [17183024.928000] tveeprom 1-0050: Hauppauge model 26582, rev C299, serial# 8442800
    [17183024.928000] tveeprom 1-0050: tuner model is TCL 2002N 5H (idx 99, type 50)
    [17183024.928000] tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
    [17183024.928000] tveeprom 1-0050: audio processor is CX25843 (idx 37)
    [17183024.932000] tveeprom 1-0050: decoder processor is CX25843 (idx 30)
    [17183024.932000] tveeprom 1-0050: has no radio, has no IR remote
    [17183025.604000] ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    [17183025.812000] ivtv0: Encoder revision: 0x02040011
    [17183025.812000] ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    [17183025.812000] ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    [17183025.812000] tuner 1-0061: type set to 50 (TCL 2002N)
    [17183026.044000] ivtv0: Initialized WinTV PVR 150, card #0
    [17183026.044000] ivtv: ==================== END INIT IVTV ====================
    [17183026.076000] lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    [17183026.080000] lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    [17183026.080000] lirc_pvr150: ivtv i2c driver #0: no devices found

  50. mark says:

    Sorry once again for the late replies — yet more work!

    fergal: it’s basically a case of me getting in gear and doing it. Unfortunately I’ve not found the time at the moment. I don’t know what changes the lirc guys will need from me. If you’ve got the free time then I’m happy for someone else to submit it for me!

    chad: If it can’t find the chip, there’s not really much I can do. (lirc_i2c won’t work either). Any chance that I can have a prod via SSH? It would be nice to have a play and find out what’s going on.

Leave a Reply

Your email address will not be published. Required fields are marked *