*** Bug 84644 has been marked as a duplicate of this bug. ***

Note that bug:84644 has some interesting insights - especially in regard to repeat rate settings on the host (server) side.

The problem is basically that VNC's protocol handles keypresses by sending a keycode and the 'down-flag', which is set if the key is pressed and unset if the key has been released.
X11's only way to simulate remote keypresses, the XTest extension (which has been designed for testing user interfaces, not for remote users) works exactly like this, you can mark keys as pressed and then as unpressed.

So krfb receives a message when the key is pressed down, uses XTest to tell X11 about it, and when it received the key-up message it uses XTest to release the key in X11. If the latency of the connection is high, this can lead to problem like the ones you are experiencing (BTW i have never seen it myself, but I only use krfb in fast networks).

There is no easy solution that does not modify the VNC protocol. One idea could be to ignore VNC's kde-up message, and to send the X11 a key-down message immediately followed by a key-up message on VNC's key-down message. But that would break other things, like scrolling with the cursor keys. Or krfb could use the one-time-trigger immediately when it receives the key-down message, and if it does not receive a key-up message for a longer period, send a key-down to X11 and not release it until it gets a key-up from the client. But then on X11 it may look like the key has been pressed twice, and it would be relatively hard to determine when to leave the key pressed.
There are many possible solutions, but it is hard to find a good one that does not break too many applications and works with different latencies.

(VNC and X11 should handle key-up/key-down and keystrokes separately, then this mess would not exist)

I'm not so sure that network latency explains the character repeat problem in my case.  The problem shows up for me on a high speed connection; both PC's directly connected to the same 100 Mbps ethernet switch.  This problem does not occur when connecting to a Win2k TightVNC host also on the same switch.  (See my posts in bug 84644 for details).  Yes, the other PC is less than 6 feet (2m) away.  Closer to me than the refrigerator.  :-)

I can offer some simple network statistics.  This is a ping from the client to host system, both in the same 192.168.1.0 subnet:

