Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver

[lirc@bartelmus.de (Christoph Bartelmus)]

Hi!

Maxim Levitsky "maximlevitsky@gmail.com" wrote:

> On Thu, 2010-07-29 at 18:58 +0200, Christoph Bartelmus wrote:
>> Hi Maxim,
>>
>> on 29 Jul 10 at 17:41, Maxim Levitsky wrote:
>> [...]
>>>>> Note that I send timeout report with zero value.
>>>>> I don't think that this value is importaint.
>>>>
>>>> This does not sound good. Of course the value is important to userspace
>>>> and 2 spaces in a row will break decoding.
>>>>
>>> Could you explain exactly how timeout reports work?
>>
>> It all should be documented in the interface description. Jarod probably
>> can point you where it can be found.
>> Timeout reports can only be generated by the hardware because only the
>> hardware can know the exact amount of time passed since the last pulse
>> when any kind of buffering is used by the hardware. You see this esp. with
>> USB devices.
> In my case hardware doesn't have that capability.
> However, I thought that timeout reports are useful to stop hardware as
> soon as timeout is hit.

You are starting a software timer for this? That's not the intention of  
timeout reports. It's just a hint to the decoder which needs to run it's  
own timer anyway. Having to stop the hardware is something very specific  
to your driver.

>>> Lirc interface isn't set to stone, so how about a reasonable compromise.
>>> After reasonable long period of inactivity (200 ms for example), space
>>> is sent, and then next report starts with a pulse.
>>> So gaps between keypresses will be maximum of 200 ms, and as a bonus I
>>> could rip of the logic that deals with remembering the time?
>>
>> For sure I will not agree to any constant introduced here. And I also
>> don't see why. Can you explain why you are trying to change the lirc
>> interface here?

> Currently, to comply with strict lirc requirements I have to send one
> big space between keypresses. Of course I can send it only when I get
> next pulse, which might happen much later.
>
> However, the in-kernel decoders depend on the last space to be sent
> right away.

Ugh. What's the most polite way to express my disgust? ;)

> that it I need to and a keypress with a space, but currently it ends
> with pulse.
>
> So my idea was to wait reasonable time for next pulse, and if it doesn't
> arrive, send a space mark even though no new pulse is registered.
>
> Of course the size of that space can be configured.

The "reasonable time" is protocol specific and must be handled by the  
decoder IMHO and not by the driver.

Christoph