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: Fri, 14 Jan 2011 23:35:41 -0500 [thread overview]
Message-ID: <1295066141.2459.34.camel@localhost> (raw)
In-Reply-To: <661A728F-3CF1-47F3-A650-D17429AF7DF1@wilsonet.com>
On Fri, 2011-01-14 at 21:30 -0500, Jarod Wilson wrote:
> On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote:
> >>> Registered IR keymap rc-hauppauge-new
> >>> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
> >>> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
> >>> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR I2C]
>
> And it *almost* works. Every key on the bundled remote is recognized, but
> every press gets feedback about like this w/evtest:
>
> Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1
> Event: time 1295058330.966220, -------------- Report Sync ------------
> Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29
> Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2
> Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0
> Event: time 1295058331.825526, -------------- Report Sync ------------
>
> That's just a single short press. With arrow keys, its quite funky to
> watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a
> second, then moves up several more.
Hmm bizzarre.
> ...
> >> Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function
> >> get_key_haup_xvr() *may* need some additions to account for the Rx data
> >> format. I'm not sure of this though. (Or a custom get_key() in the
> >> hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via
> >> platform_data.)
> >>
> >> I will provide a debug patch in another email so that it's easier to see
> >> the data ir-kbd-i2c.c sees coming from the Z8.
> >
> > I'll tack that onto the machine I've got hooked to the hdpvr and see what
> > I can see this weekend, thanks much for the pointers.
>
> I'm inclined to think that it does indeed need some of the changes from
> lirc_zilog brought over (or the custom get_key()). Now on to adding that
> patch and some testing with lirc_zilog...
Yes, maybe both the Rx data parsing *and* the precise delay between Rx
polls.
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.
Regards,
Andy
next prev parent reply other threads:[~2011-01-15 4:36 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 [this message]
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
-- 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=1295066141.2459.34.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.