From: Andy Walls <awalls@md.metrocast.net>
To: Jarod Wilson <jarod@wilsonet.com>
Cc: Jean Delvare <khali@linux-fr.org>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Janne Grunau <j@jannau.net>, Jarod Wilson <jarod@redhat.com>
Subject: Re: [PATCH] hdpvr: enable IR part
Date: Sat, 15 Jan 2011 16:46:18 -0500 [thread overview]
Message-ID: <1295127978.7147.4.camel@localhost> (raw)
In-Reply-To: <0EADA025-77B0-4E8B-A649-F3BE6F2E437B@wilsonet.com>
On Sat, 2011-01-15 at 00:37 -0500, Jarod Wilson wrote:
> On Jan 14, 2011, at 11:35 PM, Andy Walls wrote:
> Receive with lirc_zilog does actually work slightly better, though its still
> not perfect. Each key press (using irw to watch) always results in at least
> two lines of output, both with sequence number 00 (i.e., two distinct events),
> and holding a button down results in a stream of 00 events. So repeat is
> obviously busted. But I don't see the wackiness that is happening w/ir-kbd-i2c.
>
> Oh, and transmit works too. So this patch and the buffer alloc patch have now
> been formally tested. Unless we go the custom get_key() route inside the hdpvr
> driver, I think the rest of the legwork to make the hdpvr's IR part behave is
> within lirc_zilog and ir-kbd-i2c (both of which I need to spend some more
> time reading over).
>
>
> > BTW, a checkpatch and compiler tested lirc_zilog.c is here:
> >
> > http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8
> >
> > It should fix all the binding and allocation problems related to
> > ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll
> > kthread. That's possibly another bug to add to the list.
> >
> > Anyway, $DIETY knows if the lirc_zilog module actually still works after
> > all my hacks. Give it a test if you are adventurous. I won't be able
> > to test until tomorrow evening.
>
> I'll try to grab those and give them a test tomorrow, and hey, I've even got
> a baseline to test against now.
I have now confirmed that with all the above patches to lirc_zilog, both
Tx and Rx using an HVR-1600 work.
Time to start cleaning up the less important things I noticed...
Regards,
Andy
next prev parent reply other threads:[~2011-01-15 21:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-14 19:54 [PATCH] hdpvr: enable IR part Jarod Wilson
2011-01-14 21:44 ` Andy Walls
2011-01-14 22:08 ` Jarod Wilson
2011-01-15 2:30 ` Jarod Wilson
2011-01-15 4:35 ` Andy Walls
2011-01-15 5:37 ` Jarod Wilson
2011-01-15 5:53 ` Jarod Wilson
2011-01-15 6:56 ` Jarod Wilson
2011-01-15 21:56 ` Andy Walls
2011-01-15 22:10 ` Jarod Wilson
2011-01-15 14:41 ` Andy Walls
2011-01-15 21:46 ` Andy Walls [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-01-15 12:50 Andy Walls
2011-01-15 15:26 ` Andy Walls
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1295127978.7147.4.camel@localhost \
--to=awalls@md.metrocast.net \
--cc=j@jannau.net \
--cc=jarod@redhat.com \
--cc=jarod@wilsonet.com \
--cc=khali@linux-fr.org \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.