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. > >> > >> Christoph > > > 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 though that timeout reports are useful to stop hardware as soon at timeout it hit.
> > > 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. 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. Best regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
