Jan
15
Filed Under (Random) by mark on 15-01-2006

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

  1. 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.
  2. 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_.
  3. 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)
  4. 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).
  5. 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 configure

    then:

    make && make install.

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

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

    This means that the driver has detected and initialised the IR blaster hardware — if you don’t see that then let me know.

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

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

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

  12. 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).
  13. 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.
  14. 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


366 Responses to “LIRC PVR-150 IR blaster support, version 3”

Pages: « 1 2 [3] 4 5 6 7 8 » Show All

  1. 101
    Chris Says:

    Thanks Raghu, that worked perfectly. I was getting the same problem, lirc_pvr150 not creating the device (ivtv 0.7.0, kernel 2.6.17). All good now!

    And thanks Mark for the great guide and patches. Now that my remote is once again operational, the next step is to teach it what to do with my el cheapo STB ;).

  2. 102
    Noah Says:

    Hello. I have a PVR-150 that worked no problem in an older machine with KnoppMyth R5C7.

    I have upgraded to a shuttle with an nforce board. The remote no longer functions. I receive: lirc_pvr150: ivtv i2c driver #0: no devices found

    I have tried the original lirc (which worked before) and both packages listed in mark’s step #2. I have tried ivtvctl –reset-ir, cold booting and warm booting.

    Since it worked before, I have a feeling that it’s a hardware compatability with the new motherboard. Perhaps with the existing i2c SMBus(s)? Any suggestions on what can I do to further troubleshoot or fix the problem?

    Thanks much,

  3. 103
    mark Says:

    Try loading ivtv with newi2c=0 and see if that makes any difference. If not, run i2c-detect and post the output.

    Cheers,

    Mark

  4. 104
    Noah Says:

    Here ya go, mark, hopefully it’s readable:

    root@myth:~# rmmod lirc_pvr150
    root@myth:~# rmmod lirc_dev
    root@myth:~# rmmod ivtv
    root@myth:~# modprobe ivtv newi2c=0
    root@myth:~# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    root@myth:~# modprobe i2c-dev
    root@myth:~# i2cdetect
    Error: No i2c-bus specified!
    Syntax: i2cdetect [-f] [-q|-r] I2CBUS [FIRST LAST]
    I2CBUS is an integer
    With -f, scans all addresses (NOT RECOMMENDED)
    With -q, uses only quick write commands for probing (NOT RECOMMENDED)
    With -r, uses only read byte commands for probing (NOT RECOMMENDED)
    If provided, FIRST and LAST limit the probing range.
    i2cdetect -l lists installed busses only
    Installed I2C busses:
    i2c-2 unknown ivtv i2c driver #0 Algorithm unavailable
    i2c-1 unknown SMBus nForce2 adapter at 5100 Algorithm unavailable
    i2c-0 unknown SMBus nForce2 adapter at 5000 Algorithm unavailable
    root@myth:~# tail -f /var/log/syslog
    Jul 18 14:06:31 myth kernel: ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    Jul 18 14:06:31 myth kernel: tuner 2-0061: type set to 50 (TCL 2002N)
    Jul 18 14:06:31 myth kernel: ivtv0: Initialized WinTV PVR 150, card #0
    Jul 18 14:06:31 myth kernel: ivtv: ==================== END INIT IVTV ====================
    Jul 18 14:06:44 myth ntpd[4646]: frequency error -512 PPM exceeds tolerance 500 PPM
    Jul 18 14:06:45 myth kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 18 14:06:45 myth kernel: lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: no
    Jul 18 14:06:45 myth kernel: lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: no
    Jul 18 14:06:45 myth kernel: lirc_pvr150: ivtv i2c driver #0: no devices found
    Jul 18 14:07:05 myth kernel: i2c /dev entries driver

  5. 105
    Tim Schall Says:

    First off let me thank you for a very clear set of instructions that worked as they were supposed to and a piece of source code that compiled correctly. Now my problem.

    I’ve got a ‘whtie box’ computer with a Hauppauge PVR150 card. I’m using the stock IR receiver/emitter that came with the card and the stock remote. I’m using your prepatched source code. The system is running SuSE 10.0 with all updates installed and the latest version of MythTV. I’m attempting to control an external Samsung SIR-S300W DirecTV set top box. It works. Sort of. The code sets and ‘send_power now’ script indicate that I need to use the code set that appears around 1_373_. At least that’s the one that turns my receiver on and off. All I want to send is the numbers 0-9. Relevant part of the code set snipped here:

    name 1_373_KEY_0
    2171928576
    name 1_373_KEY_1
    2171928577
    name 1_373_KEY_2
    2171928578
    name 1_373_KEY_3
    2171928579
    name 1_373_KEY_4
    2171928580
    name 1_373_KEY_5
    2171928581
    name 1_373_KEY_6
    2171928582
    name 1_373_KEY_7
    2171928583
    name 1_373_KEY_8
    2171928584
    name 1_373_KEY_9
    2171928585

    Some of the numbers get sent correctly. Some do not. The receiver is consistant in its responses. I hacked up the lirc.conf.all file and came up with the following:

    name 0
    # 2171928576
    2171928583
    name 1
    # 2171928577
    2171928584
    name 2
    # 2171928578
    2171928577
    name 3
    # 2171928579
    2171928578
    name 4
    # 2171928580
    2171928579
    name 5
    2171928581
    name 6
    # 2171928582
    2171928580
    name 7
    # 2171928583
    2171928581
    name 8
    # 2171928584
    2171928582
    name 9
    2171928585

    Now, 0, 2, 3, 4, 6, 7, and 8 are all sent correctly. Using any of the channel_change scripts I’ve found and sending 1 or 5 produce no reaction from the receiver and 9 brings up the mini-guide. All of these behaivors are constant and repeatable. Using the receivers own, stock remote, produces very normal results from the receiver in all instances.

    Any thoughts on this one? I’d be glad to provide whatever info anyone would require to help resolve this.

    Tim Schall
    grover@fortgirlfriend.com

  6. 106
    raj Says:

    Hi mark,

    I can’t find /dev/lircd …it’s showing no such file or directory.
    What I have to do now.
    which driver I have to install and where could I find it?

    Thank you,

    Raj.

  7. 107
    Simon Baxter Says:

    I was using the lirc source at the top of this page, but it didn’t work with my 2.6.17 kernel. Grabbed the one above http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2

    and it works a treat!!

    A new query though. The key repeat strokes from the remote are staggered and a bit slow – especially when scrolling down long menus, or FF/REW tracking through a video clip. Is there any way to make this smoother? Or at least reduce the interval?

    Thanks!

  8. 108
    infringer Says:

    I can get the remote running but the script will not function and trying to test

    [root@localhost Desktop]# ./send_power_new
    bash: ./send_power_new: Permission denied

    its odd everytime I reboot it seems as if I have to recreate the lirc0 directory.

    It must not be working for some odd reason using ivtv 4.6 and lirc-0.8.0pre4-pvr150 and change_chan.pl for codeset for motorola DCT2244 the hardware is pvr-150 non mce…

    I know its all configured right because I do understand what is supposed to be happening

    oddly enough lircd doesnt show up in available services to start for my computer at boot

    anyways any help would be nice really

  9. 109
    infringer Says:

    by the way the remote works when I get it running flawlessly but, the irblaster fails miserably and I’m running mandriva 2006

  10. 110
    Russ Says:

    Mark,

    I am running KnoppMyth R5C7 and have not been able to get my PVR-150 irblaster working. My OVR-150 is the second of three tuner cards, the first and thir being a PVR-250. I have posted detailed findings at:

    http://mysettopbox.tv/phpBB2/viewtopic.php?t=10919

    It’s pretty long and in the interest of saving space I am posting the link rather than the entire contents here. (If you’re prefer that I post everything here please advise).

    Any of your insight to get me over the hump would be greatly appreciated!

    Best regards,
    Russ

  11. 111
    Russ Says:

    Mark/all,

    I got it working, there were two problems:

    1) when lirc_pvr150 is loaded, there is no need to specify /dev/lirc1 as it assigned the first card with an IR blaster (which was the second card in my system) as /dev/lirc.

    2) doing a make install of lirc-for-cecil.tar.bz2 placed the binaries in /usr/lical/sbin and /usr/local/bin, leaving the existing lirc binaries in /usr/sbin and /usr/bin. I renamed the old binaries and moved the new ones in their place and….

    VOILA the blaster LED now flashes and the remote works.

    Now for the next – fatal – problem:

    None of the send_power_new commands work on my Scientific Atlanta 4200. Turns out Hauppauge does not support this STB in their firmware, and I don’t believe there is any mechanism for adding unsupported codes.

  12. 112
    Dave Germiquet Says:

    Hi,

    I’m getting the same issue

    response:
    lircd: error in configfile line -2147483648:
    lircd: Segmentation fault

    With kernel 2.6.16.. from the log files it looks like the blaster is loading fine and all but when i run /usr/local/sbin/lircd –device=/dev/lirc0 /etc/lircd.conf

    i get the above error any ideas?

  13. 113
    Dave Germiquet Says:

    i think its the AMD64 bug as tha ti havesorry i missed the previous post

  14. 114
    Dave Germiquet Says:

    Hi All I am getting this error message when trying to use lircd

    i run

    lircd –device=/dev/lirc0

    lircd “2147483648”: must be valid lirc_t number
    ircd: reading config file faield (im using the for-cecil.tar.bz2 any ideas on how to fix it
    lircd appears to be running
    the modules are loaded properly…

  15. 115
    Dave Germiquet Says:

    it appears the Normal Remote control works… with the hauppauge config with lircd however… i cant get the included lircd.conf to work.. is there any updates to the lircd.conf?

  16. 116
    Dave Germiquet Says:

    Sorry for the added comments:

    I’ll make a retake. When using the lircd.conf mentioned on this page i get this error message:

    when running lircd

    lircd β€œ2147483648β€³: must be valid lirc_t number
    ircd: reading config file failed

    However when I use the Hauppauge lirc config file from the irc-0.8.1-cvspvr150 directory it works
    (I do know that the blaster needs the one on this page)

    So how do i get it to work?

  17. 117
    mark Says:

    Noah: please actually run this on the ivtv-i2c bus, something like:

    i2cdetect -l (find ivtv bus number)
    i2cdetect -a [bus number]

    Tim: the only think I can say is to try another codeset. Unfortunately I can’t do anything at all with what the blaster sends to the STB; I can only copy what the hauppauge driver does.

    Raj: /dev/lircd gets created when you run lirc. Please read step 7 carefully, or if you are still stuck I don’t mind having a poke around via SSH.

    Simon: Have you tried setting repeat= down a bit in .lirrc? If you’ve already done that, then you’ve hit the rubbish firmware on the Zilog chip. I have fiddled around with it, but it appears the current IR sample is destroyed when you poll the chip, so basically if you poll it too frequently then you get no IR response at all. So you can’t improve responsiveness by checking more frequently, and you have to have quite a gap between repeats.

    infringer: chmod 0755 ./send_power_now & ./send_power_new maybe?

    Russ: I’m glad you got it working, might be worth checking with Hauppauge if they have support for the box or not yet. If they do have a driver with support the codeset dump can be updated, otherwise you are correct in that I can’t do anything with it.

    Dave: I’ve not seen that other than with really old versions, are you sure it isn’t picking up lircd from another location? (which lircd, lircd –version). If not I guess build it with DEBUG turned on (from the configure menu), and get a backtrace in gdb.

  18. 118
    Mike Says:

    I finally got my PVR-150 today. It’s not the MCE edition, but the regular one with the jacked wire to IR receiver coming out of the back.

    I tried gentoo lirc 0.8.0-r3 with “hauppauge” driver to no avail. So I surfed on over to this site.

    I just tried your lirc patched for pvr150, with similar “no luck”.

    lirc_dev says “lirc_dev: IR Remote Control driver registered, at major 61

    But other than that, none of the drivers appear to find my IR receiver. ;-( run with “debug=1″ passed to the module, and I’m getting complete silence from them.

    Do I have a bum card?

    This is a Hauppauge WinTV-PVR-150 model 1055

  19. 119
    Noah Says:

    Hello Mark,

    Thanks again for your reply. Here’s the log:

    root@myth:~# i2cdetect -l
    i2c-2 i2c ivtv i2c driver #0 Algorithm unavailable
    i2c-1 smbus SMBus nForce2 adapter at 5100 Non-I2C SMBus adapter
    i2c-0 smbus SMBus nForce2 adapter at 5000 Non-I2C SMBus adapter
    root@myth:~# i2cdetect -a 2
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-2.
    I will probe address range 0x00-0x7f.
    Continue? [Y/n] y
    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    10: XX XX XX XX XX XX XX XX XX XX XX UU XX XX XX XX
    20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    40: XX XX XX XX UU XX XX XX XX XX XX XX XX XX XX XX
    50: UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    60: XX UU XX XX XX XX XX XX XX XX XX XX XX XX XX XX
    70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX

  20. 120
    Dave Says:

    — dmesg —

    lirc_dev: module not supported by Novell, setting U taint flag.
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: module not supported by Novell, setting U taint fla
    g.
    lirc_pvr150: no version for “lirc_unregister_plugin” found: kern
    el tainted.
    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_pvr150: poll thread started
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc
    _pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr
    150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150:
    19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21
    05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7
    c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4
    3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dli
    rc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_p
    vr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr15
    0: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5
    d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Haupp
    auge PVR-150 IR blaster: firmware version 1.3.0

    — GDB doesnt show anything to me :( just spits out error message. Im positive its the right version and i did do debug mode..

    I followed what seb did exactly

    Copyright 2005 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-suse-linux”…Using host libthread_db library “/lib64/libthread_db.so.1″.

    (gdb) set args -n -device=/dev/lirc0 -Dall
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n -device=/dev/lirc0 -Dall
    lircd: error in configfile line 58:
    lircd: “2147483648”: must be a valid (lirc_t) number
    lircd: reading of config file failed
    lircd: lircd(hauppauge_pvr150) ready

    output of another command:

    Type “show copying” to see the conditions.
    There is absolutely no warranty for GDB. Type “show warranty” for details.
    This GDB was configured as “x86_64-suse-linux”…Using host libthread_db library “/lib64/libthread_db.so.1″.

    (gdb) set args -n -device=/dev/lirc0 /etc/lircd.conf
    (gdb) run
    Starting program: /usr/local/sbin/lircd -n -device=/dev/lirc0 /etc/lircd.conf
    lircd: error in configfile line 58:
    lircd: “2147483648”: must be a valid (lirc_t) number
    lircd: reading of config file failed
    lircd: lircd(hauppauge_pvr150) ready

  21. 121
    Russ Says:

    Hauppauge says support for the SA 4200 just missed their June 2006 release and will be included in the next release (date TBA). Cool.

  22. 122
    Dave Germiquet Says:

    Hi,

    Mark did you receive my previous post. gdb turns out nothing it just says lircd ready.

    I’ll post it again when i get home if need be.. It is running on a lib64 platform.

    Could that be a reason?

  23. 123
    Marc Says:

    I have followed the guide through step 5, but am not able to see the IR RX and IR TX lines in the syslog (see below). I have a new PVR 150 with hauppauge ir blaster with botht hte receiver and transmitter attached to the single plug. Any advice would be appreciated!

    Jul 26 11:20:52 localhost kernel: ivtv0: Removed Hauppauge WinTV PVR-150, card #0
    Jul 26 11:20:55 localhost kernel: ivtv: ==================== START INIT IVTV ====================
    Jul 26 11:20:55 localhost kernel: ivtv: version 0.7.0 (tagged release) loading
    Jul 26 11:20:55 localhost kernel: ivtv: Linux version: 2.6.17-1.2157_FC5 mod_unload 686 REGPARM 4KSTACKS gcc-4.1
    Jul 26 11:20:55 localhost kernel: ivtv: In case of problems please include the debug info between
    Jul 26 11:20:55 localhost kernel: ivtv: the START INIT IVTV and END INIT IVTV lines, along with
    Jul 26 11:20:55 localhost kernel: ivtv: any module options, when mailing the ivtv-users mailinglist.
    Jul 26 11:20:55 localhost kernel: ivtv0: Autodetected Hauppauge WinTV PVR-150 card (cx23416 based)
    Jul 26 11:20:55 localhost kernel: ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 10 (level, low) -> IRQ 10
    Jul 26 11:20:55 localhost kernel: tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
    Jul 26 11:20:55 localhost kernel: cx25840 1-0044: cx25841-23 found @ 0x88 (ivtv i2c driver #0)
    Jul 26 11:20:58 localhost kernel: cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
    Jul 26 11:20:58 localhost kernel: wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #0)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: Hauppauge model 26132, rev F0B2, serial# 9329711
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: tuner model is TCL M2523_5N_E (idx 112, type 50)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: TV standards NTSC(M) (eeprom 0x08)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: audio processor is CX25841 (idx 35)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: decoder processor is CX25841 (idx 28)
    Jul 26 11:20:58 localhost kernel: tveeprom 1-0050: has no radio, has IR remote
    Jul 26 11:20:59 localhost kernel: ivtv0: loaded v4l-cx2341x-enc.fw firmware (262144 bytes)
    Jul 26 11:20:59 localhost kernel: ivtv0: Encoder revision: 0x02050032
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder YUV stream: 194 x 10800 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder VBI stream: 120 x 17472 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
    Jul 26 11:20:59 localhost kernel: tuner 1-0061: type set to 50 (TCL 2002N)
    Jul 26 11:21:00 localhost kernel: ivtv0: Initialized Hauppauge WinTV PVR-150, card #0
    Jul 26 11:21:00 localhost kernel: ivtv: ==================== END INIT IVTV ====================
    Jul 26 11:21:00 localhost kernel: lirc_dev: IR Remote Control driver registered, at major 61
    Jul 26 11:21:00 localhost kernel: lirc_pvr150: bt878 #0 [sw]: no devices found

  24. 124
    raj Says:

    Hi mark,
    Please do that for me through SSH…I am facing big trouble as I am new to Linux OS.

    Thanks a lot

  25. 125
    raj Says:

    Hi mark,
    when i ran the command below it has shown no such directory..
    ls -l /dev/lirc*

    Then I tried :

    mknod /dev/lirc0 c 61 0

    now when i ran irw again it is showing no such file or directory!

    What should I have to do now?

  26. 126
    Marc Says:

    Mark,

    Please ignoere my previous post – I saw the link above to the lirc_for_Cecil version and that is working much better for me with the latest stock Fedore core 5 2.6.17 kernel. I can now see the transmitter flash, but my Scientific Atlanta 3250 (key 78) does not respond to the transmissions. I have the transmitter placed directly in front of the 3250’s receiver, so I’m not sure what else I can try. Any ideas?

    Thank you for your efforts on this project. I can’t wait to get it all working!

    raj,

    I had the same problems you’re having until I tried the lirc_for_Cecil version (seearch for the link above). You should try that if you’re using a 2.6.17 kernel.

    Marc

  27. 127
    Dave Germiquet Says:

    If you require ssh access that can be arranged.

  28. 128
    mark Says:

    Mike: Sounds like you have a 2.6.17 kernel, try this one: http://www.blushingpenguin.com/mark/lmilk/lirc-for-cecil.tar.bz2

    Noah: no chip, no dice unfortunately. Like Simon, you could have a bad card, can you try it in a Windows machine and see if it works?

    Dave: sounds like a lirc bug, with ssh access and an hour or two I should be able to sort it out. If you are happy with this you can email details (mark@npsl.co.uk), obviously I’ll need root access to muck about with devices πŸ˜‰

    Marc: 2.6.17 maybe, see answer to Mike? Oh right, I see you did πŸ˜‰ I’d try all the codesets to see if it responds to anything at all, there is often something that matches well enough. If not, then you’d have to bug hauppauge about it.

    raj: send SSH details to my email address (mark@npsl.co.uk), and I’m happy to have a go at sorting it out.

    Russ: oh dear, I hope you have access to a Windows machine πŸ˜‰ I don’t have a spare PVR-150 and the codeset capture process is… umm… interesting!

  29. 129
    Chris Says:

    I had this running beautifully for months until a brown out a messed everything up. So I started from scratch, installed the latest ivtv module and tried the 7.2 and 8.0 patched lirc. I even replaced the card because at first I thought it fried the card because it was in use during the brownout. But i am having problems getting the remote to work. here is the dmesg dump from modprobe lirc_pvr150 debug=1. I have recompiled both version twice from a fesh download and still have the same problem. Any ideas would be helpful. Also i tried modprobe ivtv newi2c=0 and ivtvctl –reset-ir without any results.

    lirc_dev: IR Remote Control driver registered, at major 61
    tuner 0-0061: TV freq (0.00) out of range (44-958)
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_dev: IR Remote Control driver registered, at major 61
    lirc_pvr150: probe 0x70 @ ivtv i2c driver #0: yes
    lirc_pvr150: probe 0x71 @ ivtv i2c driver #0: yes
    lirc_pvr150: chip found with RX and TX
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR RX, addr=71]
    lirc_pvr150: poll thread started
    ivtv0: i2c attach to card #0 ok [client=Hauppauge PVR150 IR TX, addr=70]
    lirc_dev: lirc_register_plugin: sample_rate: 0
    lirc_dev: plugin lirc_pvr150 registered at minor number = 0
    lirc_pvr150: firmware of size 248009 loaded
    lirc_pvr150: 637 codesets loaded
    lirc_pvr150: 01 60 00 01 c7lirc_pvr150: 05 02 04 9d 16lirc_pvr150: 09 6a bc 13 0flirc_pvr150: 0d ea f6 6a falirc_pvr150: 11 72 be 32 7flirc_pvr150: 15 91 9e b6 6blirc_pvr150: 19 2a 7f 06 05lirc_pvr150: 1d 78 73 00 26lirc_pvr150: 21 05 5b 90 43lirc_pvr150: 25 cf 6a 5d 2blirc_pvr150: 29 00 7c 9f 73lirc_pvr150: 2d db 2e cf 3alirc_pvr150: 31 2d 32 d4 3dlirc_pvr150: 35 4b 3b 96 40lirc_pvr150: 39 d7 5a 1a 64lirc_pvr150: 3d ec 7c 98 1elirc_pvr150: 41 5b 17 2b 6dlirc_pvr150: 45 1f 5f 06 54lirc_pvr150: 49 39 66 57 29lirc_pvr150: 4d 8b 4d 3d 48lirc_pvr150: 51 6b 52 81 74lirc_pvr150: 55 0f 7e 1b 63lirc_pvr150: 59 41 b8 91 f9lirc_pvr150: 5d dd 0a 67 50lirc_pvr150: 61 00 00 00 50lirc_pvr150: Hauppauge PVR-150 IR blaster: firmware version 1.3.0
    lirc_pvr150: poll thread ended

  30. 130
    John Miller Says:

    In reference to Dave Germiquet’s post, I am having the same problem on my AMD64 system running Gentoo. I also used the lirc_for_Cecil version, so Dave you are not alone, it does sound like a lirc bug involving the x86_64 arch. I would be glad to help if there is anything I can do.

  31. 131
    mark Says:

    Chris: Sounds like an old bug, can you try the latest version?

    John: I had a poke around on Dave’s machine last night and found out what the issue was, it should be fixed now.

    Latest version: http://www.blushingpenguin.com/mark/lmilk/lirc-0.8.1-CVS-pvr150.tar.bz2

    HTH,

    Mark

  32. 132
    Noah Says:

    Mark,

    Thanks again. Yes, it works like a champ in windows – and I think I mentioned in my first post that it previously worked in linux in another machine. AIEEEEEE! :)

  33. 133
    infringer Says:

    Why in the world dont hauppauge support the many popular cable boxes is beyond me it appears that this is one of the biggest issues with lirc simply lack of support in sending IR codes. Why is it not fesible for hauppauge to allow open source support and development for there cards IR blaster? Are they afraid that someone will steal there work or give out files that will produce buffer overflow volnerabilities? Its a shame my ReplayTV sonic blue and it’s IR blaster worked flawlessly. I’m thinking that the most configureable option would be to use a serial port based device as it would beable to reproduce anything with and is very user configureable like the rest of mythtv setup. I’m thinking the best idea would be to make my own IR blaster using the serial port and a little bit of solder with an IR transmitter. Any IR device should be able technically follow suit of any other IR device if configured right correct? IR standard should be a regulated by the FCC for home use electronics therefore should have to follow guidelines and standards.

    Now anyone have a nice link to a newbie guide of some sort so I can purchase an IR transmitter and get out the soldering iron solder up most likely a few wires to the transmitter and possibly resistors if required.

  34. 134
    Chris Says:

    I gave the new CVS version a try and I am having the same exact problem.

  35. 135
    infringer Says:

    Anyone get this working with a DCT2244 by Motorola?

    If so please do explain,

    It is difficult to understand weather or not my box is supported because they dont specifically specify weather or not it is supported by the driver they specify Motorola and a set of codes all tried out in windows with no luck, To me that tells me it is an unsupported cable box which is quite a pain in the arse. You purchase a product in the event that you want it to operate in a specific manner then the son of a gun will not even operate as planned horrible and horrible support to not exactly ease of use I paid for.

    I think we should get everyone to flood hauppuge with requests for open source support! Get Google to email them for christ sakes to help the summer of code guys develop mythtv to a greater potential as well.

    I have a serial port on the back of my digital cable box but am unsure weather or not its supported to use as an IR blaster or not I have some tests yet to run on my end before I conclude my own investigation into getting this thing running but I will keep on keeping on.

    In the mean time please if you read this:

    Email

    >> Contact Us

    Hauppauge Headquarters, NY
    Hauppauge Computer Works, Inc.
    91 Cabot Court
    Hauppauge, NY 11788
    tel: 631.434.1600
    fax: 631.434.3198
    Sales:
    sales@hauppauge.com
    Tech Support:
    tel: 631.434.3197
    techsupport@hauppauge.com
    Click here to visit our support page
    Investor Relations:
    Jerry Tucciarone
    tel: 631.434.1600 ext.306
    jtucciarone@hauppauge.com

    TIA

  36. 136
    mark Says:

    Noah: hmm, well if it doesn’t work with either i2c driver (newi2c=0 or 1 which is the default), then I’m a bit stumped. It’s probably a timing issue, and you might be able to fiddle around introducing delays (in the ivtv driver). Does the rest of the ivtv hardware function ok? That chip has a software i2c implementation which is quite sensitive to timing, so it could be the case. Also, to be clear, does it work with Windows _on the same motherboard_?

    Chris: Can I have a poke via SSH? The poll thread shouldn’t be committing suicide (there was a quite old bug that did that, so I suppose that there could be something else along the same lines).

    infringer: If Hauppauge don’t support the box, the only thing you can do is bug them and hope/wait. Otherwise, see http://www.lirc.org/ for instructions on building a serial port blaster. I agree that it’s a frustrating situation, but there’s not a lot I can do about it. I’ve had direct contact with Hauppauge and they are unwilling to release any further details of the software running on the Zilog chip, I am not clear for what reason.

  37. 137
    Noah Says:

    Mark,

    Yes, the rest of the ivtv system works great. Worked in windows with this same motherboard. Worked in windows and linux with a different motherboard.

    Thanks!

  38. 138
    infringer Says:

    [root@localhost lirc-0.8.1-CVS-pvr150]# modprobe lirc_dev debug=1 && modprobe lirc_pvr150 debug=1
    FATAL: Error inserting lirc_pvr150 (/lib/modules/2.6.12-12mdk/misc/lirc_pvr150.ko): Invalid module format

  39. 139
    infringer Says:

    Errr dang wish there was an edit button on these posts…

    I wonder if its because I most likely need an earlier version of lirc with my kernel…

    like 0.7.2 or something

    anyways the remote was working I rebooted and above this post my previous post was the error I recieved trying to get it going again … oddly enough I can try and reinstall and the whole 9yds and no such luck … Dang mandriva or something …

    Anyways the name of the chip is not familiar I wonder what kind of assembly they are using is this a simple eeprom chip I take it if so what kind of processor is being used. Maybe some folks could just simply reverse engineer there software like it or not… If they aint going to support there hardware then hack it thats the rule of the future, and the rule of now …

    Anyhow mark you have a good one.

  40. 140
    infringer Says:

    Update it appears the zilog z8 is the chip they are using and from the looks of it the z8 is an updated version of the z80 so in all actuality the z80 disassembler should work relitively well… It seems as if it is one pin programmable…

    Alls we need is for someone to build a firmware for this thing to dump the rom then we have the OS being used by hooking some routine we can force the chip to dump the rom simply by programming a nicely crafted flash we then flash the chip dump the rom disassemble it using something like IDA or TASM30 using the z80 as a common reference.

    heres some pretty basic 8bit opcodes used within the z80 as an example…

    Z80 Opcode Listing
    Z-80 CPU Instruction Set
    —- — ———– —

    ADC HL,ss Add with carry register pair ss to HL.
    ADC A,s Add with carry operand s to accumulator.
    ADD A,n Add value n to accumulator.
    ADD A,r Add register r to accumulator.
    ADD A,(HL) Add location (HL) to acccumulator.
    ADD A,(IX+d) Add location (IX+d) to accumulator.
    ADD A,(IY+d) Add location (IY+d) to accumulator.
    ADD HL,ss Add register pair ss to HL.
    ADD IX,pp Add register pair pp to IX.
    ADD IY,rr Add register pair rr to IY.
    AND s Logical AND of operand s to accumulator.
    BIT b,(HL) Test bit b of location (HL).
    BIT b,(IX+d) Test bit b of location (IX+d).
    BIT b,(IY+d) Test bit b of location (IY+d).
    BIT b,r Test bit b of register r.
    CALL cc,nn Call subroutine at location nn if condition CC is true.
    CCF Complement carry flag.
    CP s Compare operand s with accumulator.
    CPD Comapre location (HL) and acc., decrement HL and BC,
    CPDR Perform a CPD and repeat until BC=0.
    CPI Compare location (HL) and acc., incr HL, decr BC.
    CPIR Perform a CPI and repeat until BC=0.
    CPL Complement accumulator (1’s complement).
    DAA Decimal adjust accumulator.
    DEC m Decrement operand m.
    DEC IX Decrement IX.
    DEC IY Decrement IY.
    DEC ss Decrement register pair ss.
    DI Disable interrupts.
    DJNZ e Decrement B and jump relative if B=0.
    EI Enable interrupts.
    EX (SP),HL Exchange the location (SP) and HL.
    EX (SP),IX Exchange the location (SP) and IX.
    EX (SP),IY Exchange the location (SP) and IY.
    EX AF,AF’ Exchange the contents of AF and AF’.
    EX DE,HL Exchange the contents of DE and HL.
    EXX Exchange the contents of BC,DE,HL with BC’,DE’,HL’.
    HALT Halt computer and wait for interrupt.
    IM 0 Set interrupt mode 0.
    IM 1 Set interrupt mode 1.
    IM 2 Set interrupt mode 2.
    IN A,(n) Load the accumulator with input from device n.
    IN r,(c) Load the register r with input from device (C).
    INC (HL) Increment location (HL).
    INC IX Increment IX.
    INC (IX+d) Increment location (IX+d).
    INC IY Increment IY.
    INC (IY+d) Increment location (IY+d).
    INC r Increment register r.
    INC ss Increment register pair ss.
    IND (HL)=Input from port (C). Decrement HL and B.
    INDR Perform an IND and repeat until B=0.
    INI (HL)=Input from port (C). HL=HL+1. B=B-1.
    INIR Perform an INI and repeat until B=0.
    JP (HL) Unconditional jump to location (HL).
    JP (IX) Unconditional jump to location (IX).
    JP (IY) Unconditional jump to location (IY).
    JP cc,nn Jump to location nn if condition cc is true.
    JR C,e Jump relative to PC+e if carry=1.
    JR e Unconditional jump relative to PC+e.
    JR NC,e Jump relative to PC+e if carry=0.
    JR NZ,e Jump relative to PC+e if non zero (Z=0).
    JR Z,e Jump relative to PC+e if zero (Z=1).
    LD A,(BC) Load accumulator with location (BC).
    LD A,(DE) Load accumulator with location (DE).
    LD A,I Load accumulator with I.
    LD A,(nn) Load accumulator with location nn.
    LD A,R Load accumulator with R.
    LD (BC),A Load location (BC) with accumulator.
    LD (DE),A Load location (DE) with accumulator.
    LD (HL),A Load location (HL) with accumulator.
    LD dd,nn Load register pair dd with nn.
    LD dd,(nn) Load register pair dd with location (nn).
    LD HL,(nn) Load HL with location (nn).
    LD (HL),r Load location (HL) with register r.
    LD I,A Load I with accumulator.
    LD IX,nn Load IX with value nn.
    LD IX,(nn) Load IX with location (nn).
    LD (IX+d),n Load location (IX+d) with n.
    LD (IX+d),r Load location (IX+d) with register r.
    LD IY,nn Load IY with value nn.
    LD IY,(nn) Load IY with location (nn).
    LD (IY+d),n Load location (IY+d) with value n.
    LD (IY+d),r Load location (IY+d) with register r.
    LD (nn),A Load location (nn) with accumulator.
    LD (nn),dd Load location (nn) with register pair dd.
    LD (nn),HL Load location (nn) with HL.
    LD (nn),IX Load location (nn) with IX.
    LD (nn),IY Load location (nn) with IY.
    LD R,A Load R with accumulator.
    LD r,(HL) Load register r with location (HL).
    LD r,(IX+d) Load register r with location (IX+d).
    LD r,(IY+d) Load register r with location (IY+d).
    LD r,n Load register r with value n.
    LD r,r’ Load register r with register r’.
    LD SP,HL Load SP with HL.
    LD SP,IX Load SP with IX.
    LD SP,IY Load SP with IY.
    LDD Load location (DE) with location (HL), decrement DE,HL,BC.
    LDDR Perform an LDD and repeat until BC=0.
    LDI Load location (DE) with location (HL), incr DE,HL; decr BC.
    LDIR Perform an LDI and repeat until BC=0.
    NEG Negate accumulator (2’s complement).
    NOP No operation.
    OR s Logical OR of operand s and accumulator.
    OTDR Perform an OUTD and repeat until B=0.
    OTIR Perform an OTI and repeat until B=0.
    OUT (C),r Load output port (C) with register r.
    OUT (n),A Load output port (n) with accumulator.
    OUTD Load output port (C) with (HL), decrement HL and B.
    OUTI Load output port (C) with (HL), incr HL, decr B.
    POP IX Load IX with top of stack.
    POP IY Load IY with top of stack.
    POP qq Load register pair qq with top of stack.
    PUSH IX Load IX onto stack.
    PUSH IY Load IY onto stack.
    PUSH qq Load register pair qq onto stack.
    RES b,m Reset bit b of operand m.
    RET Return from subroutine.
    RET cc Return from subroutine if condition cc is true.
    RETI Return from interrupt.
    RETN Return from non-maskable interrupt.
    RL m Rotate left through operand m.
    RLA Rotate left accumulator through carry.
    RLC (HL) Rotate location (HL) left circular.
    RLC (IX+d) Rotate location (IX+d) left circular.
    RLC (IY+d) Rotate location (IY+d) left circular.
    RLC r Rotate register r left circular.
    RLCA Rotate left circular accumulator.
    RLD Rotate digit left and right between accumulator and (HL).
    RR m Rotate right through carry operand m.
    RRA Rotate right accumulator through carry.
    RRC m Rotate operand m right circular.
    RRCA Rotate right circular accumulator.
    RRD Rotate digit right and left between accumulator and (HL).
    RST p Restart to location p.
    SBC A,s Subtract operand s from accumulator with carry.
    SBC HL,ss Subtract register pair ss from HL with carry.
    SCF Set carry flag (C=1).
    SET b,(HL) Set bit b of location (HL).
    SET b,(IX+d) Set bit b of location (IX+d).
    SET b,(IY+d) Set bit b of location (IY+d).
    SET b,R Set bit b of register r.
    SLA m Shift operand m left arithmetic.
    SRA m Shift operand m right arithmetic.
    SRL m Shift operand m right logical.
    SUB s Subtract operand s from accumulator.
    XOR s Exclusive OR operand s and accumulator.

    More information can be found at:

    http://dmoz.org/Computers/Programming/Languages/Assembly/Z80/

    dunno really how to start but know where to start if you wanna have full control of this without depending on belated drivers.

    Enjoy,
    infringer

  41. 141
    Akshat Says:

    Hi Mark,

    Thanks a lot for your work. I finally managed to get my PVR 150 IR Blaster working with my cable box. For reference, the Scientific Atlanta 4200 cable box works with the codeset 41. This is the box that Cablevision uses in NY/NJ. There was someone who commented on your blog that he couldn’t get it to work with the 4200. My comment to him is to be absolutely sure that the IR led is right in front of the sensor, which you can locate by shining a bright light into the main LCD window. Even if it is a cm off, the cable box will not respond.

  42. 142
    Tor :: Mythtv and remote problem Says:

    […] BTW. I have tried everything I can see that is relevant on Mark’s Braindump. […]

  43. 143
    mark Says:

    infringer: not compiled against the running kernel. Unfortunately, I don’t have the time or the inclination to disassemble a bunch of Z80 assembly. The firmware is poorly written anyway, so would probably need redoing, and that’s a big task that would almost certaintely ultimately require people to modify their cards. Someone from Hauppauge contacted me offering to give me the kit to write some sane firmware about 6 months ago, I was interested but they never followed up. If you want a project then have fun, sounds like a good one πŸ˜‰

    Akshat: cool, glad you got it working. Yes, the IR range is very short, that’s because it’s not an IR transmitter at all, it’s just a red LED. Shocking, eh?

    Mythtv and remote problem: er, what?

  44. 144
    Noah Says:

    Mark,

    Thanks again for the help thus far. Are they any good pages out there that document how to adjust the timing/delays? Any other suggestions?

    Thanks!

  45. 145
    Dave Says:

    Hi guys,

    I’m using a Scientific Explorer 3200 and it is in the codeset as 78 however 0_78 and 1_78 doesn’t work.

    Its rogers cable do they switch the remote control? or is it standard

  46. 146
    Dave Says:

    Oh ya the light goes on the infared when its working.

  47. 147
    Dave Says:

    woo hoo it works however i had to tape it on the box :) Cuz its short ranged.

  48. 148
    Chris K Says:

    I’ve been away for a while. I did a fresh install and gave it a try again, but no luck with the cvs version again. let me know how to send you the info to SSH into my box.

  49. 149
    Chris K Says:

    Mark,

    Let me know how to send the SSH info over to let you int. I’ll have to set the router up to let you in.

    I decided to redo the install with a extensive format but I am still having the same issue, but when you look arouind you will see what is going on.

  50. 150
    Mike Says:

    I’m having a slight newbie problem.

    When I use the channel_change script, I get the following error:

    /usr/local/bin/irsend: command failed: SEND_ONCE 0_78 5
    /usr/local/bin/irsend: unknown command: “5”

    What have I done wrong?

Pages: « 1 2 [3] 4 5 6 7 8 » Show All

Leave a Reply


− 7 = two