[pvrusb2] HVR 1950 Transmitter

[Mike Isely]

Mike:

This is unfortunately consistent with my understanding in the past about 
getting the IR blaster working.  Unfortunately I'm not the subject 
matter expert on this.  Some comments interspersed below...

On Tue, 13 Oct 2009, Mike Ingardia wrote:

> Mike,
> Sorry for the delay in getting back to you but got pulled into various
> "work" activities that distracted me from working on this.
> 
> Here is where I am:
> After doing some reading I came across the following site:
> http://www.blushingpenguin.com/mark/blog/?p=24&cp=2
> 
> Which if I follow I get painfully close:
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.859129] lirc_pvr150: probe
> 0x70 @ pvrusb2_a: yes
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.859500] lirc_pvr150: probe
> 0x71 @ pvrusb2_a: yes
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.859502] lirc_pvr150: chip
> found with RX and TX
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.859565] lirc_pvr150: poll
> thread started
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.861279] lirc_dev:
> lirc_register_plugin: sample_rate: 0
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.861316] i2c ir driver 0-0070:
> firmware: requesting haup-ir-blaster.bin
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.888847] lirc_pvr150: firmware
> of size 302355 loaded
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.889184] lirc_pvr150: 743
> codesets loaded
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.889215] lirc_pvr150: 01 60 00
> 01 5b<7>lirc_pvr150: 05 02 04 4b 1a<7>lirc_pvr150: 09 79 88 b1
> 1f<7>lirc_pvr150: 0d 87 f5 16 61<7>lirc_pvr150: 11 a6 d9 ec
> 9a<7>lirc_pvr150: 15 0f a7 ab 27<7>lirc_pvr150: 19 48 9d 7e
> 1a<7>lirc_pvr150: 1d d9 0c 0e 48<7>lirc_pvr150: 21 91 77 d6
> 3d<7>lirc_pvr150: 25 09 44 18 60<7>lirc_pvr150: 29 e5 12 c6
> 6c<7>lirc_pvr150: 2d ba 32 c4 26<7>lirc_pvr150: 31 e3 76 01
> 48<7>lirc_pvr150: 35 a2 7d 81 59<7>lirc_pvr150: 39 90 28 8f
> 48<7>lirc_pvr150: 3d 79 61 b4 0a<7>lirc_pvr150: 41 0b 57 21
> 6e<7>lirc_pvr150: 45 00 78 ad 62<7>lirc_pvr150: 49 b5 68 a2
> 27<7>lirc_pvr150: 4d 42 4e da 6c<7>lirc_pvr150: 51 94 63 0e
> 2a<7>lirc_pvr150: 55 1a 30 3b 45<7>lirc_pvr150: 59 fa 34 25
> e5<7>lirc_pvr150: 5d cb 1e c1 ee<7>lirc_pvr150: 61 00 00 00
> ee<3>lirc_pvr150: i2c_master_send failed with -5
> Oct  6 14:00:14 amd-linuxmce64 kernel: [  931.911775] lirc_pvr150: poll
> thread ended
> 
> Now inorder to load the lirc_pvr150 I had to use the firmware referenced in
> the site and I suspect that the firmware is either wrong or some how for
> what ever reason causing a problem.  Using the i2c module I can get the
> remote control to work just fine but the transmitter is non-existent, and
> from various posts I have concluded that the i2c module with *ir*-kbd-i2c
> creates the approate devices but the ir transmitter part simply does not
> work.

The ir-kbd-i2c driver (part of v4l-dvb) is a receive-only driver.  It 
doesn't know how to send.  Lirc is much better in terms of features.  

One thing I have heard is that in order for the IR blaster to work, 
firmware must be loaded to it.  I know essentially *nothing* about that 
firmware except that it's totally up to the LIRC driver to deal with it.  
I also understand that unlike the other firmware situations with the 
HVR-1950 - where we can just use the vendor-supplied firmware - in this 
cause the LIRC driver has its "own" firmware that must be loaded.  It's 
entirely possible that there might be aspects of the HVR-1950 that 
impacts whatever firmware it is loading.  Again, realize I'm not the 
subject matter expert here.


> 
> This leads me down two paths, one trying to build the latest pvrusb2 driver
> on ubuntu 9.04 ( the system I have ) and 2 trying to see if I can get the
> lirc_pvr150 module to actually work since it seems to have the right code to
> drive the IR Blaster.

The pvrusb2 driver should not have anything to do with this, i.e. it 
won't matter what the pvrusb2 driver does so long as it has established 
a communications path for the lirc driver.  If you are running a 2.6.30 
or later kernel or using a v4l-dvb snapshot, you will however need that 
IR_SCHEME patch that was posted to the list earlier today - it is part 
of the setup of the communications path...


