Hauppauge HVR-1600 Remote Not Detected

Bug #454371 reported by bsntech on 2009-10-18
This bug affects 17 people
Affects Status Importance Assigned to Milestone
linux-lts-utopic (Ubuntu)
Nominated for Jaunty by rp_linux
Nominated for Karmic by rp_linux

Bug Description

Binary package hint: lirc

Running Ubuntu Karmic 9.10 64-bit.

LIRC will not find the Hauppauage HVR-1600 remote. The same procedure below was performed on Ubuntu 9.04 Jaunty and the remote just worked:

sudo apt-get install lirc

After the install, it will configure. I choose Hauppauge TV Card and I do not use an IR Transmitter.

Using irw, it would show that the commands were found.

/dev/lirc0 is not even created. It seems that the previously used module (lirc_i2c) no longer is finding the card as it did previously.

ProblemType: Bug
Architecture: amd64
Date: Sat Oct 17 21:38:39 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: lirc 0.8.6-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: lirc
Uname: Linux 2.6.31-14-generic x86_64

bsntech (spraker) wrote :
bsntech (spraker) wrote :

I also just updated my Ubuntu 9.04 Jaunty 32-bit Dell PC to Ubuntu 9.10 Karmic 32-bit and the same thing has happened.

There is a Hauppauge WINTV-Go Plus card in this computer that also has the same exact remote and IR receiver/transmitter cable.

After the upgrade this evening, the remote no longer works on this model of the Hauppauge card as well.

The PC no longer detects the transmitter/receiver and does not create the /dev/lirc0 file.

bsntech (spraker) wrote :

I opted to re-insert the old Hauppauge PVR-150 card into the computer one PCI slot above the Hauppauage HVR-1600.

I then put the transmitter/IR cable into the IR port on the PVR-150 and then turned the PC on.

After doing so, Ubuntu/LIRC found the PVR-150 remote was attached and the remote is now working. However, the question is - why are both the HVR-1600 and the WinTV-Go Plus IR/Transmitters no longer being detected or working?

Log of dmesg | grep "lirc" after putting in the PVR-150:

[ 13.477963] lirc_dev: IR Remote Control driver registered, major 61
[ 13.824620] lirc_i2c: chip 0x10020 found @ 0x71 (Hauppauge PVR150)
[ 13.824623] lirc_dev: lirc_register_driver: sample_rate: 10

This is not really a workaround for those who do not have a PVR-150. At least I have my main HTPC box up and going with the remote again, unfortunately with an extra tuner card I didn't want to put back in. And, then the HTPC box in the master bedroom no longer works with the remote - this is the one with the Hauppauge WinTV-Go Plus card in it.

bsntech (spraker) wrote :
Download full text (4.4 KiB)

More data from the Messages log that shows the HVR-1600 does have an IR transmitter/receiver:

