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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2010-07-29 at 21:42 +0200, Christoph Bartelmus wrote: 
> Hi!
> 
> Maxim Levitsky "maximlevitsky@xxxxxxxxx" 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 what I think lately about that too.
A space is really a space. After which a pulse is received.
Therefore, lets just remove that cruft from in-kernel decoders?
Anyway, even a 200 ms is still time. Its useless to add unnecessary
latency to input.


> 
> > 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.
It can't do that. Due to requirement of alternation between pulses and
spaces, decoder doesn't see a hide nor hair of the last space, even
though internally it keeps growing because hardware continues to send
spaces.


I am now confident that its just a decoder fault, and must be fixed.

Best regards,
Maxim Levitsky

--
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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux