From mboxrd@z Thu Jan 1 00:00:00 1970 From: lirc@bartelmus.de (Christoph Bartelmus) Subject: Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver Date: 29 Jul 2010 21:42:00 +0200 Message-ID: References: <1280425386.32069.17.camel@maxim-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Return-path: Received: from moutng.kundenserver.de ([212.227.126.171]:53440 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757453Ab0G2Tn7 (ORCPT ); Thu, 29 Jul 2010 15:43:59 -0400 In-Reply-To: <1280425386.32069.17.camel@maxim-laptop> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: maximlevitsky@gmail.com Cc: jarod@wilsonet.com, linux-input@vger.kernel.org, linux-media@vger.kernel.org, lirc-list@lists.sourceforge.net, mchehab@redhat.com Hi! Maxim Levitsky "maximlevitsky@gmail.com" 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from moutng.kundenserver.de ([212.227.126.171]:53440 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757453Ab0G2Tn7 (ORCPT ); Thu, 29 Jul 2010 15:43:59 -0400 Date: 29 Jul 2010 21:42:00 +0200 From: lirc@bartelmus.de (Christoph Bartelmus) To: maximlevitsky@gmail.com Cc: jarod@wilsonet.com Cc: linux-input@vger.kernel.org Cc: linux-media@vger.kernel.org Cc: lirc-list@lists.sourceforge.net Cc: mchehab@redhat.com Message-ID: In-Reply-To: <1280425386.32069.17.camel@maxim-laptop> Subject: Re: [PATCH 0/9 v2] IR: few fixes, additions and ENE driver MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-media-owner@vger.kernel.org List-ID: Hi! Maxim Levitsky "maximlevitsky@gmail.com" 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