Oct 19 09:09:28 HTPC kernel: [ 12.512468] cx18-0: Initializing card 0
Oct 19 09:09:28 HTPC kernel: [ 12.512472] cx18-0: Autodetected Hauppauge card
Oct 19 09:09:28 HTPC kernel: [ 12.513014] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 18
Oct 19 09:09:28 HTPC kernel: [ 12.513019] cx18 0000:01:05.0: PCI INT A -> Link[LNKB] -> GSI 18 (level, low) -> IRQ 18
Oct 19 09:09:28 HTPC kernel: [ 12.513028] cx18-0: Unreasonably low latency timer, setting to 64 (was 32)
Oct 19 09:09:28 HTPC kernel: [ 12.513829] cx18-0: cx23418 revision 01010000 (B)
Oct 19 09:09:28 HTPC kernel: [ 12.731474] tveeprom 2-0050: Hauppauge model 74021, rev C1B2, serial# 1570928
Oct 19 09:09:28 HTPC kernel: [ 12.731479] tveeprom 2-0050: MAC address is 00-0D-FE-17-F8-70
Oct 19 09:09:28 HTPC kernel: [ 12.731481] tveeprom 2-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
Oct 19 09:09:28 HTPC kernel: [ 12.731484] tveeprom 2-0050: TV standards NTSC(M) (eeprom 0x08)
Oct 19 09:09:28 HTPC kernel: [ 12.731486] tveeprom 2-0050: audio processor is CX23418 (idx 38)
Oct 19 09:09:28 HTPC kernel: [ 12.731489] tveeprom 2-0050: decoder processor is CX23418 (idx 31)
Oct 19 09:09:28 HTPC kernel: [ 12.731491] tveeprom 2-0050: has no radio, has IR receiver, has IR transmitter
Oct 19 09:09:28 HTPC kernel: [ 12.731493] cx18-0: Autodetected Hauppauge HVR-1600
Oct 19 09:09:28 HTPC kernel: [ 12.731495] cx18-0: Simultaneous Digital and Analog TV capture supported
Oct 19 09:09:28 HTPC kernel: [ 12.815138] IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
Oct 19 09:09:28 HTPC kernel: [ 12.819239] tuner 3-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
Oct 19 09:09:28 HTPC kernel: [ 12.878642] cs5345 2-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
Oct 19 09:09:28 HTPC kernel: [ 12.880751] tuner-simple 3-0061: creating new instance
Oct 19 09:09:28 HTPC kernel: [ 12.880753] tuner-simple 3-0061: type set to 50 (TCL 2002N)
Oct 19 09:09:28 HTPC kernel: [ 12.881847] cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB)
Oct 19 09:09:28 HTPC kernel: [ 12.881850] DVB: registering new adapter (cx18)
Oct 19 09:09:28 HTPC kernel: [ 12.882200] HDA Intel 0000:00:07.0: power state changed by ACPI to D0
Oct 19 09:09:28 HTPC kernel: [ 12.882575] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 21
Oct 19 09:09:28 HTPC kernel: [ 12.882580] HDA Intel 0000:00:07.0: PCI INT A -> Link[LAZA] -> GSI 21 (level, low) -> IRQ 21
Oct 19 09:09:28 HTPC kernel: [ 13.166082] MXL5005S: Attached at address 0x63
Oct 19 09:09:28 HTPC kernel: [ 13.166088] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
Oct 19 09:09:28 HTPC kernel: [ 13.166167] cx18-0: DVB Frontend registered
Oct 19 09:09:28 HTPC kernel: [ 13.166169] cx18-0: Registered DVB adapter0 for TS (32 x 32 kB)
Oct 19 09:09:28 HTPC kernel: [ 13.166196] cx18-0: Registered device video33 for encoder YUV (16 x 128 kB)
Oct 19 09:09:28 HTPC kernel: [ 13.166216] cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes)
Oct 19 09:09:28 HTPC kernel: [ 13.166234] cx18-0: Registered...


Jeremy Yoder (jyoder) wrote :

This appears to be a problem with the 2.6.31 kernel drivers.

From Jaron Wilson on the LIRC mailing list:
The root of the problem is that the i2c client model changed significantly
in 2.6.31, and some drivers (such as the cx18 driver for the HVR-1600)
weren't updated soon enough for the 2.6.31 window, meaning even ir-kbd-
i2c is broken with them as well. What needs to happen is some
patchification of those drivers in a 2.6.31.x stable release, I think
(going to ping some v4l/dvb folks on that).

What we did on Dave's box is build the cx18 driver (well, all v4l-dvb
drivers) from v4l-dvb mercurial, and all was well again.

Short version:

hg clone http://linuxtv.org/hg/v4l-dvb
cd v4l-dvb
make install

If you get errors about some driver or another not building, if its
one you don't need, you can disable it from being built in v4l/
Makefile.media (the firedtv driver was failing on Dave's system for
some reason).

If you update your kernel to another that still doesn't have the
required i2c fixage in it, you'll lose the fixes from v4l-dvb, but can
get 'em back by going back into that v4l-dvb checkout and rebuilding
(after doing a 'make distclean' so the build uses the new kernel
headers instead of the prior one).

