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