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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
