Re: iMON Pad Sensitivity -- Latest CVS

[Jarod W. <ja...@wi...>]

On Jul 16, 2009, at 2:28 PM, Oliver Lupton wrote:

> On 15/07/09 04:59, Jarod Wilson wrote:
>> On Tuesday 14 July 2009 16:24:29 Oliver Lupton wrote:
>>> On 14/07/09 21:02, Michael Brakemeier wrote:
>>>> Am Dienstag 14 Juli 2009 20:53:30 schrieb Jarod Wilson:
>>>>> On 07/10/2009 09:30 AM, Oliver Lupton wrote:
>>>>>> Hey,
>>>>>>
>>>>>> I've just updated to LIRC CVS last night to get the new support  
>>>>>> for the
>>>>>> iMON Pad remote switching between mouse/keypad emulation. While
>>>>>> everything basically works, I find that when not in mouse mode  
>>>>>> then the
>>>>>> pad is quite (read: too much so for practical use) insensitive:  
>>>>>> it seems
>>>>>> to require a firm press very distinctly at one of the four  
>>>>>> sides of the
>>>>>> pad to have a hope of registering a keypress event.
>>>>>>
>>>>>> lsusb:
>>>>>> 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller
>>>>>>
>>>>>> Is there any way of configuring the sensitivity? I have the  
>>>>>> following in
>>>>>> lircd.conf:
>>>>>>
>>>>>>              Up                       0x01008000
>>>>>>              Down                     0x01007F00
>>>>>>              Left                     0x01000080
>>>>>>              Right                    0x0100007F
>>>>>>
>>>>>> I don't know how the pad support works: maybe there are some  
>>>>>> additional
>>>>>> codes I could add corresponding to more "Rightish", "Leftish"  
>>>>>> presses?
>>>>> No, these are synthetic key press codes, generated by the driver  
>>>>> after
>>>>> some amount of massaging. Increased sensitivity would likely  
>>>>> require
>>>>> twiddling some of the driver code. Amusingly, said code went in,  
>>>>> because
>>>>> there were multiple complaints the pad was too touchy. :)
>>>>>
>>>>> --jarod
>>>> Hi,
>>>> I've received several complains about the responsiveness of the  
>>>> pad since the
>>>> pad2key patch has been integrated into cvs. It looks like vasilis  
>>>> stabilize()
>>>> function does not really fit for the ffdc, maybe it can be  
>>>> parameterised
>>>> depending on the device-type or a module parameter to allow for a  
>>>> more
>>>> responsive pad? Or we simply revert to the old behaviour and have  
>>>> another
>>>> stabilize-algorithm for the ffdc?
>>>>
>>>> Regards.
>>> I haven't tried it recently, when I first got my device (a year or  
>>> two
>>> ago) then I tried the current LIRC release at the time and I don't
>>> recall it being unusably touchy. It was certainly more usable then  
>>> than
>>> it is now, so at least as an interim measure then I think disabling
>>> 'stabilize' for this device would be an improvement.
>>
>> This sounds like a decent interim measure to me. Anyone care to draft
>> (and of course test) a patch? I haven't got ffdc hardware readily
>> available myself anymore... I'm game for adding a modparam to  
>> enable or
>> disable the stabilize() bits too, if you'd like, though I think  
>> perhaps
>> its best to just come up with a new alg for these devices (if one is
>> really needed at all?).
>>
>>> If I can find some
>>> time I might look into writing a configurable stabiliser, but I  
>>> think
>>> the old behaviour is preferable until that can happen.
>>
>> A configurable stabilizer might be overkill, but by all means, have  
>> at
>> it if you really want to.
>
> This is the result of a few minutes fiddling with the parameters. I  
> don't claim it's the best solution, but it makes my remote more  
> usable with mythtv for me, and shouldn't break it for anyone else. I  
> hope.
>
> Olli
> -----
>
> Index: drivers/lirc_imon/lirc_imon.c
> ===================================================================
> RCS file: /cvsroot/lirc/lirc/drivers/lirc_imon/lirc_imon.c,v
> retrieving revision 1.93
> diff -r1.93 lirc_imon.c


Can you resubmit this using 'cvs diff -up' ?

-- 
Jarod Wilson
ja...@wi...