News
Latest: added a version that compiles with 2.6.27 kernels.
Latest: if you are packaging this, see the note at the bottom as to why I don’t provide a simple patch.
Latest: added an updated version that compiles with 2.6.24 kernels, tested against 2.6.23.12
Latest: updated `firmware` to a later revision from hauppauge (743 codesets)
HOWTO
- This is not for the MCE version of the PVR-150. This includes a USB unit which does not work the same way as the normal PVR-150, use standard lirc (and lirc_mceusb) for that.
- Use a recent kernel (note: the ivtv drivers have been part of the mainline kernel for a good number of revisions so no external drivers are required — sorry, I don’t know off hand which revision they were merged in), or for older kernels install ivtv-0.4.2+ (from this page). Earlier versions of ivtv _are not supported_.
- Get the pre-patched lirc 0.8.5-CVS-pvr150 tarball. There are also earlier versions that can be found here, should you want them. The previous revision may be required for kernels < 2.6.27 (as it is untested on lower revisions -- in theory it should work)
- You need the dialog package installed to use the lirc configuration GUI, so install that (apt-get install dialog, yum install dialog, whatever is appropriate for your distribution).
- Unpack the patched lirc:
cd /usr/src
tar xfj lirc-0.8.3-CVS-pvr150-2.tar.bz2
cd lirc-0.8.3-CVS-pvr150-2
./setup.sh
Choose:
TV card
i – Hauppauge PVR-150 TV card (note: _NOT_ ‘g – Hauppauge TV card’)
Save configuration & run configurethen:
make && make install. - IR blaster only: Now you need the ‘firmware’. This is a set of data blocks that correspond to those generated by the windows software. This goes in /usr/lib/hotplug/firmware on my debian system. Depending on your system this might also be /usr/local/lib/firmware, /lib/firmware or /lib/modules.
Note that the entire firmware is kept in memory (currently 300K) so this makes the driver quite large. (I have no plans to sort this out, memory is cheap).
- Check everything is working so far:
modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1Check the syslog output. This should report something like:
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: chip found with RX and TX
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR RX, ok]
Aug 28 02:09:11 soapbox kernel: ivtv: i2c attach [client=Hauppauge PVR150 IR TX, ok]
Aug 28 02:09:11 soapbox kernel: lirc_dev: lirc_register_plugin: sample_rate: 0
Aug 28 02:09:11 soapbox udev[5221]: creating device node ‘/dev/lirc0’
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: firmware of size 302355 loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: 743 codesets loaded
Aug 28 02:09:11 soapbox kernel: lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.
- You need to configure lircd, and find out which codeset you are going to be using. The easiest way is to start with this configuration file which contains key definitions for everything in the database. Do not use other lirc configuration files for specific STBs — these simply will not work. The IR chip is only capable of sending those codes which are in the database.
- Start lircd. Note: if you are using a static /dev, you may need to make a device for lirc. If unsure, once you have verified that the module has been loaded ok, run
ls -l /dev/lirc*. If you don’t see a/dev/lirc0or similar, then trymknod /dev/lirc0 c 61 0if the steps below fail.modprobe lirc_dev && modprobe lirc_pvr150 debug=1
lircd --device=/dev/lirc0
- You can now check if the remote is working using
irw. Run this, and press buttons on the remote. You should see some output like0000000000001795 00 Down Hauppauge_350. - Next, for the ir blaster you need to work out which codeset to use, this is the tricky bit. For this I have send_power_new, a script that just sends the power command in every single codeset. You may find your codeset number listed here if you are lucky.
Firstly, check that you are seeing the IR blaster blink. If you don’t have blinking lights at this stage, your cable probably isn’t in the card properly (try wiggling it around), or it may be broken.
Next you need to stick the IR blaster on the IR receiver of box that you intend to control, being quite careful to position it correctly — it has a very short range (a few cm) and took me a couple of goes to get right. The best way to do this is to find the IR demodulator on the box — easiest with a torch. Note that this is _not_ the light that comes on when you press a button on the remote, they tend to look like this.
If you can’t get this to work, please try and check it against the Windows driver if possible. If your device will work with the windows driver but not my driver, then it’s a driver bug that I should be able to fix. If it does not work with the Windows driver either then your only options are to use a different IR blaster or bug hauppauge until they add support for the box you are trying to control. At that point, I can update my
database too. - Once you know which codeset you want you can go and delete all of the rest from lircd.conf. They are named “XXX_key” so should be pretty easy to find. I also gave the keys standard names (0-9).
- To get mythtv to work, configure a channel change script for your device. There’s one here that should work out of the box if you
rename the number keys. - If you’re happy, you can always send me beer money. If not, add comments at the bottom 🙂
That’s it, good luck!
Packaging
The lirc distribution tarball is generated using `make dist-bzip2` which uses the gnu autotools to generate a configure script, and Makefile.in, etc. The contents of these generated files depends very much on the version of autotools that is installed; this varies from distribution to distribution. I don’t have the same auto* as the lirc maintainers, so producing a patch file against a distribution tarball makes a patch bigger than the original source archive. Hence I don’t bother; I just make a new dist bzip2 and drop it here.
I maintain the code by importing a current lirc CVS into a subversion repository hosted on this server. I tag each lirc import, generate a diff from the previous lirc import and apply it to my source tree, then port any fixes from lirc_i2c.c to lirc_pvr150.c, test, and generate a new .tar.bz2. To get the source tree you can do:
svn co http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc lirc
and you can get the changes I made to the CVS revision of lirc with:
svn diff http://svn.blushingpenguin.com/svn/vendor/lirc/current http://svn.blushingpenguin.com/svn/trunk/3rdparty/lirc
I guess it is my code, the page links to the firmware, etc. on this site. I don’t know what changes have been made to it from the code I provide. I guess just try it — if it works, fine — it’s usually easier to use your distribution’s package.
Thanks!
Mark
Got a slightly different error, the virtual address is zeroes. Here are the first few lines. Let me know if I can help
Aug 29 05:24:32 mythical lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
Aug 29 05:24:32 mythical lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
Aug 29 05:24:32 mythical lirc_pvr150: chip found with RX and TX
Aug 29 05:24:32 mythical BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 29 05:24:32 mythical printing eip:
Aug 29 05:24:32 mythical c03c33d4
Aug 29 05:24:32 mythical *pde = 00000000
Aug 29 05:24:32 mythical Oops: 0002 [#1]
Aug 29 05:24:32 mythical PREEMPT
Did you get a backtrace this time? I guess you could try inserting printk’s every so often to figure out what line is causing it to fall over.
In the meantime I have tried the code against 2.6.22-5 (stock kernel.org) and it is working for me.
Sure, I have the trace, just didn’t want to clutter up your page.
Aug 29 05:24:32 mythical lirc_dev: IR Remote Control driver registered, at major 61
Aug 29 05:24:32 mythical lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
Aug 29 05:24:32 mythical lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
Aug 29 05:24:32 mythical lirc_pvr150: chip found with RX and TX
Aug 29 05:24:32 mythical BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000
Aug 29 05:24:32 mythical printing eip:
Aug 29 05:24:32 mythical c03c33d4
Aug 29 05:24:32 mythical *pde = 00000000
Aug 29 05:24:32 mythical Oops: 0002 [#1]
Aug 29 05:24:32 mythical PREEMPT
Aug 29 05:24:32 mythical Modules linked in: lirc_pvr150 lirc_dev snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq wm8775 cx25840 tuner ivtv cx2341x tveeprom snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore i2c_viapro vt8623fb fb svgalib cfbcopyarea vgastate cfbimgblt cfbfillrect
Aug 29 05:24:32 mythical CPU: 0
Aug 29 05:24:32 mythical EIP: 0060:[] Not tainted VLI
Aug 29 05:24:32 mythical EFLAGS: 00010202 (2.6.22-gentoo-r5 #1)
Aug 29 05:24:32 mythical EIP is at __mutex_lock_slowpath+0x23/0x98
Aug 29 05:24:32 mythical eax: dd005882 ebx: dd00587e ecx: 00000000 edx: 00000000
Aug 29 05:24:32 mythical esi: d0c11590 edi: fffffff0 ebp: dd52a800 esp: d1077d30
Aug 29 05:24:32 mythical ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
Aug 29 05:24:32 mythical Process modprobe (pid: 10580, ti=d1076000 task=d0c11590 task.ti=d1076000)
Aug 29 05:24:32 mythical Stack: dd005882 dd2cecd8 00000035 c0115935 dd52a874 dd005852 c03c33a6 c034a64a
Aug 29 05:24:32 mythical d1077dd3 71fe2600 d1077da8 00000000 00000246 00000001 dd52a874 dd52a874
Aug 29 05:24:32 mythical dd52a800 e3b93416 dd52a874 e3b9422e dd52a88f e3b9360c e3b941f6 e3b941dc
Aug 29 05:24:32 mythical Call Trace:
Aug 29 05:24:32 mythical [] vprintk+0x23e/0x248
Aug 29 05:24:32 mythical [] mutex_lock+0x9/0xa
Aug 29 05:24:32 mythical [] i2c_attach_client+0x18/0x15f
Aug 29 05:24:32 mythical [] i2c_attach+0x12/0x42 [lirc_pvr150]
Aug 29 05:24:32 mythical [] ir_attach+0x1c6/0x309 [lirc_pvr150]
Aug 29 05:24:32 mythical [] ir_probe+0x109/0x12e [lirc_pvr150]
Aug 29 05:24:32 mythical [] i2c_register_driver+0xad/0xce
Aug 29 05:24:32 mythical [] init_module+0x46/0x4a [lirc_pvr150]
Aug 29 05:24:32 mythical [] sys_init_module+0x89/0x133
Aug 29 05:24:32 mythical [] syscall_call+0x7/0xb
Aug 29 05:24:32 mythical =======================
Aug 29 05:24:32 mythical Code: 7f 05 e8 99 00 00 00 c3 56 53 83 ec 10 89 c3 89 e0 25 00 e0 ff ff 8b 35 00 00 48 c0 ff 40 14 8d 43 04 8b 50 04 89 04 24 89 60 04 22 89 54 24 04 89 74 24 08 83 c8 ff 87 03 48 74 2d c7 06 02
Aug 29 05:24:32 mythical EIP: [] __mutex_lock_slowpath+0x23/0x98 SS:ESP 0068:d1077d30
Aug 29 05:24:32 mythical note: modprobe[10580] exited with preempt_count 1
Aug 29 05:24:32 mythical BUG: scheduling while atomic: modprobe/0x10000001/10580
Aug 29 05:24:32 mythical [] __sched_text_start+0x56/0x556
Aug 29 05:24:32 mythical [] unmap_page_range+0xb2/0x100
Aug 29 05:24:32 mythical [] min_pages_to_free+0xd/0x1c
Aug 29 05:24:32 mythical [] __cond_resched+0x16/0x34
Aug 29 05:24:32 mythical [] cond_resched+0x26/0x31
Aug 29 05:24:32 mythical [] unmap_vmas+0x14b/0x1a5
Aug 29 05:24:32 mythical [] exit_mmap+0x66/0xe6
Aug 29 05:24:32 mythical [] mmput+0x1f/0x7c
Aug 29 05:24:32 mythical [] do_exit+0x1c6/0x38b
Aug 29 05:24:32 mythical [] die+0x1c0/0x1c8
Aug 29 05:24:32 mythical [] do_page_fault+0x45f/0x539
Aug 29 05:24:32 mythical [] do_page_fault+0x0/0x539
Aug 29 05:24:32 mythical [] error_code+0x6a/0x70
Aug 29 05:24:32 mythical [] __mutex_lock_slowpath+0x23/0x98
Aug 29 05:24:32 mythical [] vprintk+0x23e/0x248
Aug 29 05:24:32 mythical [] mutex_lock+0x9/0xa
Aug 29 05:24:32 mythical [] i2c_attach_client+0x18/0x15f
Aug 29 05:24:32 mythical [] i2c_attach+0x12/0x42 [lirc_pvr150]
Aug 29 05:24:32 mythical [] ir_attach+0x1c6/0x309 [lirc_pvr150]
Aug 29 05:24:32 mythical [] ir_probe+0x109/0x12e [lirc_pvr150]
Aug 29 05:24:32 mythical [] i2c_register_driver+0xad/0xce
Aug 29 05:24:32 mythical [] init_module+0x46/0x4a [lirc_pvr150]
Aug 29 05:24:32 mythical [] sys_init_module+0x89/0x133
Aug 29 05:24:32 mythical [] syscall_call+0x7/0xb
Aug 29 05:24:32 mythical =======================
I guess sticking printk’s in various strategic places would help narrow it down a bit. It definitely shouldn’t be the i2c name length change causes overwriting structure issue any more (I changed it to use strlcpy, so it should truncate at worst), therefore something else is going on. Do gentoo just use stock kernels or they patched? Also, I can have a poke via SSH if you are happy with that and don’t mind the box being reboot copiously at some point (let me know if you want that and I will send you my ssh key). Can’t think of anything else OTOMH, this is the first time I’ve seen a crash bug for years so I suspect it’s due to some kernel interface change.
The gentoo kernel that I am using is patched. I can give you access, but will have to spend some time changing a few permissions and stuff on the box first.
Just for reference, this is resolved. The old code was being used by mistake, so it looks like things are all good with 2.6.22 now. Plus now my mythtv box is finally running something newer than 2.6.15, which will make it easier to test against future kernels.
Next job is to find some kind of paging extension for the comments, this is _way_ too long now.
First: thanks so much Mark. I’m so close to send beer money! If only it worked…
I have a mediasat max top box (france, canalsat), and none of the code sets will work (either Windows or Linux). I tried also my old mediasat box… no luck.
I was hoping someone else had succeeded before with a mediasat box, before I start to bug Hauppauge support…
Thanks, alex.
There is a new codeset dump from hauppauge, I will try and sort it out early next week. Unfortunately I don’t know if this includes a code that will control your box. At the moment, I cannot get to the Windows box I use for codeset dumps — it is in storage because the house is being decorated at the moment.
lircd: error in configfile line 291:
lircd: “2150039562”: must be a valid (lirc_t) number
lircd: reading of config file failed
I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)
logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x = n 8027000a => 8027000a =
lircd: error in configfile line 291:
lircd: “2150039562”: must be a valid (lirc_t) number
lircd: reading of config file failed
I added this to daemons/config_file.c : lirc_t s_strtolirc_t(char *val)
logprintf(LOG_ERR,”DBG s_strtolirc_t: %d: %s => n %lx => %x == %lx”,line,val,n,h,((unsigned long) h));
lircd: DBG s_strtolirc_t: 291: 2150039562 => n 8027000a => 8027000a == ffffffff8027000a
The problem is that when a signed int is cast to a larger unit, the sign bit is extended.
(Note, each line should start with a space, and the indentation should be one or two tabs instead of spaces… I copied right off my console and tabs probably won’t post correctly here anyway.)
— daemons/config_file.c.old 2007-08-31 21:43:48.120382951 -0700
+++ daemons/config_file.c 2007-08-31 21:59:38.503700384 -0700
@@ -200,7 +200,7 @@ lirc_t s_strtolirc_t(char *val)
n=strtoul(val,&endptr,0);
h=(lirc_t) n;
– if(!*val || *endptr || n!=((unsigned long) h))
+ if(!*val || *endptr)
{
logprintf(LOG_ERR,”error in configfile line %d:”,line);
logprintf(LOG_ERR,”\”%s\”: must be a valid (lirc_t) “
Hi Guys,
The patch that the guy gave at the end with the diff file fixed the problem.
Thanks for the patch, I have uploaded a revised tarball.
Did anyone get the ir blaster to work with a motorola vip1200. I saw someone post about it awhile back. It does work in windows using AT&T code 130 or 0130, cant remember which. I think I just need to wait until the firmware gets updated.
Thanks again Mark I have been using this for a year or two and am now adding an additional stb to the mix.
Hi Mark
I get much the same behaviour as Xavier reported in entry 20. Codesets 384, 661 and 666 work partially with my satbox (Triax 40S): sometimes the satbox accepts the code sent, sometimes not.
However, using the Hauppauge Windows program for setting up the blaster, all three codesets work perfectly.
Mark, is there any parameter (e.g. in lircd.conf) that I could try tweaking to get the same ir signal sent, as with the Windows program?
Xavier, how did you solve this problem? The idea of appending a vol_up command or similar does not work with my satbox.
Best regards,
Bo
Correction: I was referring to Xavier\’s entry no 17.
HELP!!! I just re-re-re-installed Mythdora and after following the very awesome config that you have here plus the one on http://charles.hopto.org/blog/?p=24 I’m getting a hardware does not support sending error when I try to use the irsend SEND_ONCE blaster POWER command to test. I’m a very frustrated newb right now. I’ve tried two separate versions of myth and I ACTUALLY had this thing working on a previous install. I’m looking at over 60 hours of toiling on trying to get a box up and running and of course, this is the last #*$@ thing that I need to make this work. I tried looking at the syslog after doing the commands to test, but it didn’t put anything in the log or I’m looking at the wrong one. HELP!!!
Hey Mark, Great job works perfect for me with a SA 1840 with codeset 41.
Quick question, I also have an ATI usb Remote wonder that previous worked with the lirc_atiusb module but now I can’t seem to load it. Short of compiling a 2nd instance of lirc is there a way to include it when building this package? I know on other distros i’ve seen the option to include more than one module when building lirc but I can’t seem to find it here.
thanks again,
Ben
I don\\\’t know if this process is correct for my 2setup. I have a PVR150 with a USB IR Receiver.. I want to set up a serial IR blaster to change channel2s on my sat bo/x.. if I run this LIRC compile etc.. will it work for me?
Mark… Thanks a bunch.
I was haveing a nightmare geting my 150 blaster to work in Ubuntu 7.10 Gusty. found this little slice of heaven and no more nightmares.
Thanks
Mark,
I was able to get lirc_pvr150 working without a hitch in ubuntu feisty but when I upgrade to gutsy I run into some problems (kernel 2.6.22).
The code compiles fine but then it segfaults when I go to load the module.
dmesg reports:
[ 81.548000] lirc_dev: IR Remote Control driver registered, at major 61
[ 81.592000] lirc_pvr150: chip found with RX and TX
[ 81.592000] BUG: unable to handle kernel paging request at virtual address 52540013
[ 81.592000] printing eip:
[ 81.592000] c02f31bb
[ 81.592000] *pde = 00000000
[ 81.592000] Oops: 0002 [#1]
[ 81.592000] SMP
[ 81.592000] Modules linked in: lirc_pvr150 lirc_dev binfmt_misc rfcomm l2cap bluetooth ppdev ipv6 powernow_k8 cpufreq_conservative cpufreq_powersave cpufreq_stats cpufreq_userspace cpufreq_ondemand freq_table container button sbs dock ac video battery af_packet nvram nxt200x saa7134_alsa saa7134_dvb dvb_pll saa7134 compat_ioctl32 ir_kbd_i2c ir_common video_buf_dvb dvb_core video_buf tda1004x sbp2 lp wm8775 cx25840 tuner snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ivtv snd i2c_algo_bit soundcore cx2341x tveeprom videodev v4l2_common snd_page_alloc i2c_nforce2 parport_pc parport serio_raw v4l1_compat nvidia(P) k8temp psmouse pcspkr agpgart i2c_core evdev ext3 jbd mbcache sg sd_mod usb_storage libusual ide_cd cdrom sata_nv ata_generic amd74xx ide_core ehci_hcd ohci1394 ieee1394 libata scsi_mod forcedeth ohci_hcd usbcore dm_mirror dm_snapshot dm_mod thermal processor fan fuse apparmor commoncap
[ 81.592000] CPU: 1
[ 81.592000] EIP: 0060:[] Tainted: P VLI
[ 81.592000] EFLAGS: 00010206 (2.6.22-14-generic #1)
[ 81.592000] EIP is at __mutex_lock_slowpath+0x2b/0x90
[ 81.592000] eax: ffffffff ebx: f6005882 ecx: 00000000 edx: 52540013
[ 81.592000] esi: f6005886 edi: ebf86000 ebp: f600588a esp: e6557c20
[ 81.592000] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 81.592000] Process modprobe (pid: 6871, ti=e6556000 task=ebf86000 task.ti=e6556000)
[ 81.592000] Stack: f600588a 23493400 00000246 f6005882 e8c25878 f6005852 fffffff0 c02f3084
[ 81.592000] e6557e7c f8997f79 f604ed78 f604ed58 00000001 f8997237 e6557c70 f604ed58
[ 81.592000] f6005882 e6557e7c e8c25878 e8c25800 e8c25800 f8e3a67d e6557e7c f8e3c840
[ 81.592000] Call Trace:
[ 81.592000] [] mutex_lock+0x14/0x20
[ 81.592000] [] i2c_attach_client+0x29/0x190 [i2c_core]
[ 81.592000] [] i2c_transfer+0x47/0x60 [i2c_core]
[ 81.592000] [] i2c_attach+0x1d/0x60 [lirc_pvr150]
[ 81.592000] [] ir_probe+0x4d3/0x910 [lirc_pvr150]
[ 81.592000] [] i2c_register_driver+0xd5/0x120 [i2c_core]
[ 81.592000] [] init_module+0x48/0x50 [lirc_pvr150]
[ 81.592000] [] sys_init_module+0x151/0x1a00
[ 81.592000] [] prio_tree_insert+0x1f/0x250
[ 81.592000] [] sysenter_past_esp+0x6b/0xa9
[ 81.592000] =======================
[ 81.592000] Code: 55 57 56 53 89 c3 8d 70 04 83 ec 0c 89 f0 64 8b 3d 00 90 43 c0 e8 a6 0c 00 00 8d 6b 08 b8 ff ff ff ff 8b 55 04 89 2c 24 89 65 04 22 89 54 24 04 89 7c 24 08 87 03 83 e8 01 74 2a 8d 74 26 00
[ 81.592000] EIP: [] __mutex_lock_slowpath+0x2b/0x90 SS:ESP 0068:e6557c20
Do you think its a problem with my configuration, or something with the code itself?
Thanks in advance,
I followed the doc above and able to turn on my set top box. Now I am also lost at the step 11 how to use this change_channel script in the mythtv and what is the rename the number keys?
I have not modified the script other than changing it name to change_channel.pl script.
Below is the error that I get.
[mythtv@localhost bin]$ change_channel.pl 220
channel changing 220
irsend: command failed: SEND_ONCE blaster 2
irsend: unknown command: “2”
Please let me know what should I do to fix it.
Thanks,
Raj
irsend is throwing the error…
irsend: hardware does not support sending
I’m running:
gentoo-2.6.22-r9
ivtv-1.0.3-r1
lirc-0.8.3_pre1
I have the firmware haup-ir-blaster.bin in /lib/firmware but I don’t think it’s loading
Nov 26 05:29:17 mythtv ivtv: ==================== START INIT IVTV ====================
Nov 26 05:29:17 mythtv ivtv: version 1.0.0 (2.6.22-gentoo-r9 mod_unload PENTIUM4 ) loading
Nov 26 05:29:17 mythtv ivtv0: Autodetected Hauppauge card (cx23416 based)
Nov 26 05:29:17 mythtv ACPI: PCI Interrupt 0000:02:0e.0[A] -> GSI 17 (level, low) -> IRQ 18
Nov 26 05:29:18 mythtv ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
Nov 26 05:29:18 mythtv ivtv0: Encoder revision: 0x02060039
Nov 26 05:29:18 mythtv tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Nov 26 05:29:18 mythtv cx25840 0-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
Nov 26 05:29:22 mythtv cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
Nov 26 05:29:22 mythtv wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
Nov 26 05:29:22 mythtv lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
Nov 26 05:29:22 mythtv lirc_dev: lirc_register_plugin: sample_rate: 10
Nov 26 05:29:22 mythtv tveeprom 0-0050: Hauppauge model 26152, rev E5B2, serial# 10296113
Nov 26 05:29:22 mythtv tveeprom 0-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
Nov 26 05:29:22 mythtv tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
Nov 26 05:29:22 mythtv tveeprom 0-0050: audio processor is CX25843 (idx 37)
Nov 26 05:29:22 mythtv tveeprom 0-0050: decoder processor is CX25843 (idx 30)
Nov 26 05:29:22 mythtv tveeprom 0-0050: has no radio, has IR receiver, has IR transmitter
Nov 26 05:29:22 mythtv ivtv0: Autodetected Hauppauge WinTV PVR-150
Nov 26 05:29:22 mythtv ivtv0: reopen i2c bus for IR-blaster support
Nov 26 05:29:22 mythtv tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0)
Nov 26 05:29:22 mythtv cx25840 0-0044: cx25843-24 found @ 0x88 (ivtv i2c driver #0)
Nov 26 05:29:26 mythtv cx25840 0-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
Nov 26 05:29:26 mythtv wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0)
Nov 26 05:29:26 mythtv lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
Nov 26 05:29:26 mythtv lirc_dev: lirc_register_plugin: sample_rate: 10
Nov 26 05:29:26 mythtv tuner 0-0061: type set to 50 (TCL 2002N)
Nov 26 05:29:26 mythtv ivtv0: Registered device video0 for encoder MPEG (4 MB)
Nov 26 05:29:26 mythtv ivtv0: Registered device video32 for encoder YUV (2 MB)
Nov 26 05:29:26 mythtv ivtv0: Registered device vbi0 for encoder VBI (1 MB)
Nov 26 05:29:26 mythtv ivtv0: Registered device video24 for encoder PCM audio (1 MB)
Nov 26 05:29:26 mythtv ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
Nov 26 05:29:26 mythtv ivtv: ==================== END INIT IVTV ====================
Nov 26 05:29:26 mythtv kobject_add failed for i2c ir driver with -EEXIST, don’t try to register things with the same name in the same directory.
Nov 26 05:29:26 mythtv [] kobject_shadow_add+0x141/0x173
Nov 26 05:29:26 mythtv [] kobject_register+0x19/0x30
Nov 26 05:29:26 mythtv [] bus_add_driver+0x50/0x16d
Nov 26 05:29:26 mythtv [] i2c_register_driver+0x58/0xcb [i2c_core]
Nov 26 05:29:26 mythtv [] init_module+0x48/0x4c [lirc_pvr150]
Nov 26 05:29:26 mythtv [] sys_init_module+0x11f1/0x1327
Nov 26 05:29:26 mythtv [] lirc_register_plugin+0x0/0x41d [lirc_dev]
Nov 26 05:29:26 mythtv [] do_sync_read+0x0/0x109
Nov 26 05:29:26 mythtv [] sysenter_past_esp+0x5f/0x85
Nov 26 05:29:26 mythtv [] ipt_register_table+0x25/0xa4
Nov 26 05:29:26 mythtv =======================
Any help would be greatly appreciated.
I was planning to wait for 2.6.24 to upgrade the kernel on my mythtv system again… but a storm caused a nice 30 min power failure and that was more then the UPS could handle… so I reboot in to 2.6.23… and find that I can get ivtv to compile but not lirc…
I have tried looking in to this, but Makefiles are things I don’t even have a clue where to begin with. From the source lines, it looks like either kernel-functions or the macros for the major/minor numbers aren’t being filled in.
make all-recursive
make[1]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150′
Making all in drivers
make[2]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers’
Making all in lirc_dev
make[3]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
Makefile:8: **************************************************
Makefile:8: *** Makefile trick not undone, trying to recover *
Makefile:8: **************************************************
mv Makefile.automake Makefile
make all
make[4]: Entering directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
mv Makefile Makefile.automake
cp ../Makefile.kernel Makefile
make -C /lib/modules/2.6.23-gentoo-r3/build/ SUBDIRS=/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev modules \
KBUILD_VERBOSE=1
make[5]: Entering directory `/usr/src/linux-2.6.23-gentoo-r3′
test -e include/linux/autoconf.h -a -e include/config/auto.conf || ( \
echo; \
echo ” ERROR: Kernel configuration is invalid.”; \
echo ” include/linux/autoconf.h or include/config/auto.conf are missing.”; \
echo ” Run ‘make oldconfig && make prepare’ on kernel src to fix it.”; \
echo; \
/bin/false)
mkdir -p /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_versions
rm -f /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_versions/*
make -f scripts/Makefile.build obj=/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev
gcc -Wp,-MD,/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.lirc_dev.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include -D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -march=k8 -m64 -mno-red-zone -mcmodel=kernel -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/../.. -I/lib/modules/2.6.23-gentoo-r3/build//include/ -I/lib/modules/2.6.23-gentoo-r3/build//drivers/media/video/ -DMODULE -D”KBUILD_STR(s)=#s” -D”KBUILD_BASENAME=KBUILD_STR(lirc_dev)” -D”KBUILD_MODNAME=KBUILD_STR(lirc_dev)” -c -o /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/.tmp_lirc_dev.o /usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c
/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘lirc_dev_init’:
/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: error: void value not ignored as it ought to be
/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘cleanup_module’:
/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: error: void value not ignored as it ought to be
make[6]: *** [/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.o] Error 1
make[5]: *** [_module_/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev] Error 2
make[5]: Leaving directory `/usr/src/linux-2.6.23-gentoo-r3′
make[4]: *** [lirc_dev.o] Error 2
make[4]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150/drivers’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/pvr150/lirc-0.8.3-CVS-pvr150′
make: *** [all] Error 2
Hi Mark,
Many, Many thanks for your GREAT work ! I’m really near to use my IR blaster now 🙂
I encounter two troubles :
At the time of make, on my system (Kernel 2.6.23.1, I suspect that the reason of the trouble is somewhere here), I run in this trouble :
/home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘lirc_dev_init’:
/home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: erreur: valeur void n’a pas été ignorée comme elle aurait dû l’être
/home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function ‘cleanup_module’:
/home/freevo/Téléchargement/lircd-remote/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: erreur: valeur void n’a pas été ignorée comme elle aurait dû l’être
Sorry, my system is in french, but in English, the error message should be “void value not ignored as it ought to be”
I’m a C newbee, but Google told me that this has to do to a call to a function, waiting a return, but the function don’t want to give something back.
So I did this (crude) hack :
———————————————————————
diff -u drivers/lirc_dev/lirc_dev.c ../../lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c
— drivers/lirc_dev/lirc_dev.c 2007-03-18 10:05:10.000000000 +0100
+++ ../../lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c 2007-12-02 19:03:35.000000000 +0100
@@ -880,8 +880,9 @@
return SUCCESS;
out_unregister:
– if(unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME))
– printk(KERN_ERR “lirc_dev: unregister_chrdev failed!\n”);
+ unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
+ /* if(unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME))
+ printk(KERN_ERR “lirc_dev: unregister_chrdev failed!\n”); */
out:
return -1;
}
@@ -907,7 +908,7 @@
{
int ret;
– ret = unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
+ unregister_chrdev(IRCTL_DEV_MAJOR, IRCTL_DEV_NAME);
class_destroy(lirc_class);
if(ret)
—————————————————————————
With this hack, the driver compiles and seems to be OK, as I can see the led blinking when I start send_power_new.
And now, I cone to my second trouble :
It seems that send_power_new to my ADSL TV Box (it’a a freebox, free is one of the three big ISP in France), I cannot wake up my box.
Switching to Windows XP, and using the latest irblaster soft, I can drive (not totally, but fairly good) my freebox by selecting the 706 model.
I think I read that in this case, you could eventually do something for us (read : me 😉 ). as I said, I have also a Windows XP part on this system, if you need some other informations.
Thanks again,
Pascal
Hi Mark and all,
Forget the second part of my preceding message :
The keycode for a ‘706’ type remote are presents in the lircd.conf file, and are working with my freebox (For the record, if someone else does research about freebox, I’m owning a Freebox V4).
But now, I encounter another trouble :
On this box, to select a channel number with more than one digit, (saying channel 12), I have to depress continuously the key 1 around
1 or 2 second, until the cursor on the screen move right, and then, I have to depress the key 2.
I didn’t find the trick to mimic this behaviour with irsend (nor was I able to do that on Windows).
Here is what I tried :
irsend SEND_START blaster 1_706_KEY_1 ; sleep 2 ; irsend SEND_STOP blaster 1_706_KEY_1 ; irsend SEND_ONCE blaster 1_706_KEY_2
and
for i in 1 2 3 4 5 ; do irsend SEND_ONCE blaster 1_706_KEY_1; done ; irsend SEND_ONCE blaster 1_706_KEY_2
But in the two cases, it seems that the data flow simply stop to long and my box understand that as many shorts depress of the 1 key, f
ollowed by one press on the 2 key.
Any ideas on how to change that (if this is possible) ?
Thanks,
Pascal
Hi Mark and all,
Forget my preceding message 🙂
I found a solution :
The gap (time between two action is long by default in the configuration file : gap = 333333 (I don’t know what kind of time this is ???)
I changed the gap to 5000, and now I can change to the channel 199 like that :
irsend –count=5 SEND_ONCE blaster 1_706_KEY_1 ; sleep 1 ; irsend –count=5 SEND_ONCE blaster 1_706_KEY_9; sleep 1 ; irsend SEND_ONCE blaster 1_706_KEY_9
So, for now, everything is OK 😀
Thanks,
Pascal
I’m having difficulty compiling the patch.
I’m using Linux 2.6.23.9-85.fc8 i686 athlon i386 GNU/Linux
I ./setup.sh and choose ‘i’ from the tv card menu. then save and configure.
that seems to go well, but when I make:
/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function âlirc_dev_initâ:
/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:883: error: void value not ignored as it ought to be
/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c: In function âcleanup_moduleâ:
/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.c:910: error: void value not ignored as it ought to be
make[5]: *** [/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev/lirc_dev.o] Error 1
make[4]: *** [_module_/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev] Error 2
make[4]: Leaving directory `/usr/src/kernels/2.6.23.9-85.fc8-i686′
make[3]: *** [lirc_dev.o] Error 2
make[3]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150/drivers/lirc_dev’
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150/drivers’
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/lirc-0.8.3-CVS-pvr150′
make: *** [all] Error 2
I’ve made sure that i have gcc and devel libs and anything else I could dig up on the net, but I can’t get past this point.
Thank for you help, and thanks for making this patch.
PB
I have been having difficulty getting this to work on 2.6.23, but it might just be my incompetence in prepping the kernel sources. Has anyone else been able to make this work?
Mike, PB, anyone else: I have updated the driver to compile with 2.6.24/2.6.23, and tested it on a 2.6.23.12 kernel.org release. Please let me know if you still have trouble, (poke me via email if I don’t respond).
Pascal: glad you fixed yourself up, the gap is in microseconds and is just a standard lirc parameter. It is tuned for my STB I believe 😉
Mythbuntu seems to come with your patched software. However, when I modprobe lirc_pvr150, it freezes and I never get the command prompt back.
syslog:Jan 23 13:58:45 mythslave lircd-0.8.2[5247]: lircd(userspace) ready
syslog:Jan 23 14:02:36 mythslave kernel: [ 287.538038] lirc_dev: IR Remote Control driver registered, at major 61
syslog:Jan 23 14:02:36 mythslave kernel: [ 287.590861] lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
syslog:Jan 23 14:02:36 mythslave kernel: [ 287.591350] lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
syslog:Jan 23 14:02:36 mythslave kernel: [ 287.591353] lirc_pvr150: chip found with RX and TX
Any ideas?
Please uninstall the packaged software and use the version above. If you still have trouble, then get back to me. (Alternatively, you could ask the package maintainer).
I’m trying to install this in mythbuntu, since following their instructions to get the pvr-150 blaster working didn’t work but everytime I try ./setup.sh and select "Save configuration & run configure" it runs through a big list of checks and then exits on "configure: error: *** you need to have the Linux kernel source installed for this driver" but I tried installing the linux source from synaptic and that still didn’t remedy the problem. Any Ideas?
Oh, and when I tried to get the blaster working the mythbuntu way i’d run "irsend SEND_ONCE POWEROFF command and it’d tell me that my hardware didn’t support transmitting or something like that… now it’s telling me ‘could not connect to socket’ ‘Connection refused’
gah! and on top of that I’m supposed to be working :/ Any help is very much appreciated!
> “configure: error: *** you need to have the Linux kernel source installed for this driver†but I tried
> installing the linux source from synaptic and that still didn’t remedy the problem. Any Ideas?
If that’s ubuntu derived, then you need to install the linux-headers package that matches your kernel flavour,
e.g. linux-headers-generic to build out of tree modules.
Okay, I got that sorted out, thank you very much for responding. but now I’m back to square 1 with irsend reporting ‘hardware does not support sending’
I’m a total linux idiot, so bare with me, but I think it has something to do with the lirc_pvr150 module. after running #modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1 I ran #dmesg | grep lirc and got the following
[ 91.598330] lirc_dev: IR Remote Control driver registered, major 61
[ 92.055473] lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
[ 92.056018] lirc_dev: lirc_register_plugin: sample_rate: 10
[ 187.794746] lirc_pvr150: no version for “lirc_unregister_plugin” found: kernel tainted.
[ 187.858473] [] init_module+0x48/0x50 [lirc_pvr150]
*as a side note, your CAPTCHA is very hard to decipher most times (has taken me > 2 tries each time now) you might look at reCaptcha or a honeypot style anti-spam method if you would like help setting either of those up, I’d be happy to help
> but now I’m back to square 1 with irsend reporting
> ‘hardware does not support sending’
…
> [ 91.598330] lirc_dev: IR Remote Control driver registered, major 61
> [ 92.055473] lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
You’ve loaded the wrong driver. Uninstall the distribution package.
> as a side note, your CAPTCHA is very hard to decipher most times
> (has taken me > 2 tries each time now) you might look at reCaptcha
> or a honeypot style anti-spam method if you would like help setting
> either of those up, I’d be happy to help
Thanks for the offer, but just send me mail if it bugs you 😉
Hi Mark, thanks for your work on this, I used it to get my pvr_150 going on MythBuntu, worked great until I got to the blaster portion, I also get the invalid remote “blaster” when running your test script, I have come to the conclusion that it is because there is no “blaster” remote listed in the conf file.. now this may have been answered before but I cannot find it if it has… I have looked all over the net for the config file which lists the blaster remote with all the codesets in the file. I found one rather old and it does not have my codeset in it.. the DirecTV R10 which is 112 and 125. Do you have the latest file and does it contain the R10 codeset(s) in it? Thanks in advance..
Chris..
It’s linked above in step 8, and has both 112/125 codesets in it.
Thanks Mark, I knew it had to be a oversite on my end.. Question, has anyone ever gotten this to work with the DirecTV R10 box, if so whats the secret?
I can’t help without more information. Are you saying that none of the 0_112, 1_112, 0_125 or 1_125 codesets work with your box?
not asking for a newer firmware.
I want to know what is the date of the driver you pulled the above firmware from?
I had this working wonderfully with my direcTV box, but now I\\\\\\\\\\\\\\\’ve just switched to digital cable and have a Scientific Atlanta Explorer 3100 that doesn\\\\\\\\\\\\\\\’t seem to respond to any of the codes provided (0_78 is the codeset for this box, but i\\\\\\\\\\\\\\\’ve also run send_power_new). Do you suppose this is a \\\\\\\\\\\\\\\’firmware\\\\\\\\\\\\\\\’ problem, or a setup problem? I also tried to get this working with standard LIRC and a serial IR blaster that I managed to get my hands on and it\\\\\\\\\\\\\\\’s the same thing, the light flashes, the right codes are configured, but nothing happens with my box…
Sorry if this is a double comment – my last one didn’t seem to go through.
Firstly, thanks for the effort you’ve put in to this. I’ve got the remote side working (irw works), but have yet to have success with the blaster or irsend commands. Doing a single irsend command tells me that my device doesn’t support it.
I’ve put the .bin in my /lib/firmware// dir, successfully installed your version of lirc, but I DO get a slightly different output when looking at the syslog and grepping for ‘lirc’:
lirc_dev: IR Remote Control driver registered, at major 61
lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
lirc_dev: lirc_register_plugin: sample_rate: 10
[] init_module+0x48/0x50 [lirc_pvr150]
I’m pretty new to the linux stuff, so if there’s a no-brainer step in your instructions (do I need to do anything beyond adding the .bin to the directory? since I’m running a mythbuntu install, do I need to somehow remove the old version of lirc, or did it just get stepped upon?), I may have missed it.
Any ideas?
– Dan
> (Dan)
> Sorry if this is a double comment – my last one didn’t seem to go through.
Only got it once!
> Firstly, thanks for the effort you’ve put in to this.
Cheers!
> lirc_i2c: chip 0×10020 found @ 0×71 (Hauppauge PVR150)
You are loading the wrong module, you need lirc_pvr150. Probably you have a
distribution package installed, if so uninstall it first. Otherwise a simple
killall lircd && rmmod lirc_i2c && modprobe lirc_pvr150
should get the right module loaded.
> (Jeff)
>…have a Scientific Atlanta Explorer 3100 that doesn’t seem to respond
> to any of the codes provided (0_78 is the codeset for this box, but
> i’ve also run send_power_new).
check if it’s actually on the transmitter (use a torch, see the instructions above).
Other than that if it doesn’t respond, and the LED is blinking when you send stuff,
then I guess you must be sending it the wrong thing. It should certainly be possible
to get it to work with a serial IR blaster (since you can basically send anything).
> (truekaiser)
> not asking for a newer firmware.
> I want to know what is the date of the driver you pulled the above firmware from?
Not sure, sorry. It was last updated on 2007-09-27, if there is a newer release from hauppauge
then I am happy to update it. (I don’t really look unless someone prods me).
Mark,
I know I’ve said it before, but you really do rock with all this! 🙂 That said, I’m hoping you can help.
I recently had everything working fine in a box running Gutsy (7.10) and then I’ve had to move to a new box. Now, for some reason, I can’t get it to work! Any thoughts? Specifically, I’ve tried installing mythbuntu (and then uninstalling it), and I’ve installed ivtv 1.03 and followed your instructions to the letter. I usually get as far as running irw and it all looks good, but when I run the blaster script it says “hardware does not support sending”. So, I uninstall any lirc packages I can see, then run your killmod command and it comes back saying irw can’t work because “connect: No such file or directory”. When I reboot and try again, irw doesn’t let me run and the send_power_new returns “irsend: could not connect to socket” and “irsend: Connection refused”.
Help?!?!
You probably have lirc_i2c loaded, check dmesg/syslog.
Nope – it wasn’t loaded.
So, here’s where I’m at. I’ve removed any myth related packages and rebooted my machine. I then started to follow your steps from the top. So, I went into the /usr/src/lirc… directory and re-ran setup.sh. I then ran make and make install and it seemed to go fine. Then I put in ‘modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1’ and it didn’t return to the prompt – it just sat there (kinda like irw used to when it worked).
So, I Ctrl+C but that wouldn’t quit it! I opened another terminal and killed the process and typed dmesg. The last line in the dmesg output is:
“[ 284.272776] lirc_pvr150: chip found with RX and TX
It goes no further than that.
?!?
Fixed it! There is a documented bug in Gutsy – http://ubuntuforums.org/showthread.php?t=587732 for the fix!
Hi Marc,
I have just upgraded your pre-patched lirc 0.8.3-CVS-pvr150-2 version for my Sidux BOX with this kernel:
2.6.24-2.6.24.3.slh.8-sidux-686
this kernel includes the ivtv driver, works ok for mythtv.
In previous version everything was ok. I put my previous files on /etc/lircd.conf and ~/mythtv/.mythtv/lircrc
Now only ir-blaster is working to change channels in mythtv. It seems irw does not receive signals from remote control (no messages).
When driver is loading I received the following info (dmesg) additional to your Howto,
Thanks for your help or ideas. Francisco
lirc_dev: IR Remote Control driver registered, 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
lirc_dev: lirc_register_plugin: sample_rate: 0
lirc_pvr150: firmware of size 302355 loaded
lirc_pvr150: 743 codesets loaded
lirc_pvr150: 01 60 00 01 5blirc_pvr150: 05 02 04 4b 1alirc_pvr150: 09 79 88 b1 1flirc_pvr150: 0d 87 f5 16 61lirc_pvr150: 11 a6 d9 ec 9alirc_pvr150: 15 0f a7 ab 27lirc_pvr150: 19 48 9d 7e 1alirc_pvr150: 1d d9 0c 0e 48lirc_pvr150: 21 91 77 d6 3dlirc_pvr150: 25 09 44 18 60lirc_pvr150: 29 e5 12 c6 6clirc_pvr150: 2d ba 32 c4 26lirc_pvr150: 31 e3 76 01 48lirc_pvr150: 35 a2 7d 81 59lirc_pvr150: 39 90 28 8f 48lirc_pvr150: 3d 79 61 b4 0alirc_pvr150: 41 0b 57 21 6elirc_pvr150: 45 00 78 ad 62lirc_pvr150: 49 b5 68 a2 27lirc_pvr150: 4d 42 4e da 6clirc_pvr150: 51 94 63 0e 2alirc_pvr150: 55 1a 30 3b 45lirc_pvr150: 59 fa 34 25 e5lirc_pvr150: 5d cb 1e c1 eelirc_pvr150: 61 00 00 00 eelirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
lirc_pvr150: poll called
lirc_pvr150: poll result = 0
lirc_pvr150: 01 60 79 29 d9lirc_pvr150: 05 ea 0e 48 91lirc_pvr150: 09 77 d6 3d 09lirc_pvr150: 0d 44 18 60 f5lirc_pvr150: 11 03 c1 5f bblirc_pvr150: 15 fe c7 bf edlirc_pvr150: 19 10 01 48 a2lirc_pvr150: 1d 7d 81 59 90lirc_pvr150: 21 28 0d 48 68lirc_pvr150: 25 13 c6 78 7alirc_pvr150: 29 26 53 1c 71lirc_pvr150: 2d 09 dc 10 c7lirc_pvr150: 31 19 d3 56 30lirc_pvr150: 35 3c ab 1d e6lirc_pvr150: 39 11 7c 5b 69lirc_pvr150: 3d f0 b8 ba 05lirc_pvr150: 41 cb 81 e5 26lirc_pvr150: 45 f3 f1 b7 6elirc_pvr150: 49 88 29 c2 f6lirc_pvr150: 4d bb e7 9f 1alirc_pvr150: 51 ed 39 93 45lirc_pvr150: 55 cd 3b d9 1clirc_pvr150: 59 89 fe b7 5dlirc_pvr150: 5d 82 7e 64 0elirc_pvr150: 61 00 00 00 0elirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 1)
lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 2)
lirc_pvr150: NAK expected: i2c_master_send failed with -121 (try 3)
First off, I appreciate your work on this. I’ve been using it for a few years now.
I’ve just recently ran into a problem with my latest rebuild of my Myth box. The problem is that I have to restart lircd several times for it to work. I’m not sure if this is a timing thing or what, but I initially start lircd using /etc/rc.local with the following commands:
#Reset ivtv ir
#I have to do this with the latest build, or /etc/lircd.conf doesn’t get loaded
/usr/local/bin/ivtvctl –reset-ir
#Start lirc and fix permissions
if [ ! -c /dev/lirc0 ]; then
mknod /dev/lirc0 c 61 0
chmod a+rw /dev/lirc*
fi
modprobe lirc_dev && modprobe lirc_pvr150
lircd –device=/dev/lirc1
#For some reason I have to kill and restart lircd — not sure why
kill -9 `cat /var/run/lircd.pid`
lircd –device=/dev/lirc1
In the script I use to automatically start mythfrontend I also kill and restart lircd. Unfortunately, I have to run the script 2x before the remote will start responding. So, basically, the 3rd time is the charm.
The logs don’t say anything different when the remote works, and when it doesn’t. I can post some logs if necessary, but I didn’t want to clutter things up.
Does anyone else have to load lircd multiple times before the remote will respond? Do I need to let something finish loading before starting lircd? Any suggestions would be appreciate as I’m not really sure where to go from here.
I am running Fedora 8 x86_64 on 2.6.23.15-137.fc8
Thanks,
Dave