From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Jarod Wilson <jarod@wilsonet.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH RFC] ir-rc5-decoder: don't wait for the end space to produce a code
Date: Sat, 23 Oct 2010 03:25:14 +0200 [thread overview]
Message-ID: <1287797114.4948.2.camel@maxim-laptop> (raw)
In-Reply-To: <4CC04671.6000608@redhat.com>
On Thu, 2010-10-21 at 11:56 -0200, Mauro Carvalho Chehab wrote:
> Em 21-10-2010 11:46, Jarod Wilson escreveu:
> > On Oct 20, 2010, at 1:18 PM, Mauro Carvalho Chehab wrote:
> >
> >> The RC5 decoding is complete at a BIT_END state. there's no reason
> >> to wait for the next space to produce a code.
> >
> > Well, if I'm reading things correctly here, I think the only true functional difference made to the decoder here was to skip the if
> > (ev.pulse) break; check in STATE_FINISHED, no? In other words, this looks like it was purely an issue with the receiver data parsing,
> > which was ending on a pulse instead of a space. I can make this guess in greater confidence having seen another patch somewhere that
> > implements a different buffer parsing routine for the polaris devices though... ;)
>
> This patch doesn't solve the Polaris issue ;)
>
> While I made it in the hope that it would fix Polaris (it ended by not solving), I still think it can be kept, as
> it speeds up a little bit the RC-5 output, by not waiting for the last space.
>
> I'll be forwarding soon the polaris decoder fixes patch, and another mceusb patch I did,
> improving data decode on debug mode.
>
> > The mceusb portion of the patch is probably a worthwhile micro-optimization of its ir processing routine though --
> > don't call ir_raw_event_handle if there's no event to handle. Lemme just go ahead and merge that part via my staging tree,
> > if you don't mind. (I've got a dozen or so IR patches that have been queueing up, planning on another pull req relatively soon).
> >
>
> Oh! I didn't notice that this went into the patch... for sure it doesn't belong here.
> Yes, it is just a cleanup for mceusb. Feel free to split it, adding a proper description for it
> and preserving my SOB.
No need in this patch.
My patch resolves the issue genericly by making the driver send the
timeout message at the end of the data among the current length of the
space (which will continue to grow).
Just make mceusb send the timeout sample.
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2010-10-23 1:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-20 17:18 [PATCH RFC] ir-rc5-decoder: don't wait for the end space to produce a code Mauro Carvalho Chehab
2010-10-21 13:46 ` Jarod Wilson
2010-10-21 13:56 ` Mauro Carvalho Chehab
2010-10-23 1:25 ` Maxim Levitsky [this message]
2010-10-23 1:39 ` Mauro Carvalho Chehab
2010-10-23 2:02 ` Maxim Levitsky
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=1287797114.4948.2.camel@maxim-laptop \
--to=maximlevitsky@gmail.com \
--cc=jarod@wilsonet.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox