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.
Same with the latest tigervnc currently sitting in updates-testing: tigervnc-1.0.90-0.12.20100420svn4030.fc13
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.
(In reply to comment #2) Exactly the kind of stuff I'm seeing. Thanks for confirming!
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)
I am able to reproduce the same problems using TightVNC Viewer version 1.3.9 under OS X 10.6.4, installed via macports.
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 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.
No good, still does exactly the same thing.
(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.
(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.
(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.
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.
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.
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.
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.
Did that also fix problems with random key strokes being missed and and a single key repeating when not being pressed?
(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.
(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.
(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.
Exactly the same problems continue in F-14.
(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.
(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
(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?
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).
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
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
This is still a problem in F-14. Is there anything in upstream source that addresses this? Is there another build we can try?
(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.
(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.
(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.
(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.
(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.
(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?
(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.
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.
(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.
(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).
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
(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.
(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
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.
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.
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.
(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...
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
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
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.
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
(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.
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.
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.
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)
(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.
I'm using tightvnc viewer 1.3.9 x86_64
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.
(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.
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
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
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.