All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Härdeman" <david@hardeman.nu>
To: Niels Laukens <niels@dest-unreach.be>
Cc: "Mauro Carvalho Chehab" <m.chehab@samsung.com>,
	linux-media@vger.kernel.org,
	"James Hogan" <james.hogan@imgtec.com>,
	"Antti Seppälä" <a.seppala@gmail.com>
Subject: Re: [BUG & PATCH] media/rc/ir-nec-decode : phantom keypress
Date: Thu, 12 Jun 2014 13:51:11 +0200	[thread overview]
Message-ID: <754858effccb1d52ebec59f91f860c26@hardeman.nu> (raw)
In-Reply-To: <53998D69.60901@dest-unreach.be>

On 2014-06-12 13:22, Niels Laukens wrote:
> On 2014-06-12 12:42, David Härdeman wrote:
>> Hi,
> 
> Hi, thanks for the response
> 
> 
>> the problem with triggering a keypress as soon as 32 bits have been
>> received (i.e. before the trailing silence is detected)
> 
> Just for clarity: this patch does wait for the trailing silence. It 
> does
> NOT wait for the trailing silence to have (at least) a specific length.
> (The pulse event is only fired after the pulse has ended, because the
> length of the pulse needs to be known)

True.

Interpret "trailing silence" above as "silence long enough to indicate 
end of message" :)

>> is that it would
>> cause phantom keypresses on some other protocols (I'm thinking of 
>> NEC48,
>> which does exist in the wild).
> 
> I don't think the current code is able to decode NEC48.

No, but it would still be nice not to interpret a NEC48 signal as NEC32.

> Is NEC48 recognizable in some other way than just being longer?

IIRC, no.

> In that case, the alternative would be to start a timer when the
> TRAILING_SPACE is entered, and trigger the key-event after, say 2 
> bit-times.

Another alternative is fix the driver to implement a timeout so that 
"unreasonable" values are not generated (I saw a 240550us space in your 
log).

That's basically what the filtering version of the raw interface does 
(cf. the use of dev->timeout in ir_raw_event_store_with_filter()).

And it's what most of the popular hardware does. For instance, the 
mceusb hardware will send a USB packet with timings including that 
trailing silence. And the decoder can only do their work once a packet 
has arrived (which will contain a number of samples). That also 
demonstrates a potential problem with your suggested approach (i.e. 
timings can be buffered so calls to the decoders are not necessarily 
"real-time").

>> Now, the question is why the trailing silence isn't generated within a
>> reasonable time. Which hardware decoder do you use?
> 
> I use the IR receiver built in to the TBS6281 DVB-T tuner card. I also
> have a TBS6982 DVB-S card, but I guess it's the same hardware.

Which driver?

> It also depends on what "reasonable" means. I've found 300+ms, which is
> unusable long.

Agreed...

//David


  reply	other threads:[~2014-06-12 11:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-31  8:37 [BUG & PATCH] media/rc/ir-nec-decode : phantom keypress Niels Laukens
2014-06-11  8:06 ` Niels Laukens
2014-06-12 10:42   ` David Härdeman
2014-06-12 11:22     ` Niels Laukens
2014-06-12 11:51       ` David Härdeman [this message]
2014-06-12 12:12         ` Niels Laukens
2014-06-12 12:42           ` David Härdeman
2014-06-12 15:19             ` Niels Laukens

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=754858effccb1d52ebec59f91f860c26@hardeman.nu \
    --to=david@hardeman.nu \
    --cc=a.seppala@gmail.com \
    --cc=james.hogan@imgtec.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=niels@dest-unreach.be \
    /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.