Jeremy Yoder (jyoder) on 2009-10-22
Changed in lirc (Ubuntu):
status: New → Confirmed
bsntech (spraker) wrote :

Thank you, Jeremy.

Will this also fix the issue with the WinTV-Go Plus card as well?

Any idea how long it may take for this update to be built into the next potential kernel release with Ubuntu?

bsntech (spraker) wrote :

Jeremy -

I couldn't figure out how to post back to the LIRC board, but I did the steps above and installed the most updated v4l-dvb drivers.

After rebooting, I still don't have IR/Transmitter access with HVR-1600 nor did it create a /dev/lircX folder.

resolost (resolost) wrote :

I am also having the same problem. I tried what Jeremy suggested, but still no luck. Does anyone else have a suggestion?

Indi Nix (indicium-nixor) wrote :
Download full text (3.5 KiB)

I've been screwing with this since lirc 0.8.4a became obseleted with > 2.2.28 kernel changes. I use a PVR-1600 which has been providing me with a fine new recreational activity that regularly replaces watching tv with fixing tv.

Don't get me wrong; tons and tons of fine work in all the ivtv,cx18 code, etc etc - It's been fun reading code/posts from Hans, Andy etc as my card went from entirely supported to functional in mainline kernel drivers.

I have fiddled with 0.8.6 release and cvs pulled the mercurial repo from v4l, remade any variety of modules and was generally stonewalled. I thought I was onto something with some very odd looking KERNEL_VERSION_IFDEFMADNESS in i2c_dev but it turns out I was just tired.

Helplessly googling instead of watching House I did come across a interesting read starting out with:

ir-kbd-i2c: Switch to the new-style device binding model 2009-04-04
-fascinating 3 way match between kernel maintainers, various v4l people and in an uninvolved/offhand way lirc.
-the only summary I can come up with is that there is great confusion and discussion on what style of standard can be applied to something as diverse as an i2c device, the failings and merits of various pre-existing schemas.
-abolishing i2c-dev, or ir-kbd-i2c or perhaps all of them seem to be opinioned as options.

Re: [RFC] Anticipating lirc breakage 2009-04-07
-a bit of the fallout discussed in this ominous looking post. I never really did find discussion around this on the sourceforge hosted lirc mailing list, but I have not the patience to wait for them..

Somewhere in the next 6 months a variety of other things happen; new kernels arrive and disappear with and without regressions between the deadly triumvirate of kernel/v4l/lirc. Turns out that i2c drivers are still all over the road, and again I stop watching TV.