> 
> Question one:  Mike any insight on why the lirc_pvr150 module would bomb out
> on me?  Is there a way to capture the "right" firmware for the ir blaster
> from the device?

Unfortunately I really have no idea here :-(  I think in the end this is 
going to require interaction with the LIRC community and whoever is 
working on the pvr150 driver.  I suspect that a firmware capture is not 
going to be the solution based on what I've heard in the past about that 
driver.


> 
> Question two:  Building help on ubuntu:
> 
> When I look under:/lib/modules/2.6.28-15-generic I don't see a source
> directory.
> 
> michael at amd-linuxmce:~/extract$ ls /lib/modules/2.6.28-15-generic/
> build              modules.ccwmap       modules.ofmap        modules.usbmap
> initrd             modules.dep          modules.order        updates
> kernel             modules.dep.bin      modules.pcimap       volatile
> misc               modules.ieee1394map  modules.seriomap
> modules.alias      modules.inputmap     modules.symbols
> modules.alias.bin  modules.isapnpmap    modules.symbols.bin
> 
> 
> Attempting to build with out setting any of the environment variables yields
> the following error:
> michael at amd-linuxmce:~/extract/pvrusb2-mci-20091011$ make --directory driver
> make: Entering directory `/home/michael/extract/pvrusb2-mci-20091011/driver'
> make INSTALL_MOD_DIR=pvrusb2 -C /lib/modules/2.6.28-15-generic/build
> M=/home/michael/extract/pvrusb2-mci-20091011/driver CONFIG_VIDEO_PVRUSB2=m
> CONFIG_VIDEO_PVRUSB2_24XXX=y CONFIG_VIDEO_PVRUSB2_SYSFS=y
> CONFIG_VIDEO_PVRUSB2_DVB=y CONFIG_VIDEO_PVRUSB2_DEBUGIFC=y
> CONFIG_VIDEO_ADV_DEBUG=y modules
> make[1]: Entering directory `/usr/src/linux-headers-2.6.28-15-generic'
>   CC [M]
> /home/michael/extract/pvrusb2-mci-20091011/driver/pvrusb2-devattr.o
> /home/michael/extract/pvrusb2-mci-20091011/driver/pvrusb2-devattr.c:42:22:
> error: tda18271.h: No such file or directory
> /home/michael/extract/pvrusb2-mci-20091011/driver/pvrusb2-devattr.c:43:21:
> error: tda8290.h: No such file or directory
> 
> Searching for the missing file yields:
> michael at amd-linuxmce:~/extract/pvrusb2-mci-20091011$ locate tda18271.h
> /usr/src/linux-headers-2.6.28-11-generic/include/config/media/tuner/tda18271.h
> /usr/src/linux-headers-2.6.28-13-generic/include/config/media/tuner/tda18271.h
> /usr/src/linux-headers-2.6.28-14-generic/include/config/media/tuner/tda18271.h
> /usr/src/linux-headers-2.6.28-15-generic/include/config/media/tuner/tda18271.h
> /usr/src/v4l-dvb/.hg/store/data/linux/drivers/media/common/tuners/tda18271.h.i
> /usr/src/v4l-dvb/.hg/store/data/linux/drivers/media/dvb/frontends/tda18271.h.i
> /usr/src/v4l-dvb/linux/drivers/media/common/tuners/tda18271.h
> /usr/src/v4l-dvb/v4l/tda18271.h
> michael at amd-linuxmce:~/extract/pvrusb2-mci-20091011$
> 
> Suggestions on the *right* settings for the environment variables?

The key thing to do when building the driver is for the Makefile to find 
the top of your kernel source tree.  The Makefile doesn't actually 
require a specific place for that root - you can just tell it.  That's 
what I do here.  Since I'm compiling against lots of kernel variants 
here, I have a directory that is just simply a collection of kernel 
trees.  To build I set KDIR to point to the tree I want to build 
against.  That should ALWAYS work.

Now with that said, if you don't set KDIR, the Makefile might try a 
guess or two.  Looks like from what you have above that it is guessing 
correctly.  So what else might be going wrong...  Well it's interesting 
that you can't find tda18271.h, because that is a header needed when DVB 
is in the picture - which it will be if you are building the standalone 
driver and you are using a late enough kernel.  Probably the build 
process is configuring in DVB support for you but it might not have been 
configured in the distro kernel.  Actually I'd find that very surprising 
but I think it's happened to others.  Your distro kernel tree should 
have a .config file sitting there - examine it for evidence of whether 
or not DVB had been enabled.

  -Mike