From: Maxim Levitsky <maximlevitsky@gmail.com>
To: Christoph Bartelmus <lirc@bartelmus.de>
Cc: awalls@md.metrocast.net, linux-input@vger.kernel.org,
linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net,
mchehab@redhat.com
Subject: Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver
Date: Thu, 29 Jul 2010 23:04:47 +0300 [thread overview]
Message-ID: <1280433887.2523.11.camel@maxim-laptop> (raw)
In-Reply-To: <BTlNJJN3jFB@christoph>
On Thu, 2010-07-29 at 21:35 +0200, Christoph Bartelmus wrote:
> Hi!
>
> Maxim Levitsky "maximlevitsky@gmail.com" wrote:
> [...]
> >>>>> Could you explain exactly how timeout reports work?
> [...]
> >>> So, timeout report is just another sample, with a mark attached, that
> >>> this is last sample? right?
> >>
> >> No, a timeout report is just an additional hint for the decoder that a
> >> specific amount of time has passed since the last pulse _now_.
> >>
> >> [...]
> >>> In that case, lets do that this way:
> >>>
> >>> As soon as timeout is reached, I just send lirc the timeout report.
> >>> Then next keypress will start with pulse.
> >>
> >> When timeout reports are enabled the sequence must be:
> >> <pulse> <timeout> <space> <pulse>
> >> where <timeout> is optional.
> >>
> >> lircd will not work when you leave out the space. It must know the exact
> >> time between the pulses. Some hardware generates timeout reports that are
> >> too short to distinguish between spaces that are so short that the next
> >> sequence can be interpreted as a repeat or longer spaces which indicate
> >> that this is a new key press.
>
> > Let me give an example to see if I got that right.
> >
> >
> > Suppose we have this sequence of reports from the driver:
> >
> > 500 (pulse)
> > 200000 (timeout)
> > 100000000 (space)
> > 500 (pulse)
> >
> >
> > Is that correct that time between first and second pulse is
> > '100200000' ?
>
> No, it's 100000000. The timeout is optional and just a hint to the decoder
> how much time has passed already since the last pulse. It does not change
> the meaning of the next space.
its like a carrier report then I guess.
Its clear to me now.
So, I really don't need to send/support timeout reports because hw
doesn't support that.
I can however support timeout (LIRC_SET_REC_TIMEOUT) and and use it to
adjust threshold upon which I stop the hardware, and remember current
time.
I can put that in generic function for ene like hardware
(hw that sends small packs of samples very often)
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2010-07-29 20:04 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-28 23:40 (unknown), Maxim Levitsky
2010-07-28 23:40 ` [PATCH 1/9] IR: Kconfig fixes Maxim Levitsky
2010-07-28 23:40 ` [PATCH 2/9] IR: minor fixes: Maxim Levitsky
2010-07-28 23:40 ` [PATCH 3/9] IR: replace spinlock with mutex Maxim Levitsky
2010-07-28 23:40 ` [PATCH 4/9] IR: add helper function for hardware with small o/b buffer Maxim Levitsky
2010-07-28 23:40 ` [PATCH 5/9] IR: extend interfaces to support more device settings Maxim Levitsky
2010-07-29 7:25 ` Christoph Bartelmus
2010-07-29 15:27 ` Maxim Levitsky
2010-07-29 17:05 ` Christoph Bartelmus
2010-07-28 23:40 ` [PATCH 6/9] IR: Allow not to compile keymaps in Maxim Levitsky
2010-07-28 23:40 ` [PATCH 7/9] IR: report unknown scancodes the in-kernel decoders found Maxim Levitsky
2010-07-28 23:40 ` [PATCH 8/9] STAGING: remove lirc_ene0100 driver Maxim Levitsky
2010-07-28 23:40 ` [PATCH 9/9] IR: Port ene driver to new IR subsystem and enable it Maxim Levitsky
2010-07-29 3:52 ` [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Jarod Wilson
2010-07-29 15:30 ` Maxim Levitsky
2010-07-29 15:26 ` Jarod Wilson
2010-07-29 7:23 ` <kein Betreff> Christoph Bartelmus
2010-07-29 14:41 ` [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Maxim Levitsky
2010-07-29 15:38 ` Andy Walls
2010-07-29 16:26 ` Maxim Levitsky
2010-07-29 16:58 ` Andy Walls
2010-07-29 17:15 ` Christoph Bartelmus
2010-07-29 17:35 ` Maxim Levitsky
2010-07-29 19:35 ` Christoph Bartelmus
2010-07-29 20:04 ` Maxim Levitsky [this message]
2010-07-29 21:28 ` Jarod Wilson
2010-07-29 21:57 ` Jarod Wilson
2010-07-29 22:07 ` Maxim Levitsky
2010-07-29 22:24 ` Maxim Levitsky
2010-07-30 2:03 ` Andy Walls
2010-07-29 17:17 ` Christoph Bartelmus
2010-07-29 16:58 ` Christoph Bartelmus
2010-07-29 17:43 ` Maxim Levitsky
2010-07-29 19:42 ` Christoph Bartelmus
2010-07-29 19:58 ` Maxim Levitsky
2010-07-29 19:21 ` Jarod Wilson
-- strict thread matches above, loose matches on Subject: below --
2010-07-30 2:17 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=1280433887.2523.11.camel@maxim-laptop \
--to=maximlevitsky@gmail.com \
--cc=awalls@md.metrocast.net \
--cc=linux-input@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=lirc-list@lists.sourceforge.net \
--cc=lirc@bartelmus.de \
--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;
as well as URLs for NNTP newsgroup(s).