[Q] SK4G dropping keystrokes randomly

Search This thread

nxd

Senior Member
Oct 19, 2011
117
78
Tucson, AZ
Thanks. I should know in a day or two whether it's an easy integration.

It turns out it was quite easy to integrate.

http://xdaforums.com/showthread.php?p=26324759#post26324759

Note that the key feature of this patch is that it makes the column and timer delays adjustable. The default settings may or may not be particularly good or suitable for your usage. I encourage interested individuals to experiment with the timings and report their results.

From the Kconfig help text:

The current delays may be read with:

cat /sys/devices/platform/s3c-keypad/column_delay
cat /sys/devices/platform/s3c-keypad/timer_delay

and new delays may be set with:

echo C > /sys/devices/platform/s3c-keypad/column_delay
echo T > /sys/devices/platform/s3c-keypad/timer_delay

where C is the column-switch delay (µs) and T the timer delay (jiffies).

A timer delay of "1" yields the shortest timer, and the most responsive keypad possible, whereas a delay of HZ (e.g., "256") is the longest allowed. For HZ=256, a delay of "2" (HZ/100) is default.

A column-switch delay of "1" is the most efficient (0.1% CPU util.) but results in ghost key presses across columns (rows). The default "300" is very inefficient, 34.6% CPU util., for a timer delay of "2". Try if values of "50" (5.8% CPU) or even "5" (0.6% CPU) work well without ghosting. This delay affects efficiency only, not responsiveness.
 

yogi2010

Senior Member
Dec 22, 2010
2,120
319
Los Angeles, CA

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    If you can find the patch, I will try to integrate it into my kernel.

    good news, the post was easy to find, and the patch is still there!

    http://xdaforums.com/showpost.php?p=16096212&postcount=79

    this was back in the days of KD1, but i hope it could still be of use to us.
    2
    good news, the post was easy to find, and the patch is still there!

    http://xdaforums.com/showpost.php?p=16096212&postcount=79

    this was back in the days of KD1, but i hope it could still be of use to us.

    Thanks. I should know in a day or two whether it's an easy integration.

    Sent from my SGH-T839 using xda premium
    2
    Thanks. I should know in a day or two whether it's an easy integration.

    It turns out it was quite easy to integrate.

    http://xdaforums.com/showthread.php?p=26324759#post26324759

    Note that the key feature of this patch is that it makes the column and timer delays adjustable. The default settings may or may not be particularly good or suitable for your usage. I encourage interested individuals to experiment with the timings and report their results.

    From the Kconfig help text:

    The current delays may be read with:

    cat /sys/devices/platform/s3c-keypad/column_delay
    cat /sys/devices/platform/s3c-keypad/timer_delay

    and new delays may be set with:

    echo C > /sys/devices/platform/s3c-keypad/column_delay
    echo T > /sys/devices/platform/s3c-keypad/timer_delay

    where C is the column-switch delay (µs) and T the timer delay (jiffies).

    A timer delay of "1" yields the shortest timer, and the most responsive keypad possible, whereas a delay of HZ (e.g., "256") is the longest allowed. For HZ=256, a delay of "2" (HZ/100) is default.

    A column-switch delay of "1" is the most efficient (0.1% CPU util.) but results in ghost key presses across columns (rows). The default "300" is very inefficient, 34.6% CPU util., for a timer delay of "2". Try if values of "50" (5.8% CPU) or even "5" (0.6% CPU) work well without ghosting. This delay affects efficiency only, not responsiveness.
    1
    Yeah, the Epic 4G was WAY worse lol. I actually contacted the dev. that pretty much fixed the problem on the Epic, and he was curious and took a look at the SK. He said indeed that the SK shouldn't suffer nearly the same keyboard woes. But he did make a little patch for us anyway, to try and improve some other stuff, but it was never put into a kernel I don't think.

    I do get a missed keystroke on this device every now and then, but not too often.

    If you can find the patch, I will try to integrate it into my kernel.