From: Oliver L. <oli...@gm...> - 2009-07-16 18:28:12
|
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 1059a1060,1062 > * > * These are what the original author of this code put in -- presumably they work > * well for some of the newer devices 1061,1063c1064,1073 < #define IMON_PAD_TIMEOUT 1000 /* in msecs */ < #define IMON_PAD_THRESHOLD 80 /* 160x160 square */ < static int stabilize(int a, int b) --- > #define IMON_PAD_TIMEOUT_NEWDEV 1000 /* in msecs */ > #define IMON_PAD_THRESHOLD_NEWDEV 80 /* 160x160 square */ > > /** > * For older devices (such as the 15c2:ffdc I have) these work better, the above > * values make it very sluggish > */ > #define IMON_PAD_TIMEOUT_OLDDEV 10 > #define IMON_PAD_THRESHOLD_OLDDEV 15 > static int stabilize(int a, int b, short timeout, short threshold) 1087c1097 < if (abs(x) > IMON_PAD_THRESHOLD || abs(y) > IMON_PAD_THRESHOLD) { --- > if (abs(x) > threshold || abs(y) > threshold) { 1102c1112 < y = 17 * IMON_PAD_THRESHOLD / 30; --- > y = 17 * threshold / 30; 1105c1115 < y -= 17 * IMON_PAD_THRESHOLD / 30; --- > y -= 17 * threshold / 30; 1108c1118 < x = 17 * IMON_PAD_THRESHOLD / 30; --- > x = 17 * threshold / 30; 1111c1121 < x -= 17 * IMON_PAD_THRESHOLD / 30; --- > x -= 17 * threshold / 30; 1116c1126 < if (hits == 2 && msec_hit < IMON_PAD_TIMEOUT) { --- > if (hits == 2 && msec_hit < timeout) { 1279c1289 < dir = stabilize((int)rel_x, (int)rel_y); --- > dir = stabilize((int)rel_x, (int)rel_y, IMON_PAD_TIMEOUT_NEWDEV, IMON_PAD_THRESHOLD_NEWDEV); 1316c1326 < dir = stabilize((int)rel_x, (int)rel_y); --- > dir = stabilize((int)rel_x, (int)rel_y, IMON_PAD_TIMEOUT_OLDDEV, IMON_PAD_THRESHOLD_OLDDEV); |