This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 607866 - Sticky keys with tigervnc in F-13 and F-14
Sticky keys with tigervnc in F-13 and F-14
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: tigervnc (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-24 23:36 EDT by Bojan Smojver
Modified: 2015-09-09 05:19 EDT (History)
13 users (show)

See Also:
Fixed In Version: tigervnc-1.0.90-0.16.20100420svn4030.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1010776 (view as bug list)
Environment:
Last Closed: 2011-01-31 14:51:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bojan Smojver 2010-06-24 23:36:47 EDT
Description of problem:
Since the upgrade to F-13, I'm noticing the sticky keys and other keystroke problems. First, they caps lock key almost never works. Second, shift key sometimes gets stuck and is on forever. Third, shift key sometimes doesn't work (you press shift + letter and nothing comes out). Fourth, after the symptoms explained in point three, sometimes the letter that is pressed next will be continuously repeated.

Version-Release number of selected component (if applicable):
1.0.90-0.11.20100420svn4030

How reproducible:
Most times.

Steps to Reproduce:
1. Use caps lock, shift keys.
  
Actual results:
Doesn't work properly.

Expected results:
Used to work.

Additional info:
I am exhibiting this when I do the following:

- connect using Citrix ICA to a Citrix server
- open an RDP session from there to xrdp on F-13, which runs tigervnc in the back.
Comment 1 Bojan Smojver 2010-06-24 23:40:23 EDT
Same with the latest tigervnc currently sitting in updates-testing: tigervnc-1.0.90-0.12.20100420svn4030.fc13
Comment 2 Mike Pittaro 2010-08-27 15:01:18 EDT
Description:

I am seeing similar problems with the tigervnc-1.0.90-0.12.20100420svn4030.fc13 server.

The following key sequences usually reproduce the problem:

1.  <shift>: results in :;;;;;;;;;;;;;;;;;;;;   ...repeating
2. typing "This is a test" results in "This is a est", dropping the second t
3. typing "His hit" results in "His it"


The problem only seems to affect some keys. For example, the 'This is a test' sequence almost always demonstrates the problem, other sequences don't. I have a suspicion the problem is more likely to reproduce if an uppercase letter is followed by it's lower case equivalent.

my VNC viewer is CotVNC 2.0b4

Standard US keyboard layout.
Comment 3 Bojan Smojver 2010-08-27 19:35:02 EDT
(In reply to comment #2)

Exactly the kind of stuff I'm seeing. Thanks for confirming!
Comment 4 Mike Pittaro 2010-08-28 14:19:55 EDT
I am also able to reproduce the same problems using the Apple OS X built in screen sharing application ( connect to server using vnc://<host>:port )

I'm running OS X 10.6.4, Screen sharing Version 1.1.1 (4550500)
Comment 5 Mike Pittaro 2010-08-28 15:07:21 EDT
I am able to reproduce the same problems using TightVNC Viewer version 1.3.9 under OS X 10.6.4, installed via macports.
Comment 6 Adam Tkac 2010-09-02 07:58:35 EDT
Can you test rpms on http://atkac.fedorapeople.org/tigervnc, please? Although I haven't reproduced this bug, in theory those packages should fix this issue. Thank you in advance.
Comment 7 Bojan Smojver 2010-09-02 20:24:35 EDT
I see these landed in stable today. I rebooted the box that's running xrdp and will keep an eye on the whole thing.

One thing I can tell you right away. Caps Lock key still doesn't work. I still get lowercase letters.
Comment 8 Bojan Smojver 2010-09-02 20:48:22 EDT
No good, still does exactly the same thing.
Comment 9 Leland C. Scott 2010-09-06 11:19:17 EDT
(In reply to comment #6)
> Can you test rpms on http://atkac.fedorapeople.org/tigervnc, please? Although I
> haven't reproduced this bug, in theory those packages should fix this issue.
> Thank you in advance.

I upgraded my two Fedora-13 systems on 9/5, 32 bit and 64 bit versions, and I now have exactly the same problem as mentioned by the other poster. The caps lock key doesn't work. I can use the shift key to get upper case however.
Comment 10 Adam Tkac 2010-09-16 11:51:06 EDT
(In reply to comment #9)
> (In reply to comment #6)
> > Can you test rpms on http://atkac.fedorapeople.org/tigervnc, please? Although I
> > haven't reproduced this bug, in theory those packages should fix this issue.
> > Thank you in advance.
> 
> I upgraded my two Fedora-13 systems on 9/5, 32 bit and 64 bit versions, and I
> now have exactly the same problem as mentioned by the other poster. The caps
> lock key doesn't work. I can use the shift key to get upper case however.

It seems this is different issue, check bug #633931.
Comment 11 Adam Tkac 2010-09-20 08:22:34 EDT
(In reply to comment #2)
> Description:
> 
> I am seeing similar problems with the tigervnc-1.0.90-0.12.20100420svn4030.fc13
> server.
> 
> The following key sequences usually reproduce the problem:
> 
> 1.  <shift>: results in :;;;;;;;;;;;;;;;;;;;;   ...repeating
> 2. typing "This is a test" results in "This is a est", dropping the second t
> 3. typing "His hit" results in "His it"
> 
> 
> The problem only seems to affect some keys. For example, the 'This is a test'
> sequence almost always demonstrates the problem, other sequences don't. I have
> a suspicion the problem is more likely to reproduce if an uppercase letter is
> followed by it's lower case equivalent.
> 
> my VNC viewer is CotVNC 2.0b4
> 
> Standard US keyboard layout.

After inspection I'm sure this is viewer's issue. I tested TightVNC 1.3.10 and it is broken. When I run TigerVNC server with "-log Input:stderr:100" (which enables logging of key events) this is in the ~/.vnc/*log file when I press shift, press "t", release shift and release "t":

 Input:       keycode 50 down
 Input:       keycode 28 down
 Input:       keycode 50 up

This means TightVNC viewer sends shift press, then sends "t" press, then sends shift release but doesn't send "t" release even if "t" has been released on the client side. Server thinks that "t" is still pressed so it repeats ";". I'm sure CotVNC is affected by the same issue.
Comment 12 Bojan Smojver 2010-09-21 23:30:48 EDT
Still the same in 0.15 version of tigervnc, currently in testing (https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.15.20100420svn4030.fc13). Caps lock still doesn't work properly either.
Comment 13 Leland C. Scott 2010-09-22 02:15:16 EDT
I just installed the same package (0.15) on my 32 bit F-13 system and I can confirm the caps-lock still doesn't work for me either as well. It's used by the Xrdp package for remote access.

(In reply to comment #12)
> Still the same in 0.15 version of tigervnc, currently in testing
> (https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.15.20100420svn4030.fc13).
> Caps lock still doesn't work properly either.
Comment 14 Need Real Name 2010-09-23 11:15:39 EDT
I've been suffering from this bug for months.  I'm pretty sure its not a client problem, as I've seen it with krdc from kdenetwork-4.4.5-3, tigervnc-client from tigervnc-1.0.90, and even the Apple Leopard screen sharing 1.0.3 client.  I normally use ssh tunnels and the -localhost option, but I've tested without that and I still see the problem, even when the client is running on the same machine as the server!  I've also tested this on both fc13 and fc12, and I can confirm that the problem exists on both. I'm certain I've been seeing it since June, which makes me think it has something to do with the changes between 1.0.0 and 1.0.1.
Comment 15 sub 2010-10-01 20:45:27 EDT
I had a similar problem with sticky keys and shift getting stuck. It went away after I changed the "Input Method" from "IBus" to "X compose table". I did this using the menu: System -> Preferences -> Input Method. Now it appears to work fine.
Comment 16 Leland C. Scott 2010-10-02 01:51:34 EDT
Did that also fix problems with random key strokes being missed and and a single key repeating when not being pressed?
Comment 17 Bojan Smojver 2010-10-05 19:42:53 EDT
(In reply to comment #15)
> I had a similar problem with sticky keys and shift getting stuck. It went away
> after I changed the "Input Method" from "IBus" to "X compose table". I did this
> using the menu: System -> Preferences -> Input Method. Now it appears to work
> fine.

And you changed that on the client or server? I'm guessing server, but just making sure.
Comment 18 Bojan Smojver 2010-10-05 20:04:59 EDT
(In reply to comment #17)
> And you changed that on the client or server? I'm guessing server, but just
> making sure.

I enabled this in my Gnome session on xrdp server now. One thing is for sure, caps lock still doesn't work. I'll have to wait and see about sticky keys.

BTW, prior to this, I didn't even have ibus installed.
Comment 19 Bojan Smojver 2010-10-05 20:06:22 EDT
(In reply to comment #18)
> I enabled this in my Gnome session on xrdp server now. One thing is for sure,
> caps lock still doesn't work. I'll have to wait and see about sticky keys.
> 
> BTW, prior to this, I didn't even have ibus installed.

Nope, this doesn't work for me.
Comment 20 Bojan Smojver 2010-10-27 21:06:50 EDT
Exactly the same problems continue in F-14.
Comment 21 Adam Tkac 2010-10-29 06:48:25 EDT
(In reply to comment #18)
> (In reply to comment #17)
> > And you changed that on the client or server? I'm guessing server, but just
> > making sure.
> 
> I enabled this in my Gnome session on xrdp server now. One thing is for sure,
> caps lock still doesn't work. I'll have to wait and see about sticky keys.

I tested "rdesktop" client (UNIX client) and client shipped as part of Windows 7 and caps lock works fine. Can you please point me where can I download Citrix client? I wasn't able to find it.
Comment 22 Bojan Smojver 2010-10-29 17:39:09 EDT
(In reply to comment #21)
 
> I tested "rdesktop" client (UNIX client) and client shipped as part of Windows
> 7 and caps lock works fine. Can you please point me where can I download Citrix
> client? I wasn't able to find it.

http://www.citrix.com/English/ss/downloads/details.asp?downloadId=3323&productId=186&c1=sot2755
Comment 23 Adam Tkac 2010-11-02 08:41:27 EDT
(In reply to comment #22)
> (In reply to comment #21)
> 
> > I tested "rdesktop" client (UNIX client) and client shipped as part of Windows
> > 7 and caps lock works fine. Can you please point me where can I download Citrix
> > client? I wasn't able to find it.
> 
> http://www.citrix.com/English/ss/downloads/details.asp?downloadId=3323&productId=186&c1=sot2755

I've successfully installed the client, thanks. However I cannot find how to connect to the xrdp session. If I read documentation correctly this client only supports connections to the Citrix's Xen servers.

May I ask you how did you configure the client to connect directly to the xrdp session, please?
Comment 24 Bojan Smojver 2010-11-02 17:18:49 EDT
If you want to replicate what I'm doing, then you need to connect to a Citrix server using ICA client that you downloaded. When you get there and get a desktop, use Microsoft's remote desktop to connect to xrdp (this will be the RDP bit). For me it's a two step process - that's how my work infrastructure is set up (I cannot change that).
Comment 25 sub 2010-11-03 10:12:07 EDT
My problem with dropped keystrokes persist. For what it's worth, as a secondary confirmation of comment 11, I ran "xev" to see X events generated. TigerVNC on the server (FC 13). TightVNC on the client. After a few trials, if I quickly press Shift, X and release both Shift and X, I get the results below, which are missing the release for X.


KeyPress event, serial 33, synthetic NO, window 0x2400001,
    root 0xfd, subw 0x0, time 2249154670, (-478,-5), root:(306,181),
    state 0x10, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x2400001,
    root 0xfd, subw 0x0, time 2249154750, (-478,-5), root:(306,181),
    state 0x11, keycode 53 (keysym 0x58, X), same_screen YES,
    XLookupString gives 1 bytes: (58) "X"
    XmbLookupString gives 1 bytes: (58) "X"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x2400001,
    root 0xfd, subw 0x0, time 2249154825, (-478,-5), root:(306,181),
    state 0x11, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False
Comment 26 robark 2010-11-04 02:42:37 EDT
Got some detailed info

Using  fully updated F13 32bit. vncserver and client same box.
Tested tightvnc / tigervnc / RealVNC viewers.

client viewer: tightvnc 1.2.9/1.3.9/1.3.10 all produce same behavior  of repeating keypress. (note: so both protocol 3.3 and 3.8 with tightvnc behave similar)

How reproducable: 100%

To reproduce bug:
Quickly press a key followed by shift. Then let go of key, then let go of shift.

Example: 

depress 'a'
depress 'shift'
lift 'a'
lift 'shift'

Result: forever repeating 'a'

these have to be performed quick enough to prevent the original 'a' depress from repeating. So if you keep 'a' depressed long enough to cause normal repeat, the bug does not manifest.

However, using tigervnc viewer or RealVNC viewer 4.1.3 I was not able to reproduce the repeat bug. So tigervnc viewer and RealVNC viewer seem to be fine. 

But I'm still not 100% convinced it's a viewer issue as tightvnc viewer worked fine with the old RealVNC server of earlier Fedora releases.


**********Here is tightvnc 1.3.10 viewer output:

Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Password: 
Authentication successful
Desktop name "fedora13:2 (username)"
VNC server default format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Warning: Cannot convert string "-*-helvetica-bold-r-*-*-16-*-*-*-*-*-*-*" to type FontStruct
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
Same machine: preferring raw encoding



********Here is tigervnc viewer output:

TigerVNC Viewer for X version 1.0.90 - built Sep 21 2010 08:35:09
Copyright (C) 2002-2005 RealVNC Ltd.
Copyright (C) 2000-2006 TightVNC Group
Copyright (C) 2004-2009 Peter Astrand for Cendio AB
See http://www.tigervnc.org for information on TigerVNC.

Wed Nov  3 22:07:53 2010
 CConn:       connected to host localhost port 5902
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Wed Nov  3 22:07:57 2010
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding


********Here is RealVNC viewer output:

VNC Viewer Free Edition 4.1.3 for X - built Nov  3 2010 23:30:11
Copyright (C) 2002-2008 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.

Wed Nov  3 23:30:48 2010
 CConn:       connected to host localhost port 5902
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8

Wed Nov  3 23:30:51 2010
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding
 CConn:       Throughput 20000 kbit/s - changing to hextile encoding
 CConn:       Throughput 20000 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using hextile encoding
Comment 27 Bojan Smojver 2010-11-17 00:59:33 EST
This is still a problem in F-14. Is there anything in upstream source that addresses this? Is there another build we can try?
Comment 28 Adam Tkac 2010-11-22 08:13:33 EST
(In reply to comment #27)
> This is still a problem in F-14. Is there anything in upstream source that
> addresses this? Is there another build we can try?

No, unfortunately.

There are two different issues mentioned in this bug report:

1. Key repeating issues with the TightVNC viewer
2. Problem with the Citrix & xrdp connection

The first problem is a bug in the TightVNC viewer, as I wrote in comment #11 - it doesn't send the "release" event so the server thinks the key is still pressed.

The second problem is quite hard to reproduce & fix for me. I tend to say it's a bug in the Citrix server because when I used Microsoft's rdesktop client and xrdp then caps lock worked fine for me. Can you please tell me which version of rdesktop do you use (Windows XP/Vista/7/some other) ? If it will work fine without Citrix's piece then I will mark this bug as Citrix's one.
Comment 29 Bojan Smojver 2010-11-22 15:52:32 EST
(In reply to comment #28)

> 1. Key repeating issues with the TightVNC viewer
> 2. Problem with the Citrix & xrdp connection

Don't worry about 2. The problem is 1. The rest will work (like it did in F-12), once 1 is fixed.
Comment 30 Need Real Name 2010-11-22 16:49:59 EST
(In reply to comment #28)
> (In reply to comment #27)
> > This is still a problem in F-14. Is there anything in upstream source that
> > addresses this? Is there another build we can try?
> 
> No, unfortunately.
> 
> There are two different issues mentioned in this bug report:
> 
> 1. Key repeating issues with the TightVNC viewer
> 2. Problem with the Citrix & xrdp connection
> 
> The first problem is a bug in the TightVNC viewer, as I wrote in comment #11 -
> it doesn't send the "release" event so the server thinks the key is still
> pressed.

I'm wondering how the root cause can be a client bug. I don't doubt that you see the missing release event, but I continue to see repeats and shift key problems with multiple, diverse clients as I mentioned in comment #14.  The only common factor is the tightvnc server.
Comment 31 Bojan Smojver 2010-11-22 17:44:30 EST
(In reply to comment #30)
 
> I'm wondering how the root cause can be a client bug. I don't doubt that you
> see the missing release event, but I continue to see repeats and shift key
> problems with multiple, diverse clients as I mentioned in comment #14.  The
> only common factor is the tightvnc server.

This problem started for me when I upgraded the machine I connect to to F-13, which carries the new tigervnc. It has nothing to do with Citrix (or if it has, this can be ignored). The only reason I mentioned Citrix is because that is how I connect: two hop process - Citrix server first and RDP from there. I cannot change this - I'm not in charge of that part of infrastructure.

PS. Note that if I use Citrix only, there is no problem. I get all my Caps Lock and shifts properly in whichever app I use on the Citrix server. So, once again, this is not a Citrix problem.
Comment 32 Bojan Smojver 2010-11-22 17:45:47 EST
(In reply to comment #31)
 
> This problem started for me when I upgraded the machine I connect to to F-13,
> which carries the new tigervnc.

That is to say, I agree with comment #30.
Comment 33 Bojan Smojver 2010-12-07 22:56:32 EST
(In reply to comment #27)
> This is still a problem in F-14. Is there anything in upstream source that
> addresses this? Is there another build we can try?

Same question. Any progress at all?
Comment 34 Adam Tkac 2010-12-08 06:57:54 EST
(In reply to comment #33)
> (In reply to comment #27)
> > This is still a problem in F-14. Is there anything in upstream source that
> > addresses this? Is there another build we can try?
> 
> Same question. Any progress at all?

Although this is a bug in the various viewers I understand that from user perspective Xvnc might seem guilty.

I added some hacks into 1.0.90-0.22.20100813svn4123.fc14.2 which should solve vast majority of issues (at least the annoying key repeating issue). Can you please download & test packages from http://atkac.fedorapeople.org/tigervnc/? Make sure you install both tigervnc-server and tigervnc-server-minimal. Thank you in advance.
Comment 35 Bojan Smojver 2010-12-08 16:39:05 EST
Running these now:

tigervnc-server-minimal-1.0.90-0.22.20100813svn4123.fc14.2.i686
tigervnc-1.0.90-0.22.20100813svn4123.fc14.1.i686
tigervnc-server-1.0.90-0.22.20100813svn4123.fc14.2.i686
tigervnc-license-1.0.90-0.22.20100813svn4123.fc14.1.noarch

On first use, it looks a bit better (although one can still press Shift and not get an uppercase character), but only time will tell.

PS. Just FYI, Caps Lock still doesn't work.
Comment 36 Bojan Smojver 2010-12-08 21:08:49 EST
(In reply to comment #35)
 
> PS. Just FYI, Caps Lock still doesn't work.

But, at least can be made to work. Press Caps Lock, followed by shift and voilà - uppercase. To get out, just press Caps Lock.

The rest is also working better. The only problems I've seen thus far are:

1. Occasionally shift will affect the second character in the word I'm typing, not the first one. Meaning, there is something going on with timings still here - an already released shift is still affecting individual characters.

2. Occasionally typed characters do not appear at all (not related to Shift as far as I can see).

Anyhow, these packages are an improvement, that's for sure.
Comment 37 Bojan Smojver 2010-12-08 21:11:36 EST
(In reply to comment #36)

> The only problems I've seen thus far are:

And, as I wrote before, sometimes Shift doesn't take effect at all (which I guess is probably 1 above).
Comment 38 Steve Jasinski 2010-12-13 19:57:28 EST
These problems also occur on Fedora 12 (32-bit).  I am using a remote desktop connection from a Windows 7 32-bit client machine into a Fedora 12 box running XRDP.

I'm getting both sticky-keys and missed-keys.  Both sticky and missed keys seem to regularly involve the use of modifier keys - particularly [Shift].

$ uname -a
Linux celery.extensia.local 2.6.32.26-175.fc12.i686 #1 SMP Wed Dec 1 21:52:04 UTC 2010 i686 i686 i386 GNU/Linux

$ yum list "tigervnc*"
Loaded plugins: presto, refresh-packagekit
fedora/metalink                                          | 3.2 kB     00:00     
updates/metalink                                         | 3.0 kB     00:00     
updates                                                  | 4.7 kB     00:00     
updates/primary_db                                       | 5.1 MB     00:20     
Installed Packages
tigervnc-server.i686                       1.0.1-3.fc12                 @updates
Available Packages
tigervnc.i686                              1.0.1-3.fc12                 updates 
tigervnc-server-module.i686                1.0.1-3.fc12                 updates 

$ yum list "xrdp*"
Loaded plugins: presto, refresh-packagekit
Installed Packages
xrdp.i686                   0.5.0-0.10.03172010.fc12                    @updates
Comment 39 Adam Tkac 2010-12-20 08:47:38 EST
(In reply to comment #37)
> (In reply to comment #36)
> 
> > The only problems I've seen thus far are:
> 
> And, as I wrote before, sometimes Shift doesn't take effect at all (which I
> guess is probably 1 above).

Can you start Xvnc server with the "-log Input:stderr:100" parameter, wait till you reproduce this issue and then attach your ~/.vnc/<hostname>:<display>.log file, please? Thank you in advance.
Comment 40 Bojan Smojver 2010-12-20 16:46:38 EST
(In reply to comment #39)
 
> Can you start Xvnc server with the "-log Input:stderr:100" parameter, wait till
> you reproduce this issue and then attach your ~/.vnc/<hostname>:<display>.log
> file, please? Thank you in advance.

OK, I'll stick this in /etc/xrdp/sesman.ini. So, it'll be:

[Xvnc]
param1=-localhost
param2=-log
param3=Input:stderr:100
Comment 41 Bojan Smojver 2010-12-20 17:25:59 EST
Hmm, I can see Xvnc running with -log Input:stderr:100 parameter, but the log file is not being created. I'm guessing xrdp routes stderr somewhere else.
Comment 42 David 2010-12-20 19:09:34 EST
I've been having similar problems since F-13 too.  For me, it's usually when I'm
in emacs and type esc-< to go to the beginning of the buffer.  Instead it sends
a series of ','.  It's as if I didn't hold down the shift key and never let
go of the ,< key.
Comment 43 David 2010-12-23 01:17:12 EST
There is a thread about a similar (same?) problem on the tigervnc list:
http://www.mail-archive.com/tigervnc-users@lists.sourceforge.net/msg00196.html
Somebody submitted a patch.
Comment 44 Bojan Smojver 2010-12-23 01:26:48 EST
(In reply to comment #43)
> There is a thread about a similar (same?) problem on the tigervnc list:
> http://www.mail-archive.com/tigervnc-users@lists.sourceforge.net/msg00196.html
> Somebody submitted a patch.

That somebody is our good package maintainer Adam Tkac :-)

So, either this patch is what we got in RPMS from comment #34 or something brand new. Hopefully something brand new.

Anyhow, let's see whether Adam drops another set of RPMS on us...
Comment 45 Fedora Update System 2011-01-14 09:04:16 EST
tigervnc-1.0.90-0.16.20100420svn4030.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.16.20100420svn4030.fc13
Comment 46 Fedora Update System 2011-01-14 09:04:29 EST
tigervnc-1.0.90-0.24.20100813svn4123.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.24.20100813svn4123.fc14
Comment 47 Adam Tkac 2011-01-14 09:08:05 EST
I believe updated packages fix all issues except Bojan's CapsLock issue with xrdp.

Bojan, in case the CapsLock issue is still present fill a separate bug for it, please.
Comment 48 Fedora Update System 2011-01-14 15:31:25 EST
tigervnc-1.0.90-0.16.20100420svn4030.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update tigervnc'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/tigervnc-1.0.90-0.16.20100420svn4030.fc13
Comment 49 Bojan Smojver 2011-01-14 16:41:42 EST
(In reply to comment #47)
> I believe updated packages fix all issues except Bojan's CapsLock issue with
> xrdp.
> 
> Bojan, in case the CapsLock issue is still present fill a separate bug for it,
> please.

Sure will, thanks. It may take a while before I test all this, because I won't be using this setup for a week or so.
Comment 50 Fedora Update System 2011-01-31 14:51:28 EST
tigervnc-1.0.90-0.24.20100813svn4123.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 51 Fedora Update System 2011-01-31 14:54:06 EST
tigervnc-1.0.90-0.16.20100420svn4030.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 52 robark 2011-02-15 12:25:20 EST
This new version fixes the previous issues but introduces a new one. The backspace key no longer works. I must cursor back and use delete. Wonder if this is because I use Colemak keyboard layout. (btw Caps Lock is also backspace in Colemak and it also doesn't work)
Comment 53 Adam Tkac 2011-02-18 04:19:01 EST
(In reply to comment #52)
> This new version fixes the previous issues but introduces a new one. The
> backspace key no longer works. I must cursor back and use delete. Wonder if
> this is because I use Colemak keyboard layout. (btw Caps Lock is also backspace
> in Colemak and it also doesn't work)

May I ask you which VNC viewer do you use? I checked TigerVNC vncviewer (with colemak layout) and TigerVNC Xvnc server (with default layout) and backspace works fine in my case.
Comment 54 robark 2011-02-22 15:17:58 EST
I'm using tightvnc viewer 1.3.9 x86_64
Comment 55 Bojan Smojver 2011-03-16 20:23:32 EDT
Just one final point here. Although the latest packages made things better, it's still not quite right. There are still situations where Shift key does strange things, like affecting the character after the one it was supposed to and stuff like that.

So, this is more like a workaround than a fix.
Comment 56 Adam Tkac 2011-03-17 05:26:59 EDT
(In reply to comment #55)
> Just one final point here. Although the latest packages made things better,
> it's still not quite right. There are still situations where Shift key does
> strange things, like affecting the character after the one it was supposed to
> and stuff like that.
> 
> So, this is more like a workaround than a fix.

This might me also due bug in the Xorg sources. I filled https://bugs.freedesktop.org/show_bug.cgi?id=34435 some time ago, I will inform you when it gets fixed and then you can test if it solves the rest of Xvnc keyboard issues.
Comment 57 kronical420 2014-03-27 15:01:35 EDT
I hate to bring this back up, but I am experiencing this same issue, and believe to have discovered something that may be of use.

I am running CentOS 6.5 on a Hyper-v VM in Server 2008 R2.
All packages up to date.
Installed xrdp and tiger-vnc to allow remote access via Windows RDP.
Upon a user's first login to the VM using RDP, the user is prompted for root password to allow proxy to be set. As the first character of the root password is a capital letter, I have been unable to successfully enter the password, as (I assume) this first capital character is repeated indefinitely until I hit backspace. From comment 11, and expanding on comment 26, I looked at how (without use of logs) I was physically entering this capital letter. It seems as though I was pressing and holding shift, pressing the letter, and releasing shift prior to releasing the letter, resulting in the character being repeated in this manner, regardless of how fast or slow I attempted to enter the characters, 100% of the time. I opened gedit to test this theory, and in fact was able to replicate the issue 100%, noticing that the repeated character changed to lowercase after the shift key was released.

This occurs regardless of which Input Method is used as suggested in comment 15.

Ok, nothing new here. However, I then decided to repeat the process, ensuring that I release the letter BEFORE releasing the shift key, and 100% of the time, the issue did NOT occur.

tigervnc-server.x86_64 1.1.0-8.el6_5
xrdp.x86_64 0.5.0-0.13.el6
Comment 58 wfyu 2015-09-09 04:28:20 EDT
hi all, I am encountering the same issues, according the comment 57, I release the letter BEFORE releasing the shift key, and no repeat issue.

and another issue is: when I input the left angle bracket "<", it will show me the right one ">". 

tigervnc-server-1.1.0-16.el6.x86_64  on rhel 6.6
turbovnc/tigervnc/tightvnc/ultravnc viewer on win7
Comment 59 wfyu 2015-09-09 05:19:51 EDT
In order to use the opengl, so I used the x0vncserver in linux, and use turbovnc viewer connect to IP. this issue only occured with x0vncserver, And no problem with vncserver.

Note You need to log in before you can comment on or make changes to this bug.