Re: [BUG & PATCH] media/rc/ir-nec-decode : phantom keypress

["David Härdeman" <david@hardeman.nu>]

On 2014-06-12 14:12, Niels Laukens wrote:
> On 2014-06-12 13:51, David Härdeman wrote:
>> On 2014-06-12 13:22, Niels Laukens wrote:
>>> 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).
> 
> OK, that sounds like a good way to solve this as well.
> I'm very new to this subsystem, so I don't know what layer should
> perform what function.

I'm not 100% sure that would be the right fix, but I think so. Haven't 
looked at the driver.

>>>> 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?
> 
> I think it's the out-of-tree saa716x_tbs_dvb driver:
> 
> [    7.670565] input: saa716x IR (TurboSight TBS 6281) as
> /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/rc/rc0/input6
> [    7.671156] rc0: saa716x IR (TurboSight TBS 6281) as
> /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/rc/rc0

Could you paste the output from lsmod?

Where did you get the driver? Is it this one?
http://www.tbsdtv.com/download/document/common/tbs-linux-drivers_v140425.zip


>> And it's what most of the popular hardware does.
> 
> So I'll have to rework this patch to function at this lower level, and
> try to upstream it to TBS. Thank you for your time!
> 
> 
>> 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").
> 
> I see what you mean, but I don't see how the proposed patch fails in
> this sense. Or were you referring to the proposal of adding a timer at
> the ir-nec-decoder level?

Yes. The ir-nec-decoder timer doesn't know what the hardware is up to so 
it could timeout because it didn't get more data in time while at the 
same time the driver is buffering data...