unasked for autorepeating keys when typing
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
Menu
▾
▴
#192 unasked for autorepeating keys when typing
When I'm typing in some text window on the remote
system via Chicken of the VNC, the remote system will
suddenly go into auto-repeat mode _BUT_ I'm not holding
any keys, and continues until I actually hit another key.
While it can happen for any key, I seem to notice it
more just after typing a SHIFT'ed key.
This is most annoying when I'm entering a password, as
I can not easily see that one or more of the keys have
repeated.
These days, my most common use of COTVNC is connecting
to a Linux vncserver running VMware hosting a Windows
XP session.
However, if I do not use VNC, but rather have the
VMware X-Window exported to X11 on my PowerMac G5
(MacOSX 10.4.7), then I do not have this problem. But
this is only a viable option if I'm in the office.
When I'm at home on my iBook, the bandwidth demands for
X-Windows is too high for my home network connection.
My wife also experiences this problem connecting to her
work systems via COTVNC as well.
Thanks
Bob Harris
Logged In: NO
I have been able to work around this by disabling keyboard autorepeat in the
kde settings for the (linux) server machine. I speculate that this is due to an
interaction between the (Macbook pro OS X) keyboard and KDE's keyboard
handling.
Colleagues using pre-KDE window managers have not reported this problem to
me. Also, disabling autorepeat on my mac client machine does not fix this
problem.
Logged In: YES
user_id=17698
I also see this a lot. I also connect to my Linux box, and
use VMware on it. But I also see this problem outside of VMware.
Logged In: YES
user_id=1342901
Originator: NO
I have this trouble as well, also connecting to a
Linux box running KDE, and I can add another piece
of info which might (or might not) shed some light
on the problem.
This problem, for me, only occurs when I log into the
shared desktop (i.e., screen 0 or port 5900). When I
try any of the other screens (running in the background,
not displayed on the actual screen but instead using Xvnc)
this problem does not occur.
Oh, one more thing, I notice a lot of redraws and
the cursor sometimes looks like it is flickering (as
if it is redrawing many, many times unnecessarily).
When this happens, response time plummets. This problem
is also only limited to the shared screen.
Just a hunch, maybe what's happening is that there is
too much information being sent? If the "key down" and
"key up" events were separated by a lot of other junk,
that could explain why auto-repeat is being triggered.
Maybe this is a bug with the shared desktop in KDE.
Thanks,
Bark!
Logged In: YES
user_id=344921
Originator: NO
I've been unable to reproduce this problem, both with the standard 2.0b4 binary and my own binaries with keyboard fixes (see http://sourceforge.net/tracker/index.php?func=detail&aid=1561487&group_id=64347&atid=507159\). It would be great if you all could help by:
* Providing some more information: Are you using Intel or PowerPC Macs? Which OSX version? Which applications are you using when this happens? Which version of KDE are you using? Has anyone seen this outside KDE? How long does it take, typically, before this happens?
* Try my binaries, available from http://www.cendio.se/~astrand/cotvnc/.
Regards, Peter
Logged In: YES
user_id=1254486
Originator: YES
>Date: 2007-02-06 09:51
>Sender: astrandAccepting Donations
>I've been unable to reproduce this problem, both with the standard 2.0b4
>binary and my own binaries with keyboard fixes (see
>http://sourceforge.net/tracker/index.php?func=detail&aid=1561487&group_id=64347&atid=507159).
>It would be great if you all could help by:
>
>* Providing some more information: Are you using Intel or PowerPC Macs?
Both. I have a PowerMac PowerPC Dual G5/2.5GHz system. I have a MacBook intel Core 2 2GHz system. It has also happened on my previous 14" iBook G4/1GHz, and my wife experiences this on her 12" iBook G4/1Ghz
>Which OSX version?
Mac OS X 10.4.8
>Which applications are you using when this happens?
I generally see this when connected to a Linux box (Redhat Release 4 update 2) BUT more importantly, the applications running on the Linux box that I'm really talking to is a VMware session running Windows-XP. It is a strange world, but it does allow me to get my work done.
My wife is also talking to VMware sessions running on Linux, however, she may be talking to EITHER Windows-XP OR Linux virtual machine sessions.
>Which version of KDE are you using?
Actually I run the Gnome desktop on my remote Linux box.
>Has anyone seen this outside KDE?
While I'm running Gnome as the desktop/window manager, I DO NOT see this autorepeat behavior with anything EXCEPT VMware sessions. Just using the terminal, or other desktop apps does not seem to cause any problems. Then again, I do not use VNC to control the remote Linux desktop all that much. I mostly use it for accessing the VMware sessions.
>How long does it take, typically, before this happens?
No time at all. Here is Where I see it most:
VMware session running Windows-XP. It can be something like just entering my password to log in, or typing in a command window.
Type any Shifted key. A capital letter, the : key, etc... And if you do NOT quickly type another non-shifted key, then there is a 30% chance that the input will start to auto-repeat.
For example: Type Capital B. Release the B and the Shift keys. Do nothing. And now the lowercase b starts to auto-repeat until another key is pressed.
If you continue to hold down the shift key after typing the capital B, then it will not auto-repeat. If I quickly type the next key, beating the auto-repeat settings on the Windows-XP keyboard preferences, then it will not auto-repeat. If you are slow in removing your pinky finger off the shift key, it will not auto-repeat.
And the use of the 'B' key is an example. I can get this behavior with any shifted key. If this happens with an unshifted key, it has been so rare that I can not remember it.
>* Try my binaries, available from http://www.cendio.se/~astrand/cotvnc/.
I have tried your binary. And yes it still does this.
Logged In: YES
user_id=955479
Originator: NO
Just FYI, I can confirm this behaviour on the VNC server provided by RedHat on RHEL4.
I plan to look into it. (10.4, PPC)
Logged In: YES
user_id=1254486
Originator: YES
I have a few thoughts. Is it possible that somehow the other end is not seeing the keyup message for the typed key, but is only seeing the Shift keyup?
The behavior I'm observing is almost as if the other side does not see I released the letter key, but did see the release of the shift key.
Going one step further (again using Windows-XP on VMware on Linux).
I Hold down Shift,
Hold down K,
keep holding down K,
release Shift
Auto-repeat starts
Release k
Auto-repeat CONTINUES
At this point, auto-repeat continues, even though I have released the k key. I can make this happen everytime. It can be any key, A,B,C, etc...
But if, I just hold down lowercase k, wait for auto-repeat to start, then release k, auto-repeat stops. So there is something involving the Shift key modifier that is triggering this behavior.
Another observation. When I'm in this auto-repeat situation, if I move my mouse out of the VMware session window to the Linux desktop, but remain inside of the overall Chickin of the VNC window, the auto-repeat stops.
The same thing happens if I use MacOSX Command-Tab to switch to a different MacOSX application, the auto-repeat stops. Maybe this is a behavior of the Linux window manager, taking focus away from the VMware application. Speculation.
All these experiments are making me wonder if the problem is releasing Shift before releasing the shifted key. When I touch type, I can very fast, and it is very possible that my pinky finger comes off of the Shift key a fraction of a second before I release the letter key, so the other side is seeing
Shift Down
Letter Key Down
Shift Up
Letter key up
And that is the root of the problem. Why that would cause Windows-XP on VMware on Linux to think an Auto-repeat had been requested, I don't know, but it appears to be the key sequence that triggers it for me.
I have some workaround suggestions. They could be dangerous if the remote system has remapped its keyboard so that the Shift key is not doing what we think it is doing. But I'll present my suggestions anyway.
1) When a Shifted key is being sent, if the Shift key is released before the letter key (or : or " or ! or @, etc...), then delay a little bit and see if the letter key is also released and send the keyup sequences as letter key up first, then Shift key up.
1a) Or some variation on that theme. Shift key up, assume letter key is coming up, so send letter key before shift key up. If letter key does not come up in a reasonable period of time, then send lowercase letter key down after the fact.
2) Would it be possible to insert a "Shift" keydown/keyup sequence after a shifted key is sent?
That is to say, if I type capital 'A' and release the Shift, could Chicken of the VNC, notice that I just released the shift key, and inject an extra Shift keydown/keyup sequence into the data stream.
My thought is that if this is a problem at the other end, and CotVNC is just a victim, maybe CotVNC could work around this by sending down a "Do Nothing" key sequence that stops any attempt by the other side from thinking there is an auto-repeat situation.
It could be dangerous, in that CotVNC does not know if the other side has remapped the Shift key to be some other operation, or it is a Game and the Shift key is the "Fire" button, and we just expended 2 rounds, instead of one (but then again, who plays action games via VNC? :-) ).
Anyway, if CotVNC were to try implementing this suggestion, it might be best to make it a option. Something like "Accidental Auto-Repeat Suppression Option".
Thanks for looking at this.
Bob Harris
Logged In: YES
user_id=1342901
Originator: NO
Hi all.
Thanks for looking into this.
FYI, my info is this:
2 Ghz G5 iMac, 10.4.8
I see this problem with all applications running through CotVNC to my Linux workstation running SuSE-9.3 and KDE. Of particular note is that I *only* see this when attaching to the shared desktop (#0, port 5900), not when I use an alternate one (running via xinetd on port 5901-3).
My problems happen with or without the shift key. Also, I note at all times the mouse cursor is flickering and sluggish, leading me to suspect that there is a lot of extra events being sent.
Here is the output of xev [abridged, I'm just including the key events]. I typed "abc" quickly in the window. [No idea if this helps explain anything....it looks the same to me as what happens with auto-repeat.]
KeyPress event, serial 27, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538263, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538513, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538513, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538546, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538546, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538579, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538579, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
XmbLookupString gives 1 bytes: (61) "a"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538583, (80,112), root:(1158,827),
state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
XLookupString gives 1 bytes: (61) "a"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538834, (80,112), root:(1158,827),
state 0x0, keycode 56 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
XmbLookupString gives 1 bytes: (62) "b"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538835, (80,112), root:(1158,827),
state 0x0, keycode 56 (keysym 0x62, b), same_screen YES,
XLookupString gives 1 bytes: (62) "b"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003538835, (80,112), root:(1158,827),
state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (63) "c"
XmbLookupString gives 1 bytes: (63) "c"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003539085, (80,112), root:(1158,827),
state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (63) "c"
KeyPress event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003539085, (80,112), root:(1158,827),
state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (63) "c"
XmbLookupString gives 1 bytes: (63) "c"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0x1c00001,
root 0x13d, subw 0x0, time 1003539119, (80,112), root:(1158,827),
state 0x0, keycode 54 (keysym 0x63, c), same_screen YES,
XLookupString gives 1 bytes: (63) "c"
Thanks again,
Bark!
Logged In: YES
user_id=955479
Originator: NO
I can confirm a few things:
1) The hold shift/hold k/release shift/release k is 100% reproducible.
2) This only failes on the vnc.so extension to the main X server on Linux.
It does not fail on a second server started manually, nor on a solaris
9 (but then, I can't do the extension on Solaris. . .).
Logged In: YES
user_id=7076
Originator: NO
I can confirm this behavior.
Mac client: Macbook core 2 duo, 10.4.9
Also on an MDD Powermac (2x1.25ghz G4)
VNC Server: FreeBSD 6.1, vncserver from ports collection, XFCE 4.2, 1.7ghz Xeon (display 1)
This seems to happen a lot more over a bandwidth-starved connection. My VNC server is at work, and when the mac is connected over the VPN, I'll typically get intermittent delays in latency (~500ms), though it does still happen when wired directly to the 100mbit network.
I've turned off autorepeat in the XFCE control panel, and so far that seems to be an improvement.
Logged In: NO
i see the same thing using cotvnc 2.0b4 running on OS X Leopard 10.5.2 when connecting to x11vcn on RHEL3 remotely to my workplace [with port forwarding thru my company's ssh firewall].
you can mitigate this a bit by being very deliberate with the timing of when down the shift key, strike and release the relevant key to be shifting, and then up the shift key. i do this, where <pause> means just the briefest of hesitations: <shift down> <pause> <key strike/release> <pause> <shift up>. the key strike/release is as quick as usual.