From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxim Levitsky Subject: Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Date: Thu, 29 Jul 2010 20:43:06 +0300 Message-ID: <1280425386.32069.17.camel@maxim-laptop> References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-media-owner@vger.kernel.org To: Christoph Bartelmus Cc: jarod@wilsonet.com, linux-input@vger.kernel.org, linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net, mchehab@redhat.com List-Id: linux-input@vger.kernel.org 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