Aug
28
Filed Under (Random) by mark on 28-08-2005

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!


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

Pages: [1] 2 3 4 5 » Show All

  1. 1
    thylacine222 Says:

    I have installed both ivtv and lirc as per your instructions, using ivtv-0.3.7a and your patched lirc. When I attempt to modprobe lirc_pvr150 and lircdev, it replies with this:
    # /sbin/modprobe lirc_dev debug=1 && /sbin/modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-1.1398_FC4/misc/lirc_pvr150.ko): Unknown symbol in module, or unknown parameter (see dmesg)

    And dmesg says:
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

  2. 2
    thylacine222 Says:

    Sorry, clicked submit early. I think that it said something along the lines of this when I tried to compile ivtv with patch in ivtv-0.3.7h, but I had no messages for it in 0.3.7a

  3. 3
    Administrator Says:

    I tried this with 0.3.7h, and the patch fails to apply. It’s pretty trivial, 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 it does is export that symbol for use by other modules.

    Try doing that and you should then be able to load the module.

  4. 4
    kenadak Says:

    using knoppmyth r5a16 (auto install) I get a error when I try to compile pre-patched lirc 0.7.2 the error is something like:

    libtool invalid option “–tag=CC”

    (not a programmer but I’ve built my share of kernals in the past)

    I have upgraded libtool to 1.5.6-6

    any recommendations?

    P.S.
    does this lirc support the remote that came with the pvr-150 in ADDITION to the blaster or am I stuck with one OR the other?

  5. 5
    Administrator Says:

    OK, can you try downloading it again (file has been updated — same URL), and let me know how it goes? (details below)

    In answer to your other question, both the remote and the IR blaster are supported. They appear a a single device, which supports both writing (irsend) and reading (irw). You can disable one or other portion with the module parameters disable_rx=1 (remote) or disable_tx=1 (IR blaster).

    Detail: basically this was me not understanding autotools at all — some hours later I think I understand it (basically I was editing a bunch of autogenerated files, which you obviously aren’t supposed to do). I’ve fixed this by regenerating those files in the right way (something like autoreconf -f -i && make dist-bzip2, with some mucking about to get an appopriate version of autoconf). None of that should matter btw, the whole point is you are just supposed to be provided with the correctly generated output in the distribution tarball.

    Thanks,

    Mark

  6. 6
    Giff Says:

    Mark,

    I attempted the new patch, and dangit if it isn’t SOOO close. After making lirc, I attempted to patch ivtv. Alas, there is no file ivtv-driver.c.patch to be found in the drivers/lirc_pvr150 directory. I’m possibly missing something, but I have followed your new directions twice to no avail.

    I skipped that one part because I couldn’t find the file, and here is the new error in dmesg:

    lirc_pvr150: Unknown symbol ivtv_reset_ir_gpio

    I’m sure that is related to being unable to patch ivtv before I recompiled it. I can’t stress how much of a help you have been through all of this. Although I’m still without a remote, the new version of IVTV still works, so no harm done, and the tuner seems much better with the development release anyways. Thanks again.

  7. 7
    Administrator Says:

    I obviously need to test my instructions a bit more! After some people had compile problems, I updated the .tar.bz2 appropriately. Unfortunately this doesn’t include the patch any more. *sigh*. Sorry about that.

    I have revised step 3 in the HOWTO to include a link to the patch (here in fact).

    You are correct in that what you are seeing is exactly what is expected with an unpatched ivtv driver.

    HTH,

    Mark

  8. 8
    Giff Says:

    Mark,

    Would it be too much trouble for you to post your relevant settings files (ie the ivtv module file) that you use for the .3.7 branch of IVTV? I am only able to compile and use ~.3.3 without having major issues (though the patch on .3.3 doesn’t seem to work), and I’m hoping they are only related to settings files for .2.0. I would really appreciate it.

    I can’t give further info at this time on specific error messages, as I’m not near my ivtv/lirc box.

  9. 9
    Administrator Says:

    Sorry, not sure what you mean by settings files. If you can let me know exactly which file(s) you are after I’ll happily send them on.

    I had a look, and the 3.3 branch (nor the 0.20 branch, which basically does not properly support the PVR150/500 anyway) will not work as it does not include the necessary support for resetting the IR device of the PVR-150. If you ask the ivtv-devel list they should be able to help you out with getting the 0.3.7 branch working with your card. If you tell me what specific issues you are having I might know, but there are far more knowledgeable people on the list.

    Mark

  10. 10
    Giff Says:

    Mark,

    One last thing – you got any info on a way I can donate financially to you for all this help? I can’t really provide coding assistance – I’m a high-level SQL and MS Studio tools guy… business IT, not nitty-gritty code. But I would like to throw in for all your hard work that saves my ass ages of pain.

  11. 11
    Giff Says:

    Mark,

    I’m beginning to be the “problem child” for you. I have everything resolved except loading haup-ir-blaster.bin. I have placed that sucker into every directory imaginable. Dmesg output shows these lines:

    lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR (PVR150), addr=71]
    lirc_dev: lirc_register_plugin: sample_rate: 10
    lirc_i2c: chip found @ 0x70 (Hauppauge IR TX (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR TX (PVR150), addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_i2c: firmware haup-ir-blaster.bin not available (-2)

    After loading the machine, if I run “modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1”, this is shown in /var/log/messages:

    Aug 31 21:16:08 gifftv kernel: kobject_register failed for i2c ir driver (-17)
    Aug 31 21:16:08 gifftv kernel: [kobject_register+59/64] kobject_register+0x3b/0x40
    Aug 31 21:16:08 gifftv kernel: [bus_add_driver+64/160] bus_add_driver+0x40/0xa0
    Aug 31 21:16:08 gifftv kernel: [driver_register+59/64] driver_register+0x3b/0x40
    Aug 31 21:16:08 gifftv kernel: [pg0+548132078/1067987968] i2c_add_driver+0x3e/0xc0 [i2c_core]
    Aug 31 21:16:08 gifftv kernel: [pg0+559328698/1067987968] init_module+0x5a/0x60 [lirc_pvr150]
    Aug 31 21:16:08 gifftv kernel: [sys_init_module+370/560] sys_init_module+0x172/0x230
    Aug 31 21:16:08 gifftv kernel: [syscall_call+7/11] syscall_call+0x7/0xb

    Do you have any ideas? Thanks for all of the help.

  12. 12
    Administrator Says:

    Assuming this is still a debian woody system, try apt-get install hotplug.

  13. 13
    Daniel Sherwood Says:

    Mark

    Cheers for this update, it should make things a bit
    cleaner (I had modified the send_power script to reset
    the device and retry whenever a failure occurred).

    I still have a couple of issues though.

    1) My IR blaster cable only has a bare red LED on the
    end of it rather than the clear capsule containing the
    red and IR LEDs. I have requested a new one from
    Hauppage but they insist that this is how it should
    look. Any chance you could send me a photo of yours
    so I can send them this as a comparison and hopefully
    get a new one.

    2) I asked before about the codeset for the Pace SKY
    Digibox and you said that this could be found from the
    XML file. Please can you tell me how you get this
    from the XML file as all I see is a list of hex.

    Cheers

    Daniel

  14. 14
    Blerghass Says:

    I have gotten things working to the point where I can see the IR blaster blinking when sending (which is good). However, I can’t get it to control the cable box. I’ve run the send_power script several times and it doesn’t ever turn off the cable box. It works in windows, with numbers 41 or 72. Do you have any idea what could be wrong?

    I have also tried http://lirc.sourceforge.net/remotes/time_warner_cable/UR4-P360 since that is my remote control. It causes a low-level error though.

  15. 15
    Joe Says:

    I left a comment here a little while ago but it looks like it got deleted. It was under a different name. Not sure why.

    Anyway, I have the blaster blinking in red similar to what it does in Windows. However, after running the send_power script over and over I can’t get the cable box to respond at all. It works in Windows with either the numbers 41 or 72 (codesets I think). Any idea what could be wrong?

  16. 16
    Joe Says:

    I posted before but it’s not showing up. Not sure why.

    It works in Windows (codeset 41 or 72). I got the red light blinking. I’ve tried 41 and 72 KEY_POWER individually as well as send_power a few times. I can’t get the cable box to respond. Any ideas? Thanks.

  17. 17
    Joe Says:

    Sorry for the double post. Still not sure why my original post is gone.

    Daniel, a picture of the blaster can be found here:
    http://www.newegg.com/Product/Product.asp?Item=N82E16815116625
    It’s not a very good one, but it is obviously more than just a single LED.

  18. 18
    Joe Says:

    Sorry to keep posting, but I wanted to give you some more information.

    I am in the US and using the NTSC version of the PVR-150). I am using encoder firmware version 0x02040024. I am using your haup-ir-blaster.bin, and it loads as version 1.3.0. I am in gentoo with a 2.6.12 kernel.

    I have discovered that codesets 41, 72, 74, 75, 76, 78, and 313 all work in Windows. I am pretty sure that my HcwMako and HcwFalcn are the same as the ones that load in Windows.

    Does this differ from what you are using? Anything I can try?

  19. 19
    Administrator Says:

    Sorry, I haven’t had any time to work on this recently (actual work has been piling up, unfortunately).

    Here’s some more out of order replies:

    Daniel — I’ll try and find the time to take a picture of my IR blaster device, but it is a single LED in a clear plastic case (I’ve already taken it apart). So it should be ok, but I rather suspect it should have come with the case.
    The XML file has a section at the top that lists the windows manufacturer->codeset mappings, that’s where I look. However if you can’t get it to power on/power off using any of the codesets that’s not going to help.

    Joe — I’m not sure what’s going on there. I’m using the encoder firmware version 0x02050032 & ivtv-0.3.7b, but I doubt that really matters too much as the driver just talks to some embedded program running on a Zilog CPU on the board via I2C. It is possible I guess that the firmware could affect it, but I wouldn’t have thought so — I guess you can try it out to eliminate it). Do any of the other button presses work?

    I collated the data from I2C captures from the windows software. Can you point me at the windows software you are using? I can always run another capture through it if it is different.

    Sorry that’s not much help. If I can think of anything else to try I’ll let you know.

    One other person seems to have got the driver to change channels, so at least I’m not the only one now!

  20. 20
    Patrick Says:

    Ok, so I successfully loaded your PVR150 driver, and verified that all my /dev/lirc* entries existed. When I tried to submit some irsend commands, lircd segfaulted.

    I examined the debug output and didn’t see anything I could decipher. I do have one question, are you running this on an SMP kernel?

    Here’s the output of my dmesg:
    lirc_dev (lirc_pvr150[0]): open called
    lirc_dev (lirc_pvr150[0]): ioctl called (0x80046900)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x40046911)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x40046912)
    lirc_dev (lirc_pvr150[0]): ioctl called (0x8004690f)
    lirc_dev (lirc_pvr150[0]): poll called
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_dev (lirc_pvr150[0]): poll called
    lirc_pvr150: poll called
    lirc_pvr150: poll result = 0
    lirc_dev (lirc_pvr150[0]): write called
    lirc_pvr150: failed to get data for code 0, key 400 — check lircd.conf entries
    lirc_pvr150: sending to the IR transmitter chip failed, trying reset
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    printing eip:
    00000000
    *pde = 00000000
    Oops: 0000 [#2]
    SMP
    Modules linked in: lirc_pvr150 lirc_dev isofs zlib_inflate nls_iso8859_1 vfat fat wm8775 firmware_class tuner tveeprom ivtv videodev parport_pc lp parport snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore usbcore radeon drm intel_agp agpgart sbp2 ohci1394 ieee1394 3c59x mii st
    CPU: 0
    EIP: 0060:[] Not tainted VLI
    EFLAGS: 00210286 (2.6.11-gentoo-r9)
    EIP is at 0x0
    eax: fffffff2 ebx: 00000000 ecx: 000002cc edx: 00000007
    esi: 00000000 edi: 00000000 ebp: 00000000 esp: c5f93f5c
    ds: 007b es: 007b ss: 0068
    Process lircd (pid: 25778, threadinfo=c5f92000 task=dfbf3020)
    Stack: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    Call Trace:
    Code: Bad EIP value.
    lirc_dev (lirc_pvr150[0]): close called

    Thanks for your work on this!
    -Patrick

  21. 21
    Joe Says:

    I got all my windows software from here: http://www.hauppauge.com/pages/support/support_pvr150.html
    Specifically, I used that IR blaster setup program in “Accessories” with some of the other files there.

    I don’t know why my firmware version is different from yours. I pulled my .rom files from /windows/system32/drivers or something like that. I’m not sure where to get other firmware. I also do not know why your firmware is newer than mine.

    I am in ivtv-0.3.7c. Everything on my system is happy except that the IR blaster doesn’t affect the cable box.

  22. 22
    Administrator Says:

    I’ll try it with some older firmware this evening and get back to you. There are a whole stack of firmware images on the ivtv firmware page if you want to try it sooner.

  23. 23
    Administrator Says:

    Patrick: that’s a kernel oops, which is caused by a bug in the driver. Somebody else pointed this out to me recently. It is caused by sending invalid key codes to the driver. Please check that you are using the version of lircd.conf linked to above, it should work then (you’ll probably have to reboot though if you haven’t done so already).

    I’m using it on a UP kernel, but I don’t believe that that is the issue.

  24. 24
    Joe Says:

    Mark, are you using the same hardware as me otherwise? NTSC pvr150, US bought? I just got it recently, I don’t know if there are any revision numbers or anything. BTW, I’m on an i815 system with a tualatin celeron, sb live, gf2mx, not much else. I don’t think this would affect it, but who knows.

    Gonna try the newer firmwares now–I’ll let you know.

  25. 25
    Joe Says:

    02050032 didn’t work. What else should I try?

  26. 26
    a crick in the net » Yay! Says:

    […] I think I have the reference I need: it’s nice to find a page that solves the problems you haven’t encountered yet. But I’m reaching the tiredness point I was at last night where no further progress was made. […]

  27. 27
    Joe Says:

    Mark,

    I really appreciate your help here. I noticed something weird in the Windows software that may be related. This is in the simpler “blastcfg” part of the software. When I put code 72, it works only if I have “cable box” selected. If I have “satellite” selected, still code 72, it does not turn off my cable box, even though it still flashes red. Is there some other state bit in the card that may be important? I figured it could be relevant since it is the same light blinking, but no IR effect symptom.

    By the way, I tried 0x02040011 also, no dice. Thanks again.

  28. 28
    Administrator Says:

    Ah, thanks — I think you’ve probably nailed it there. I didn’t realise that satellite vs cable box made a difference, whereas it obviously does — I though that only the codeset number was important.

    Unfortunately it’s not even as simple as a state bit; the data block (99 bytes) seems to change substantially even between runs of the application. So basically what I need to do here is another I2C capture of all of the codesets again (hurrah!), and regenerate the ‘firmware’. I will attempt to do this in a bit. I’ll try and see if the other fields make any difference at the same time. After I’ve done that, I’m pretty optimistic that it will work for you.

    Thanks,

    Mark

  29. 29
    Joe Says:

    Thanks so much for your fast response! I’m excited now, this is the last step to making my myth box work.

    I’ll keep checking the page to look for the update.

    Hopefully this will help lots of cable box people.

  30. 30
    Administrator Says:

    I have done some experiments, and it appears that the selected device definitely changes the data that the hauppauge stuff sends over the I2C bus. To be a bit more thorough I changed the vendor & region settings as well, but they don’t appear to make any difference. I’m running another capture now, then I’ll have to post process the data + update the software to cope with it — I don’t know if I’ll manage to finish it tonight, but I’ll give it a go. I’ll send you an email when I’ve finished so you don’t have to keep checking back with this page. Funnily enough, I do happen to have a cable box but it responds as a satellite box.

    Thanks for you help with this — that was a really sharp piece of detective work.

    Mark

  31. 31
    Joe Says:

    No hurry, I won’t be able to test this tonight. Looking forward to it tomorrow though. Thanks again.

  32. 32
    Administrator Says:

    Patrick — your oops — that’s when trying to reset the IR chip. There is a bug in the code (it shouldn’t bother resetting the IR chip when sent an invalid code), but it’s actually the call to ivtv_reset_ir_gpio that’s causing it.

    Can you send me the complete dmesg output after loading the module & then the output of lsmod so I can try and track this down? Plus can you let me know which version of the ivtv driver you are using?

    What strikes me as really weird is that the “modules linked in” output from the oops doesn’t show ivtv — but lirc_pvr150 requests ivtv explicitly in the init_module function. It really looks like ivtv isn’t loaded, which ought not be possible.

    Thanks,

    Mark

  33. 33
    Clark Says:

    Mark,
    You are a king, I am in the exact same situation as Joe, light is blinking again after running through your version 2 instructions. I tested the same process as Joe in windows, using my codeset 39, and my cable box responds the same. Looking forward to your updated captures. Best regards,

    Clark

  34. 34
    JerseyJoe Says:

    Mark,

    Having the same issue as Clark and Joe, but I donn’t have a Windows side to boot too. I am fairly certain that once you get the new stuff out it should work. BTW I my Cable Box is a Scientific Atlanta Explorer 4200 from Cablevision/Optimum Online in Morristown, NJ, USA. I include this information as I am curious if Joe and Clark have anything in common with my setup.

    I have a question though. I tried putting some remote configs in my /etc/lircd.conf that should work with my cable box, but they only caused the lircd program to segfault when I called an irsend for any of the codes under these remotes. Just curious why your remote codes work and those others cause a segfault. Anyway the offending remote conf files are here.

    http://lirc.sourceforge.net/remotes/scientific_atlanta/

    Joe

    PS: Email me sometime as I think you might be able to help me out with another computer problem with my Gyration MCR having buttons that only work under Windows but not linux. If you can help me out with that I will make it worth your while.

  35. 35
    JerseyJoe Says:

    Hmm I posted a comment here yesterday but it didn’t seem to register.

    I am having the exact same issue as both Joe and Mark. I am curious to know what there equipment is, what the providor name is, and their location for comparison. I am using a Scientific Atlanta Explorer 4200 from Cablevision/Optimum Cable in Morristown, NJ, 07960

    I have a few questions. Like, why I get a segfault from your patched lircd when I tried out irsend using one of the remote configs from sourceforge site. I just appended the 2 for Scientific Atlanta to the end of the lircd.conf file that you supplied and restarted lircd. All your stuff still works but the new configs cause a segfault of the lircd. Any idea why? I don’t know enough about this stuff to guess at it.

  36. 36
    Administrator Says:

    They don’t register until I approve them — sorry I don’t get around to it quite as fast as I’d like sometimes.

    You can’t use anything other than the appropriate configuration files. All my stuff has is a list of codeset/key press numbers, so if you send something else to it it can’t do anything. Other sorts of receiver/transmitter have frequencies and pulse timings, etc — these kind of configuration files simply won’t work. I’m not sure why lircd segfaults though — it ought not do that, so I’ll try and reproduce this and fix it — all that should happen is that you get some kind of error message.

    I have done a capture and created some updated firmware with all of the cable box data as well as the satellite data, but I’ve yet to test it. Unfortunately I won’t have time to do this today as I’m now off to celebrate regaining the ashes ๐Ÿ™‚

  37. 37
    Joe Says:

    If you have the firmware file ready but not tested, would you mind posting it or e-mailing it to me so that I can test it tonight? I’ll let you know if it works for me. Thanks!

  38. 38
    Joe Says:

    I tried the new firmware and lircd.conf. It loaded 575 codesets, which was a good sign. Unfortunately, it didn’t work. Here’s what happened:

    irsend: command failed: SEND_ONCE a 1_0_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_1_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_2_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_4_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_5_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_6_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_6_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_7_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_7_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 0_8_KEY_POWER
    irsend: transmission failed
    irsend: command failed: SEND_ONCE a 1_8_KEY_POWER
    irsend: transmission failed

    Even the old “blaster” codesets also failed. Thanks for your help, and let me know if I can help you with anything to finish this up.

  39. 39
    Administrator Says:

    I wasn’t that surprised, as I said I hadn’t tested it at all! I’ve tested it properly now and fixed the issue that was preventing transmission from working. It still works for me with the old list of codesets that my device responds on, so apart from additional codesets it should be as it was.

    Please download haup-ir-blaster.bin, lircd.conf, and send_power_new again and let me know how you get on with those. You’ll need to unload & reload the lirc_pvr150 module in order to get it to pick up the updated “firmware”.

    Codesets are named DEVICE_CODESET_KEY, e.g. 0_41_KEY_POWER for cable box, codeset 41, power button or 1_41_KEY_POWER for satellite box, codeset 41, power button, etc.

    Good luck!

    Mark

  40. 40
    Joe Says:

    What did you need to fix? Just curious.

  41. 41
    Administrator Says:

    The key/codeset pair form a 32-bit number that lircd sends to the driver, the upper 16 bits are the codeset & the lower 16 bits are the key. To accomodate having two variants of each codeset I elected to set bit 31 (top most bit, previously unused) to indicate which device the codeset was for. Effectively this just renumbers the codesets (so the base driver doesn’t need to change).

    After some long winded process involving poking the windows driver and capturing the results, I run some perl scripts to post process this data and generate the ‘firmware’ – a codeset/key database. In that database each codeset has a header including the ID; this clearly ought to be a 16-bit number but in the version I knocked up before heading out to the pub I’d shifted left the device ID by 31 rather than 16 bits. That was the first issue.

    The other problem was that the codeset database is ordered by codeset id, and searched using a binary chop algorithm, thus it needs to be sorted by codeset id. The database generation script also needed to be updated to take account of setting the top bit so that the codesets end up correctly sorted in the database.

    Nothing I wouldn’t have caught during normal testing, but you did ask for it early!

  42. 42
    Clark Says:

    Mark,

    Write a book and send us your paypal, your information is as good as gold. I am up and running 100% after following your posts. I run a General Instruments Cable box that uses the standard DCT2000 Motorola remote codes. I can’t thank you enough and my wife will be glad to get the media center back in a much mre functional state.

    Best regards,
    Clark

  43. 43
    Joe Says:

    Success! Thanks so much. Amazing turnaround time on the driver fixing. I’m going to finalize my setup now. ๐Ÿ™‚

  44. 44
    J. Longman Says:

    Hi there,

    I’m trying to use your code to control my cable box, and I’ve gotten stuck. I started with Knoppmyth, but have taken the ivtv 0.3.9 drivers (I haven’t tested if sound works yet, but video does) and your lircd patch together and am having a few problems.

    Now I should mention that I also have a kworld bttv card in the machine, as well as a non-MCE PVR-150.

    Earlier I was seeing what looked like a connection to a bt878 right where it should have said something about establishing a connection, and I could never get lircd and irw to connet to each other.

    But since then I noticed that I didn’t have lirc_i2c modprobe’d. So I modprobe’d lirc_i2c, lirc_dev and then when I modprobe lirc_pvr150 I get in my dmesg:

    kobject_register failed for i2c ir driver (-17)
    [] kobject_register+0x3b/0x40
    [] bus_add_driver+0x40/0xa0
    [] driver_register+0x3b/0x40
    [] i2c_add_driver+0x3e/0xc0 [i2c_core]
    [] init_module+0x5a/0x60 [lirc_pvr150]
    [] sys_init_module+0x172/0x230
    [] syscall_call+0x7/0xb

    but lircd and irw do seem to connect, but nothing is printed, and if I run the send_etc it says the device has no TX capability.

    Finally, if I try to rmmod lirc_pvr150 I get a segmentation fault. (previously to modprobe’ing lirc_i2c I could do this).

    So, is lirc_i2c required?
    I noticed that there is an adapt_struct or somesuch passed into the driver, is it possible to the wrong one is passed in? and is it possible to control which one is passed in?
    Any further suggestions?

    I leave you with my boot dmesg (sorry and thanks!):

    bttv0: using: Jetway TV/Capture JW-TV878-FBK, Kworld KW-TV878RF [card=78,insmod option]
    bttv0: gpio: en=00000000, out=00000000 in=003fffff [init]
    tuner 1-0060: chip found @ 0xc0 (bt878 #0 [sw])
    bttv0: using tuner=2
    tuner 1-0060: type set to 2 (Philips NTSC (FI1236,FM1236 and compatibles))
    bttv0: i2c: checking for TDA9875 @ 0xb0… not found
    bttv0: i2c: checking for TDA7432 @ 0x8a… not found
    bttv0: i2c: checking for TDA9887 @ 0x86… not found
    bttv0: registered device video0
    bttv0: registered device vbi0
    bttv0: registered device radio0
    bttv0: PLL: 28636363 => 35468950 .. ok
    ivtv: ==================== START INIT IVTV ====================
    ivtv: version 0.3.9 (development svn snapshot revision ) loading
    ivtv: Linux version: 2.6.11.9-chw-2 SMP preempt 586 gcc-3.3
    ieee1394: Host added: ID:BUS[0-00:1023] GUID[00e01800001fccb3]
    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.
    ivtv: Autodetected WinTV PVR 150 card (iTVC16 based)
    ACPI: PCI interrupt 0000:02:09.0[A] -> GSI 21 (level, low) -> IRQ 21
    ivtv: i2c attach to card #0 ok [client=tveeprom, addr=50]
    ivtv: i2c attach to card #0 ok [client=(tuner unset), addr=61]
    tuner 2-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    tveeprom: Hauppauge: model = 26032, rev = C199, serial# = 8003342
    tveeprom: tuner = (idx = 99, type = -605520296)
    tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x00001000)
    tveeprom: audio_processor = TDA9850 (type = 3)
    cx25840: loading /lib/modules/HcwMakoA.ROM
    cx25840: unable to open firmware
    ivtv: i2c attach to card #0 ok [client=cx25840[50], addr=44]
    ivtv: i2c attach to card #0 ok [client=wm8775, addr=1b]
    ivtv: loading /lib/modules/ivtv-fw-enc.bin
    ivtv: Encoder revision: 0x02040011
    ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    ivtv: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    ivtv: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    ivtv: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    ivtv: Create encoder radio stream
    tuner 2-0061: type set to 47 (LG NTSC (TAPE series))
    ivtv: Initialized WinTV PVR 150, card #0
    ivtv: ==================== END INIT IVTV ====================
    cx2388x v4l2 driver version 0.0.4 loaded
    lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
    ivtv: i2c attach to card #0 ok [client=Hauppauge IR (PVR150), addr=71]
    lirc_dev: lirc_register_plugin: sample_rate: 10
    ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 17

  45. 45
    Administrator Says:

    You don’t need lirc_i2c and loading as well as lirc_pvr150 it is indeed likely to cause issues as they will try and claim the same device. Please send me the dmesg output from modprobe lirc_pvr150 after a fresh boot and we’ll see where it is going wrong from there.

  46. 46
    J. Longman Says:

    Well, that’s a relief! I’ll have to try it again when I get home. Thanks for your help. I wish I had captured the output before as I suspect its something really simple. e.g. I noticed that the lirc_pvr150 module had a “minor” option – but it didn’t seem to make a difference.

    Would /dev/lirc* need to be chmod’d 666? I think I noticed that in the Lirc docs – but since I was running as root I didn’t think about it too much.

    Thanks!

  47. 47
    Administrator Says:

    “minor” just sets the preferred minor device number, not really relevant unless you are loading multiple lirc drivers and want to be sure which /dev/lircX will be created (hotplug) or used (static).

    Setting the permissions on /dev/lircX is only relevant if you aren’t running lircd as root. /dev/lircdX is a socket created rw to all by default (see man lircd to change the permission set). The usual case is running lircd as root & not really caring which users have access to the device so unless you are particularly security conscious or are encountering a specific issue there’s no reason to manipulate the permissions.

  48. 48
    J. Longman Says:

    Looking at your initial instructions, and thinking back to yesterday, what was missing was a line similar to

    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
    (my bold, er, if it works – bold around the udev line)

    Will a (static) equivalent to this line appear if I’m not using udev (as I don’t believe Knoppmyth does)? I did an apt-get install hotplug, so I believe I do have hotplug – had to in order to make the firmware happy.

    I’m looking at the patch and I see where I have to pay attention next time — in the ir_probe method.

  49. 49
    Giff Says:

    Mark,

    I believe I may be having the same problems as the gentleman above. lirc_i2c is loading upon boot. How would I disable this permanently? lirc_pvr150 successfully loads, but I’m still having the remote lockup problem, and I’m assuming this is because lirc_i2c is still in control of the IR device. I also believe this may be the reason I am unable to load the firmware, even though hotplug is installed and running, and the firmware is in the correct location.

    Thanks.

  50. 50
    Administrator Says:

    J. Longman: no ‘static’ equivalent would appear. ‘static’ means that you have to create everything in /dev yourself with mknod. If you can send me the output from “modprobe lirc_pvr150 debug=1” then I should be able to figure out where to go from there.

    Giff: not sure, depends on what you have that is loading it automagically — have a look in /etc/modules, for example.

    That shouldn’t affect firmware loading, however. Are you sure you’ve got hotplug installed? Do things like /sbin/hotplug & /etc/hotplug/firmware.agent exist? If you really can’t get it going and you are willing to let me prod around with an SSH session then I can see if I can spot anything.

    Mark

Pages: [1] 2 3 4 5 » Show All

Leave a Reply