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-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
