[PATCH] cx88: Add IR support to pcHDTV HD3000 & HD5500

[PATCH] cx88: Add IR support to pcHDTV HD3000 & HD5500

[Erik S. Beiser]

cx88: Add IR support to pcHDTV HD3000 & HD5500

Signed-off-by: Erik S. Beiser <erikb@bu.edu>

---

Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529
I made it into this small patch and added the HD3000 support also, which I have  I've actually
been using this for over a year, updating for new kernel versions.  I'm tired of doing so,
and would like to try and have it merged upstream -- I hope I got all the patch-mechanics
correct.  I just updated and tested it today on 2.6.28.7 vanilla.  Thanks.

--- linux/drivers/media/video/cx88/cx88-input.c.orig	2009-02-20 17:41:27.000000000 -0500
+++ linux/drivers/media/video/cx88/cx88-input.c	2009-02-28 15:58:34.000000000 -0500
@@ -226,6 +226,8 @@ int cx88_ir_init(struct cx88_core *core,
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000LITE:
+	case CX88_BOARD_PCHDTV_HD3000:
+	case CX88_BOARD_PCHDTV_HD5500:
 		ir_codes = ir_codes_hauppauge_new;
 		ir_type = IR_TYPE_RC5;
 		ir->sampling = 1;
@@ -466,6 +468,8 @@ void cx88_ir_irq(struct cx88_core *core)
 	case CX88_BOARD_HAUPPAUGE_HVR3000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000:
 	case CX88_BOARD_HAUPPAUGE_HVR4000LITE:
+	case CX88_BOARD_PCHDTV_HD3000:
+	case CX88_BOARD_PCHDTV_HD5500:
 		ircode = ir_decode_biphase(ir->samples, ir->scount, 5, 7);
 		ir_dprintk("biphase decoded: %x\n", ircode);
 		/*

Re: [PATCH] cx88: Add IR support to pcHDTV HD3000 & HD5500

[Trent Piepho]

On Sat, 28 Feb 2009, Erik S. Beiser wrote:

> cx88: Add IR support to pcHDTV HD3000 & HD5500
>
> Signed-off-by: Erik S. Beiser <erikb@bu.edu>
>
> ---
>
> Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529
> I made it into this small patch and added the HD3000 support also, which I have  I've actually
> been using this for over a year, updating for new kernel versions.  I'm tired of doing so,
> and would like to try and have it merged upstream -- I hope I got all the patch-mechanics
> correct.  I just updated and tested it today on 2.6.28.7 vanilla.  Thanks.

You forgot a patch description.

Since neither the HD-3000 or HD-5500 came with a remote, and at least my
HD-3000 didn't even come with an IR receiver.  So I have to ask why
configuring the driver to work a remote you happened to have is any more
correct than configuring it to work a remote someone else happens to have?

This patch also causes these cards to generate 101 interrupts per second
per card, even when not in use.  That seems pretty costly for a card that
doesn't even come with an ir sensor.

Re: [PATCH] cx88: Add IR support to pcHDTV HD3000 & HD5500

[Erik S. Beiser]

Thanks for your comments, Trent.  My responses below:

Trent Piepho wrote:
> On Sat, 28 Feb 2009, Erik S. Beiser wrote:
> 
>> cx88: Add IR support to pcHDTV HD3000 & HD5500
>>
>> Signed-off-by: Erik S. Beiser <erikb@bu.edu>
>>
>> ---
>>
>> Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529
>> I made it into this small patch and added the HD3000 support also, which I have  I've actually
>> been using this for over a year, updating for new kernel versions.  I'm tired of doing so,
>> and would like to try and have it merged upstream -- I hope I got all the patch-mechanics
>> correct.  I just updated and tested it today on 2.6.28.7 vanilla.  Thanks.
> 
> You forgot a patch description.
Ok, I had looked around and saw many patches that had the one-liner
descriptions, which I thought would be sufficient for a four line
patch.  At your request, I can add a couple lines description when I
fix it (see below).

> Since neither the HD-3000 or HD-5500 came with a remote, and at least my
> HD-3000 didn't even come with an IR receiver.  So I have to ask why
> configuring the driver to work a remote you happened to have is any more
> correct than configuring it to work a remote someone else happens to have?
True, the vendor doesn't seem to sell a remote or IR receiver with
these cards.  I was actually surprised when I got mine to see the jack
for an IR receiver, which can be made to work if one has those parts
from another source.  I don't think that because these cards were sold
without a remote and receiver should mean that we don't expose the
receiver functionality.  I didn't see that happening elsewhere, so I
adopted this 'worksforme' solution.  You have a valid point about the
key mapping, which I did not fully consider.  I don't have a good
justification.  OTOH how does someone with one of those cards use a
remote different from what came with their card?  Is that possible?

All I'm really trying to accomplish is to somehow get inputs from a
remote exposed through some device, with which I could parse stuff
with lirc.  This method exposed it via a /dev/input/eventN node.  I
admit I hadn't paid too much attention to the keymapping before.
(Just trying to get the thing to work.)  But you prompted me to dig
deeper, and I see that in drivers/media/common/ir-keymaps.c there is a
ir_codes_empty mapping.  I tried it tonight with that mapping instead,
and a /dev/input/eventN device was created, but I don't seem to get
anything from it.  Which I guess isn't too surprising, but if so, then
how can I go about generically exposing signals from the IR port to
userspace?

> This patch also causes these cards to generate 101 interrupts per second
> per card, even when not in use.  That seems pretty costly for a card that
> doesn't even come with an ir sensor.
Whoa, I didn't realize that.  Can you point me to how I can verify
that?  Is that simply an effect of the ir->sampling type?  Might a
different type be preferred?  I could do some experimenting.

Is there a better way of doing this?  I'm willing to do a little
legwork to see if I can make this a better, more generic solution.

--Erik

p.s.  I don't mean to appear rude, so FYI I will be w/o net access
this weekend and thus unable to respond to anyone until at least Monday.

Re: [PATCH] cx88: Add IR support to pcHDTV HD3000 & HD5500

[Trent Piepho]

On Thu, 5 Mar 2009, Erik S. Beiser wrote:
> Thanks for your comments, Trent.  My responses below:
>
> Trent Piepho wrote:
> > On Sat, 28 Feb 2009, Erik S. Beiser wrote:
> >
> >> cx88: Add IR support to pcHDTV HD3000 & HD5500
> >>
> >> Signed-off-by: Erik S. Beiser <erikb@bu.edu>
> >>
> >> ---
> >>
> >> Idea originally from http://www.pchdtv.com/forum/viewtopic.php?t=1529
> >> I made it into this small patch and added the HD3000 support also, which I have  I've actually
> >> been using this for over a year, updating for new kernel versions.  I'm tired of doing so,
> >> and would like to try and have it merged upstream -- I hope I got all the patch-mechanics
> >> correct.  I just updated and tested it today on 2.6.28.7 vanilla.  Thanks.
> >
> > You forgot a patch description.
> Ok, I had looked around and saw many patches that had the one-liner
> descriptions, which I thought would be sufficient for a four line
> patch.  At your request, I can add a couple lines description when I
> fix it (see below).

You won't see such patch descriptions from me.  Clearly your patch made
some very significant changes and assumptions that really should have in
the description.

> > Since neither the HD-3000 or HD-5500 came with a remote, and at least my
> > HD-3000 didn't even come with an IR receiver.  So I have to ask why
> > configuring the driver to work a remote you happened to have is any more
> > correct than configuring it to work a remote someone else happens to have?
> True, the vendor doesn't seem to sell a remote or IR receiver with
> these cards.  I was actually surprised when I got mine to see the jack
> for an IR receiver, which can be made to work if one has those parts
> from another source.  I don't think that because these cards were sold
> without a remote and receiver should mean that we don't expose the
> receiver functionality.  I didn't see that happening elsewhere, so I
> adopted this 'worksforme' solution.  You have a valid point about the
> key mapping, which I did not fully consider.  I don't have a good
> justification.  OTOH how does someone with one of those cards use a
> remote different from what came with their card?  Is that possible?

The problem with exposing the receiver this way is that it's unlikely to be
useful to anyone but yourself.  Given the significant performance cost of
enabling ir sampling, and the very limited usefulness, I don't think this
belongs in the kernel.

> All I'm really trying to accomplish is to somehow get inputs from a
> remote exposed through some device, with which I could parse stuff
> with lirc.  This method exposed it via a /dev/input/eventN node.  I
> admit I hadn't paid too much attention to the keymapping before.
> (Just trying to get the thing to work.)  But you prompted me to dig
> deeper, and I see that in drivers/media/common/ir-keymaps.c there is a
> ir_codes_empty mapping.  I tried it tonight with that mapping instead,
> and a /dev/input/eventN device was created, but I don't seem to get
> anything from it.  Which I guess isn't too surprising, but if so, then
> how can I go about generically exposing signals from the IR port to
> userspace?

You might look at the patches from Jon Simrl that try to add IR support to
the input system.  They use configfs to define remote keycodes.

You could also create a device the exports the raw timings to lircd to
decode.  I think lircd might still use the "mode2" interface I created for
the ir serial driver over a decade ago.  That would be easy to copy.

> > This patch also causes these cards to generate 101 interrupts per second
> > per card, even when not in use.  That seems pretty costly for a card that
> > doesn't even come with an ir sensor.
> Whoa, I didn't realize that.  Can you point me to how I can verify
> that?  Is that simply an effect of the ir->sampling type?  Might a
> different type be preferred?  I could do some experimenting.

Just look at /proc/interrupts.  The ir sampling mode isn't documented in
the cx23880 datasheet, but it looks like it samples gpio16 at about 250 us
intervals and generate an interrupt each time 32 samples are ready.  Hugely
inefficient.  A serial port ir receiver would be much better.  The cx23880
can operate that way with gpio22 and gpio23, but I think the mpeg ts
interface uses those gpios.

Maybe there is some way to turn on the remote sampling when something is
listening for remote events?