On Tue, Nov 10, 2020 at 01:19:18PM +0000, Sean Young wrote:
On Tue, Nov 10, 2020 at 01:48:05PM +0100, Michael Klein wrote:
On Tue, Nov 10, 2020 at 10:17:27AM +0000, Sean Young wrote:
> On Mon, Nov 09, 2020 at 04:23:09PM +0100, Michael Klein wrote:
> > The default recorder timeout of 125ms is too high for some BPF protocol
> > decoders when a remote sends repeat codes at high rates. This makes the
> > timeout configurable via the devicetree.
>
> To be honest, 125ms is too much by any measurement. The longest space
> in any protocol I'm aware of is 40ms in the sharp ir protocol. I think
> changing IR_DEFAUL_TIMEOUT to something like 50ms would make sense.
Seconded. I'm happy to prepare a patch if changing the default value is
acceptable.
Actually I don't understand why the high timeout is an issue. It means that
between ir messages you don't get a LIRC_TIMEOUT, just a LIRC_SPACE. Why is
this a problem?
Never mind; this turned out do be a problem of the BPF protocol decoder,
which relied on LIRC_TIMEOUT to terminate each IR message. After
overhaul it is quite a bit simpler now and works fine with the long
timeout.
Thank you for your insights.
Michael
