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, Jul 29, 2010 at 5:28 PM, Jarod Wilson <jarod@xxxxxxxxxx> wrote:
> On Thu, Jul 29, 2010 at 11:04:47PM +0300, Maxim Levitsky wrote:
>> On Thu, 2010-07-29 at 21:35 +0200, Christoph Bartelmus wrote:
>> > Hi!
>> >
>> > Maxim Levitsky "maximlevitsky@xxxxxxxxx" wrote:
>> > [...]
>> > >>>>> Could you explain exactly how timeout reports work?
>> > [...]
>> > >>> So, timeout report is just another sample, with a mark attached, that
>> > >>> this is last sample? right?
>> > >>
>> > >> No, a timeout report is just an additional hint for the decoder that a
>> > >> specific amount of time has passed since the last pulse _now_.
>> > >>
>> > >> [...]
>> > >>> In that case, lets do that this way:
>> > >>>
>> > >>> As soon as timeout is reached, I just send lirc the timeout report.
>> > >>> Then next keypress will start with pulse.
>> > >>
>> > >> When timeout reports are enabled the sequence must be:
>> > >> <pulse> <timeout> <space> <pulse>
>> > >> where <timeout> is optional.
>> > >>
>> > >> lircd will not work when you leave out the space. It must know the exact
>> > >> time between the pulses. Some hardware generates timeout reports that are
>> > >> too short to distinguish between spaces that are so short that the next
>> > >> sequence can be interpreted as a repeat or longer spaces which indicate
>> > >> that this is a new key press.
>> >
>> > > Let me give an example to see if I got that right.
>> > >
>> > >
>> > > Suppose we have this sequence of reports from the driver:
>> > >
>> > > 500 (pulse)
>> > > 200000 (timeout)
>> > > 100000000 (space)
>> > > 500 (pulse)
>> > >
>> > >
>> > > Is that correct that time between first and second pulse is
>> > > '100200000' ?
>> >
>> > No, it's 100000000. The timeout is optional and just a hint to the decoder
>> > how much time has passed already since the last pulse. It does not change
>> > the meaning of the next space.
>>
>> its like a carrier report then I guess.
>> Its clear to me now.
>>
>> So, I really don't need to send/support timeout reports because hw
>> doesn't support that.
>>
>> I can however support timeout (LIRC_SET_REC_TIMEOUT) and and use it to
>> adjust threshold upon which I stop the hardware, and remember current
>> time.
>> I can put that in generic function for ene like hardware
>> (hw that sends small packs of samples very often)
>
> So... I presume this means a v3 patchset? And/or, is it worth merging
> patches 1, 2, 3, 6 and 7 now, then having you work on top of that?

This branch is a as-of-a-few-minutes-ago, up-to-date linuxtv
staging/other plus a few outstanding patches and your patches 1, 2, 3,
6 and 7:

http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/staging

-- 
Jarod Wilson
jarod@xxxxxxxxxxxx
--
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