coyote# ping -c 60 roadrunner
PING roadrunner.acme.com (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.712 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.928 ms
<snip>
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=1.273 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=1.001 ms

--- roadrunner.acme.com ping statistics ---
60 packets transmitted, 60 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.279/0.707/1.273/0.279 ms

All other network activity is consistent with the normal speed of the network. (e.g.  I can browse the internet or access internal web servers with quick response times).

Perhaps my build of krfb is "acting" like there's a slow connection??  I'd be willing to test any configuration suggestions on an identical FreeBSD 4.10 box.  (Yes, I duplicated the character repeat problem on another PC with the same configuration).  By the way, I'm using the FreeBSD binary packages for XFree86-4.3.0,1.

Hmm... another possible explanation could be that the idle routine is not called as frequently as it should. This could either be the result of X11/kernel oddity, or because the update scanner needs a very long time on your system. Right now it scans 1/35th of the screen's lines per idle invocation, +17 for the most likely hits. That's ca 40 lines. If you compile from source, you may tweak them in the file krfb/xupdatescanner.cc. 

In line 65 the constant MAX_RECENT_HITS is the number of the last hits that will be remembered and retried. It's currently 12, you can set it down to 1.

In line 68 the constant CURSOR_SCANLINES is the number of lines around the x11 cursor that will be scanned. You can also reduce it to 1.

If you do this and recompile, you have 15 lines less per idle invocation. If it gets better, this may be the cause of the problem. 

You can also increase the SCANLINES constant to a higher value (35 = every 35th line will be scanned), but only if you add a number into the scanlines array in the following line for each additional scanline. Every number < SCANLINES must be contained in the array, so if you want to scan every 40th scanline, you increase it to 40 and add '35, 36, 37, 38, 39' at the end of the array, after the '21'.

I did the recompile with changes to krfb/xupdatescanner.cc, but it errored out with this:

xupdatescanner.cc:71: excess elements in aggregate initializer
xupdatescanner.cc: In method `bool XUpdateScanner::copyTile(int, int, int, int)':
xupdatescanner.cc:252: warning: comparison between signed and unsigned
xupdatescanner.cc:261: warning: comparison between signed and unsigned
xupdatescanner.cc:270: warning: comparison between signed and unsigned
xupdatescanner.cc:280: warning: comparison between signed and unsigned
xupdatescanner.cc: In method `void XUpdateScanner::createHintFromTile(int, int, int, Hint &)':
xupdatescanner.cc:302: warning: comparison between signed and unsigned
xupdatescanner.cc: In method `void XUpdateScanner::addTileToHint(int, int, int, Hint &)':
xupdatescanner.cc:317: warning: comparison between signed and unsigned
xupdatescanner.cc:330: warning: comparison between signed and unsigned
xupdatescanner.cc:334: warning: comparison between signed and unsigned
xupdatescanner.cc: In method `void XUpdateScanner::flushHint(int, int, int &, Hint &, QPtrList<Hint> &)':
xupdatescanner.cc:360: warning: unused parameter `int x'
xupdatescanner.cc:360: warning: unused parameter `int y'
xupdatescanner.cc: In method `void XUpdateScanner::createHints(QPtrList<Hint> &)':
xupdatescanner.cc:379: warning: comparison between signed and unsigned
xupdatescanner.cc:381: warning: comparison between signed and unsigned
xupdatescanner.cc: In method `void XUpdateScanner::searchUpdates(QPtrList<Hint> &, int)':
xupdatescanner.cc:470: warning: comparison between signed and unsigned
xupdatescanner.cc: At top level:
xupdatescanner.cc:339: warning: `void printStatistics(Hint &)' defined but not used
gmake[3]: *** [xupdatescanner.o] Error 1
gmake[3]: Leaving directory `/usr/ports/net/kdenetwork3/work/kdenetwork-3.2.2/krfb/krfb'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/ports/net/kdenetwork3/work/kdenetwork-3.2.2/krfb'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/ports/net/kdenetwork3/work/kdenetwork-3.2.2'
gmake: *** [all] Error 2
*** Error code 2

Stop in /usr/ports/net/kdenetwork3.

Evidently, due to the change on line 68 where the constant CURSOR_SCANLINES sets the array that follows to 1, except that there are still 5 values defined in the array?

// #define CURSOR_SCANLINES 5
#define CURSOR_SCANLINES 1
int cursorScanlines[CURSOR_SCANLINES] = {
		-10, -4, 0, 4, 10
};

What values should be dropped from '-10, -4, 0, 4, 10'?  Guess I could start trying each of them.  I'll start with 0.

I changed the cursorScanlines array to each of the previous values -10, then -4, 0, 4, 10 one at a time.  Then set CURSOR_SCANLINES back to 5 and put all array values back the way they were.  Results were:

-10: slightly improved - keys still repeat occasionally
 -4: slightly improved - keys still repeat occasionally
  0: slightly improved - keys still repeat occasionally
  4: slightly improved - keys still repeat occasionally
 10: slightly improved - keys still repeat occasionally

Example (with aplogies to Thomas Hardy's "Return of the Native"):
a saturday afternoonnnnnnn in november was approaching the time of twilight, and the vast tract of unenclosed wild known as egdon heath embrooooooowned itself moment by moment

Putting all array values back was perhaps no improvement at all.

Example:
a saturday afternoon in novemberrrrrr wwwwwwwas approaching the      time of twwilight, and the vast tract of unenclosed wild knowwwwwwn         as egdon heath embroooooooowned itself moment by momennnnnnt.

Any other ideas?

Changing the values in cursorScanlines does not have any influence on performance, it's just the relative vertical offset to the mouse cursor that will be scanned. Only reducing CURSOR_SCANLINES matters for performance. 
If you change CURSOR_SCANLINES you need to reduce the members of the array initializers (the '-10, -4, 0, 4, 10' sequence) as well - sorry, forgot that. It you set it to 1, keeping the '0' is the best idea.

Did you set MAX_RECENT_HITS to 1? It's more important than CURSOR_SCANLINES, because it will reduce the scanline number by 11.

If you have both MAX_RECENT_HITS and CURSOR_SCANLINES at 1, I am pretty much out of ideas. Either the problem is somewhere else (and I have no idea where), or your graphics hardware is extremely slow.

Yes, in addition to all variations for the cursorScanlines array, I set CURSOR_SCANLINES = 1 and MAX_RECENT_HITS = 1.  I also changed SCANLINES = 40 along with the additional array values '35, 36, 37, 38, 39'.  These last two constant values were used during all tests.

The video card used during this test was a Diamond Viper 330 with merely 4 Mb memory.  Come to think of it, my production FreeBSD box also has only 4 Mb on the video card, but that is a different make, an ATI Rage Pro.

However, I was previously able to connect to a krfb host when using FreeBSD 4.9 STABLE and KDE 3.1.4 without the key repeat problem.  After upgrading to FreeBSD 4.10 RELEASE and KDE 3.2.2 was when the bug started for me.  Same hardware though.

Would it be possible to compile the krfb code from the kdenetwork source from KDE 3.1.4 on top of KDE 3.2.2?  Just to see if the bug can be isolated to krfb itself, or if it relates to KDE 3.2.x in general.  Just grasping now...

You could try the 3.1.x code, i have no idea whether it compiles. I wouldn't expect any improvement though, there have been very few changes in the code since 3.1, but who knows...

Another possibility is the age of your graphic hardware: has someone reproduced the problem on a fast network AND with a modern graphics card (like GeForce, Radeons)?

I manually copied the (KDE 3.1.4) krfb binaries over the top of my existing ones, and they functioned in my KDE 3.2.2 environment, but did not solve the key repeat problem.  However...

I think I have the solution!  Long story, short.  I changed a setting in my /etc/X11/XF86Config file in the keyboard section, adding this:

Option "XkbDisable" "true"

(See the "Double Key stroke problem in X" section at the bottom of this page: http://www.sibern.com.au/laptop/te2100/ ).

This solution worked with FreeBSD 4.10-RELEASE (KDE 3.2.2) and also on SUSE Linux 9.1 Pro (KDE 3.2.1).  Evidently during my FreeBSD upgrade, this setting was lost when my X configuration was recreated, and SUSE X utility does not auto generate this setting either.

This key repeat problem evidently affects laptop users, and for some reason remote desktop connections.  Perhaps it's because of the fact that krfb does not create a new X session, but rather, uses the existing one, (a feature I love, by the way), so the keyboard options are set twice?

Yeah, but with this "tweak", right alt works as if it was left alt - so I am unable to type any characters normally made with right alt - it opens meu instead (like if it was left alt).

Other thing I noticed, KDE Keyboard Tool (in tray - Kxkb - a keyboard layout switching utility based on X11 xkb extension) doesn't start when this line is added to /etc/X11/XF86Config...

OK, I found even better solution for that.
It is taken from x11vnc - see FAQ question 45 - http://www.karlrunge.com/x11vnc/#FAQ-45

You can disable this unwanted behaviour by simply typing "xset r off" in a console.

This command can be executed as an ordinary user.
A quick fix to krfb would be to set this on when user is connected, and off when disconnects.

http://bugs.kde.org/show_bug.cgi?id=55691 seems to be a duplicate of this bug.