Re: cx18 i2c changes for 2.6.31.x? 2009-10-20
 (http://<email address hidden>/msg10856.html)
-makes clear the necessity of a recent pull of v4l to get the cx18 cards working with ir-kbd-i2c

On a whim, I loaded ir-kbd-i2c today.

Nov 3 21:10:45 indulgent kernel: [ ] input: i2c IR (CX23418 Z8F0811 Hauppau as /devices/virtual/input/input7
Nov 3 21:10:45 indulgent kernel: [ ] ir-kbd-i2c: i2c IR (CX23418 Z8F0811 Hauppau detected at i2c-0/0-0071/ir0 [cx18 i2c driver #0-0]

Note that in one of the lengthy discussions about not breaking anything they decided to leave ir-kbd-i2c arranged such that nothing loads it.. but it loads.

Very interesting!

Quick like a fox, I recompiled lircd with the "Linux input layer (/dev/input/eventX)" selected.

sudo lircd -n --device=/dev/input/event7 --output=/var/run/lirc/lircd

lircd-0.8.6[]: lircd(devinput) ready, using /var/run/lirc/lircd
lircd-0.8.6[]: accepted new client on /var/run/lirc/lircd
lircd-0.8.6[]: initializing '/dev/input/event6'

Promising! With great zeal I dove into the corners of my computer room, searching for the long buried remote.

0000000080010161 00 Go HVR-1100

Go HVR-.. well, I do need to set this up (again).

I am tempted to as...


jim_charlton (charltn) wrote :
Download full text (3.2 KiB)

The comments above are rather cryptic to the novice (like me). It was a bit of a struggle to know exactly what to do to get this working. So here is a more detailed account of what I had to do to get my IR remote to work. Note... I am using a Hauppage PVR-1600 card and the grey topped remote.

Install the sources for lirc-0.8.6 in /usr/src/lirc-0.8.6. Install the kernel header files (sudo apt-get install linux-headers-$(uname -r)). I also installed the linux source files but I don't think it was necessary. I did not recompile the kernel at any time.

 Cd to the /usr/src/lirc-0.8.6 directory and run ./configure. For device, choose "other" and then "Linux Input Layer". Recompile everything with 'make'. Install with 'make install'.

 Install /etc/lirc/lircd.conf from http://lirc.sourceforge.net/remotes/devinput/lircd.conf.devinput. It is generic for the remote and using linux input layer. Remove any /etc/lircd.conf file. It should not be there.

Make sure that you have only one copy of lircd on your system ('updatedb' and 'locate lircd'). I found that there were copies in /usr/local/sbin and /usr/sbin with the newer one that was just compiled in /usr/local/sbin. Copy it over the one in /usr/sbin.

Edit /home/<yourusername>/.lircrc to put the new codes in lircd.conf into .lircrc.

If you reboot at this point, the ir_kbd_i2c driver will be loaded and connect the ir chip on the Hauppauge card to an event# in /dev/input/event#. You can figure out which event# by looking at /proc/bus/input/devices and looking for the device with NAME=i2c IR ...... You can hard code that device number into /etc/lirc/hardware.conf. But the number may change as you change other things so this is not a perfect solution.

Better is to do the following

Put file called 30-ir_event.rules with the line
KERNEL=="event[0-9]*", ATTRS{name}=="i2c IR *", SYMLINK+="input/hauppage"
(all on one line) into /etc/udev/rules.d. The ATTRS{name} variable can
be obtained by looking into /proc/bus/input/devices (in case you are using a different card). This udev rule will create a device entry (symlink) in /dev/input called hauppage that will always point to the proper event# in the same directory.

Now point your lircd at /dev/input/hauppage by putting it
into /etc/lirc/hardware.conf. Edit the lines given below.
REMOTE_LIRCD_ARGS="--device=/dev/input/hauppage --driver=dev/input"

At this point if you reboot you will find that 'lsmod' shows that the iir_kbd_i2c module is loaded and 'ps -ef | grep lircd' gives "root 953 1 0 18:04 ? 00:00:00 /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/input/hauppage" (on my machine) (all commands run as root).

This is (as best I can remember) what I did to get my remote to control mplayer (I put mplayer controls in .lircrc) and watch TV with 'mplayer /dev/video0'. I use a propriety program (you can get a copy by writing to me) to change channels but channels can al...


jim_charlton (charltn) wrote :

After a kernel upgrade came along on November 26, 2009, the lirc trick above using the ir_kbd_i2c module ceased to work. I no longer get a device (/dev/input/event#) on installing (modprobe) the ir_kbd_i2c module. I am still trying to figure out why.

jim_charlton (charltn) wrote :
Download full text (3.8 KiB)

November 26, 2009. I got an automatic upgrade and it killed the lirc remote. So I started trying to solve the problem. It seemed to be the ir_kbd_i2c module. Funny thing... the actual source code is for ir-kbd-i2c (notice the difference between _ and -). Apparently, modprobe does not distinguish these two symbols! In any event the module does not create the /dev/input/event# anymore and gives no indication as to why. I tried to recompile the lirc-0.8.6 package as it has the module but that led to no joy. So I got the v4l-dvb package http://linuxtv.org/hg/v4l-dvb/shortlog/9c38704cfd56 (cx18 package) and compiled it. I had to disable the compilation of the FireDTV module (see Multimedia->DVB/ATSC section of make menuconfig) as there were errors in compiling that module, and I did not need it anyway. Then I did a make install and a modprobe cx18... and everything started working again.

Here is the dmesg output.

[11901.657407] Linux video capture interface: v2.00
[11901.671872] cx18: Start initialization, version 1.3.0
[11901.672002] cx18-0: Initializing card 0
[11901.672007] cx18-0: Autodetected Hauppauge card
[11901.672114] cx18 0000:04:01.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[11901.673022] cx18-0: cx23418 revision 01010000 (B)
[11901.892198] tveeprom 3-0050: Hauppauge model 74041, rev C6B2, serial# 3335359
[11901.892203] tveeprom 3-0050: MAC address is 00-0D-FE-32-E4-BF
[11901.892206] tveeprom 3-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
[11901.892210] tveeprom 3-0050: TV standards NTSC(M) (eeprom 0x08)
[11901.892213] tveeprom 3-0050: audio processor is CX23418 (idx 38)
[11901.892216] tveeprom 3-0050: decoder processor is CX23418 (idx 31)
[11901.892220] tveeprom 3-0050: has no radio, has IR receiver, has IR transmitter
[11901.892223] cx18-0: Autodetected Hauppauge HVR-1600
[11901.892225] cx18-0: Simultaneous Digital and Analog TV capture supported
[11901.975333] IRQ 16/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
[11901.982107] tuner 4-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
[11901.984326] cs5345 3-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[11901.986529] input: i2c IR (Hauppauge HVR-1600) as /devices/virtual/input/input6
[11901.986588] ir-kbd-i2c: i2c IR (Hauppauge HVR-1600) detected at i2c-3/3-0071/ir0 [cx18 i2c driver #0-0]
[11901.995210] tuner-simple 4-0061: creating new instance
[11901.995214] tuner-simple 4-0061: type set to 50 (TCL 2002N)
[11902.450286] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
[11902.450292] DVB: registering new adapter (cx18)
[11902.491277] cx18 0000:04:01.0: firmware: requesting v4l-cx23418-cpu.fw
[11902.886829] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
[11902.912079] cx18 0000:04:01.0: firmware: requesting v4l-cx23418-apu.fw
[11903.017156] MXL5005S: Attached at address 0x63
[11903.017162] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
[11903.017248] cx18-0: DVB Frontend registered
[11903.017252] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
[11903.017286] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB)
[11903.017313] cx18-0: Registered device vbi0 for encoder VBI (...


Jeff Utter (jeffutter) wrote :

I can confirm that the cx18/ir_kbd_i2c driver update creates the /dev/input/event entry. And this partially works. Some keys on my remote work, the basic left/right/volume/numbers work. However the 'special' keys like the TV/Movies/etc do not. If i recall before i did not have my remote setup with devinput, before I had a /dev/lirc entry (I think) I'm not really sure what to do from here to trouble shoot this. Any Ideas?

jim_charlton (charltn) wrote :

I think that I can help you Jeff.... but, before doing that.... Today (December 5) I got another kernel update. This again broke cx18, and ir_kbd_i2c, as far as the Hauppauge 1600 PVR card is concerned. When I modprobed cx18, there were no /dev/videoxx entires and of course, modprobe ir_kbd_i2c did not generate any lirc devices either since the TV card was not installed. I again recompiled the modules from http://linuxtv.org/hg/v4l-dvb/shortlog/9c38704cfd56 (cx18 package).
I did a... make release, make clean, make install, make unload, modprobe cx18, modprobe ir_kbd_i2c, /etc/init.d/lirc start, /etc/init.d/irexec.sh start ... and everything works again.

Jeff: What program are you controlling with the remote? You may have to edit /home/<user>/.lircrc with new "button" values. You get the button key codes from running irw.

Jeff Utter (jeffutter) wrote :

I am trying to use the remote with xbmc. I seem to get no output from irw at all. Which sort of confuses me because the remote still has some functionality. It seems like with this setup the remote is creating a /dev/input device that linux seems to think is a keyboard. Thus the 'keyboardy' keys work ike they would on a keyboard, but the special remote keys do not work at all. Now I admit that something might be wrong in my /etc/lirc/* config files, can you provide some info on how yours are setup.

jim_charlton (charltn) wrote :

Ahhhh. If you only `modprobe cx18` and `modprobe ir_kbd_i2c` then your remote will act like an infrared keyboard. irw will not work as it needs the lircd daemon running before it will work as an ir remote for other programs. So I suspect that you have the correct modules loaded but... you do not have lircd running). Try `ps -ef | grep lirc` to see if it is running. If not (and probably even if it is running), you need to follow the instructions in message 10 above to compile and install lircd for the use of /dev/input/event# input. There are detailed instructions there for the required /etc/lirc/hardware.conf, /etc/lirc/lircd.conf and /home/<userid>/.lircrc files.

Just for fun I removed my compiled version of lircd and installed the current lirc package (apt-get remove lirc and then apt-get install lirc). This installs the 0.8.6 lirc... BUT... it is not the one that is needed for use of the remote with the Haupauge 1600 card as described in message 10 above.

When you have the proper lircd compile, installed and launched by rebooting (or executing `/etc/init.d/lirc start`) then you will get the keycodes when you run irw. And if you run irexec as a daemon you can direct translated keycodes to specific programs to get the effects that you want.

Frank Rizzo (francisarizzo) wrote :
Download full text (3.3 KiB)

I have the Hauppauge HVR-1600 (1199) card with the grey remote (A415-HPG-A), and I have spent the last few days trying everything to make my remote work, but so far no results. I do not have any problems using the card to watch TV using the cx18 driver that comes with Mythbuntu 9.10 or any new cx18 drivers that I compile. The only problem that I have is loading the new ir-kbd-i2c module and getting the remote to work (it always gets "killed").

I'm running a fresh install of Mythbuntu 9.10, with all of the available updates (including kernel 2.6.31-17-generic). I have tried using these methods with the 2.6.31-14 packages, and they did not work. I have also tried using these methods with the updated 2.6.31-17 packages, and they also did not work.

I tried the following solutions for making the remote work, but they also did not work:
- http://www.uluga.ubuntuforums.org/showpost.php?p=8257616&postcount=27 (ir-kbd-i2c is "killed")
- http://rtr.ca/hvr1600/ (compilation errors)

I've followed the instructions from posts #12, #14 and #16 above, and I'm able to compile and install the LIRC 0.8.6 and V4L-DVB packages, but I cannot load the ir-kbd-i2c modules into memory after I reboot. I always get a "killed" message after the modprobe, and related messages printed to the kernel buffer (dmesg). For example:

frank@desktop:~$ sudo modprobe ir-kbd-i2c

frank@desktop:~$ dmesg
[ 186.577886] Creating IR device irrcv0
[ 186.577899] BUG: unable to handle kernel paging request at 72727563
[ 186.577905] IP: [<c0318b52>] strcmp+0x12/0x30
[ 186.577916] *pde = 00000000
[ 186.577920] Oops: 0000 [#1] SMP
[ 186.577923] last sysfs file: /sys/module/ir_common/initstate
[ 186.577927] Modules linked in: ir_kbd_i2c(+) mxl5005s s5h1409 tuner_simple tuner_types cs5345 tuner snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi cx18 snd_rawmidi snd_seq_midi_event snd_seq snd_timer iptable_filter snd_seq_device dvb_core i2c_algo_bit cx2341x ip_tables snd v4l2_common x_tables soundcore snd_page_alloc videodev v4l1_compat ir_common ir_core ppdev dell_wmi tveeprom psmouse dcdbas serio_raw parport_pc lp parport usb_storage usbhid tg3 floppy intel_agp agpgart
[ 186.577973]
[ 186.577977] Pid: 2036, comm: modprobe Not tainted (2.6.31-17-generic #54-Ubuntu) OptiPlex GX280
[ 186.577981] EIP: 0060:[<c0318b52>] EFLAGS: 00210292 CPU: 0
[ 186.577984] EIP is at strcmp+0x12/0x30
[ 186.577987] EAX: c06e2d75 EBX: f6978de0 ECX: c023a3c0 EDX: 72727563

From what I understand, this card's remote control is not yet supported by the LIRC i2c device (/dev/lirc), but it should work with the LIRC keyboard input layer device (/dev/input/eventX) as described by Indi Nix (message # 9) and jim_charlton (messages # 10, 12, 14 and 16). Indi.N also describes this in:

Getting the remote to work with this card has been more aggravating than I imagined. I'm almost tempted to build my own LIRC-compatible IR receiver and forget about using the IR receiver that came with the HVR-1600 card.

Can someone please point me in ...


rp_linux (mail2ramkumar) wrote :

I have the Hauppauge HVR-1600 card with the grey remote (A415-HPG-A) and have also been trying to get it working, without any success so far. I have a mythbuntu 9.10.

$ uname -r

After reading this posting, I updated the cx18 drivers (using Jeremy Yoder's post #5). Checking dmesg output looks like the tuner is functional except for the remote. Able to see live video in myth also.

However there is no /dev/lircd0 created, buttons do not get recognized in irw. Since others have gotten it to work earlier, Iam guessing it is something wrong in my setup.

I installed lirc using apt-get, not by compiling from source.
$ sudo apt-get install lirc mythbuntu-lirc-generator lirc-x

Is this ok or do I need to compile and install lirc from source?

My dmesg for lirc
$ dmesg | grep lir
[ 23.347623] lirc_dev: IR Remote Control driver registered, major 61

I don't know if my /etc/lirc/hardware.conf has any issues as I pieced it from reading several postings online.

$ cat /etc/lirc/hardware.conf
REMOTE="Hauppauge TV card"
REMOTE_MODULES="lirc_dev lirc_i2c"

I checked the logs for any known issues in v4l-db mercurial drivers, don't see any issues for 2.6.31* kernel.

I don't have a working hardware.conf to verify against, hoping I have something wrong in that and someone can point it to me. appreciate if someone can post their working hardware.conf.

Please help!

rp_linux (mail2ramkumar) wrote :

Som additional info for my post #18 on lirc settings. lirc version is 0.8.6

$ ps -ef | grep lirc
root 1234 1 0 01:10 ? 00:00:00 /usr/sbin/lircd --output=/var/run/lirc/lircd --device=/dev/lirc0

$ lsmod | grep ir
lirc_i2c 7136 0
lirc_dev 10804 1 lirc_i2c
ir_common 47868 4 cx88xx,ivtv,bttv,cx18
ir_core 7336 3 cx88xx,bttv,ir_common

It appears like this bug affects Lucid Lynx as well

Kevin Worth (kworth) wrote :

Updated from 9.04 to 9.10 and then to 10.04 today. Found that in both newer releases my remote stopped working. Once I made it to 10.04, I looked around and found this thread. Things look like they go back pretty far, so perhaps things are in a better shape today, as I was able to get mine working with no need for special builds.

My current kernel:
# uname -r
(System was brought up-to-date today)

My old config (that worked on 9.04 and before):
# /etc/lirc/hardware.conf
#Chosen Remote Control
REMOTE_MODULES="lirc_dev lirc_i2c"

My new config (that works now on 10.04)
# /etc/lirc/hardware.conf
#Chosen Remote Control
REMOTE="Hauppauge TV card"
REMOTE_MODULES="ir_kbd_i2c lirc_dev lirc_i2c"

dmesg output that let me know ir_kbd_i2c was looking good:
[ 1257.753138] input: i2c IR (CX23418 Z8F0811 Hauppau as /devices/virtual/input/input6
[ 1257.753306] ir-kbd-i2c: i2c IR (CX23418 Z8F0811 Hauppau detected at i2c-0/0-0071/ir0 [cx18 i2c driver #0-0]

Found which /dev/intput/event* device it was by looking at /proc/bus/input/devices
I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="i2c IR (CX23418 Z8F0811 Hauppau"
P: Phys=i2c-0/0-0071/ir0
S: Sysfs=/devices/virtual/input/input6
U: Uniq=
H: Handlers=kbd event4
B: EV=100003
B: KEY=100fc312 214a802 0 0 0 0 18000 41a8 4801 9e1680 0 0 10000ffc

Fired up irw and tested a few events
000000008001018f 00 green HVR-1100
000000008001018f 01 green HVR-1100
000000008001018f 02 green HVR-1100
00000000800100ae 00 Back/edit HVR-1100

I think the codes for some things may have changed, as I believe previously the codes were recognized as a PVR-350 (also note the typo "Back/edit" not "Back/exit"). So it may require a little editing/regeneration of key config and bindings, but overall things look good.

Peter Whalley (pwhalley) wrote :
Download full text (12.8 KiB)

Hello all,

I hope someone here can give me some guidance.

I am using the HVR-1600 and am trying to get the Ir functions - both ways - working.

I have Ubuntu 10.4 - 2.6.32-21-generic (#32-Ubuntu SMP Fri Apr 16 08:10:02 UTC 2010) - installed. Myth is up to date and I think I have newest V4L / CX18 installed and working (mostly). I can simultaneously record one 1080i ATSC stream and one NTSC using the SV1 with acceptable results.

I can't figure out what I should do to get both (most important is send - to control a Directv receiver) working on the backend machine.

This is dmesg output if it helps:

[ 26.612877] cx18: Start initialization, version 1.4.0
[ 26.612937] cx18-0: Initializing card 0
[ 26.612941] cx18-0: Autodetected Hauppauge card
[ 26.623812] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[ 26.623820] alloc irq_desc for 18 on node -1
[ 26.623822] alloc kstat_irqs on node -1
[ 26.623832] cx18 0000:02:06.0: PCI INT A -> Link[APC3] -> GSI 18 (level, low) -> IRQ 18
[ 26.623842] cx18-0: Unreasonably low latency timer, setting to 64 (was 32)
[ 26.625857] cx18-0: cx23418 revision 01010000 (B)
[ 26.857725] tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 931126
[ 26.857730] tveeprom 4-0050: MAC address is 00:0d:fe:0e:35:36
[ 26.857733] tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
[ 26.857737] tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08)
[ 26.857740] tveeprom 4-0050: audio processor is CX23418 (idx 38)
[ 26.857743] tveeprom 4-0050: decoder processor is CX23418 (idx 31)
[ 26.857745] tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter
[ 26.857748] cx18-0: Autodetected Hauppauge HVR-1600
[ 26.857751] cx18-0: Simultaneous Digital and Analog TV capture supported
[ 26.961118] IRQ 18/cx18-0: IRQF_DISABLED is not guaranteed on shared IRQs
[ 27.099066] tuner 5-0061: chip found @ 0xc2 (cx18 i2c driver #0-1)
[ 27.257366] cs5345 4-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[ 27.312638] Installing knfsd (copyright (C) 1996 <email address hidden>).
[ 27.411675] tuner-simple 5-0061: creating new instance
[ 27.411681] tuner-simple 5-0061: type set to 50 (TCL 2002N)
[ 27.413415] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
[ 27.413419] DVB: registering new adapter (cx18)
[ 27.815684] ACPI: PCI Interrupt Link [APCJ] enabled at IRQ 20
[ 27.815691] Intel ICH 0000:00:06.0: PCI INT A -> Link[APCJ] -> GSI 20 (level, high) -> IRQ 20
[ 27.815740] Intel ICH 0000:00:06.0: setting latency timer to 64
[ 27.891170] MXL5005S: Attached at address 0x63
[ 27.891178] DVB: registering adapter 0 frontend 0 (Samsung S5H1409 QAM/8VSB Frontend)...
[ 27.891351] cx18-0: DVB Frontend registered
[ 27.891355] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
[ 27.891392] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB)
[ 27.891423] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
[ 27.891454] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB)
[ 27.891458] cx18-0: Initialized card: Hauppauge HVR-1600
[ 27.891491] cx18: End initialization
[ 27.932652] cx18 0000:02...

Alec Leamas (leamas-alec) wrote :

Perhaps wrong kernel version, duuno. But it's the kernel, media susbsystem.

affects: lirc (Ubuntu) → linux-lts-utopic (Ubuntu)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers