tigervnc 1.3.0-3 sort of freezes when typing a "/" slash key in a terminal or xterm. On my German keyboard it's Shift-7. "Freezes" is not exactly the correct word, here are some details: The "/" gets displayed as "?" and most further keys aren't displayed or recognized at all. Some of them show up as Capitals even if I don't press shift. Sometimes pressing shift, the normal key seems to work, but isn't displayed. Even Ctrl-d needs to be Ctrl-Shift-d to work - sometimes. No, Caps-Lock isn't activated. Additionally many mouse functions aren't working any more. I can't move or close windows. I tried it with openbox, fluxbox and xfce. Same result. Downgrading to 1.2.80-0.15 makes it work again. Christian
Are you using a tigervnc-1.3.0-3 viewer with a tigervnc-1.3.0-3 server? How are you starting the server?
I'm starting vncserver with vncserver :3 -geometry 1900x1000 ~/.vnc/xstartup contains: #!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources xsetroot -solid grey openbox-session& The viewer is RealVNC running on Windows (7 Enterprise 64 Bit) as version VNC Viewer Enterprise Edition E4.5.1(r27892)
Can you try using a different viewer to see if the problem exists there as well? That will help narrow down the cause. e.g. try the native vncviewer on the same machine (or another Linux machine), or try the Java applet over HTTP.
Now I tried it on my Fedora 19 box at home too. Here with the tigervnc's vncviewer (on the same machine). Same result. But it not only seems to happen with Shift-7 ("/"). Some other key(s) have the same effect. Seems to be Shift-[Number] related?!?! I'll try to find out more.
These are the keys I always can reproduce the problem with: / (Shift-7) displays a "?" = (Shift-0) displays a "+" ; (Shift-[the key to the right of "M"]) displays a ":" I don't know if it is the character or the physical key. So I tried to describe both. I'm using German layout and a German keyboard. The above "displays a ..." let me think the issue has to do with keyboard and language handling/driver somehow in combination with this new tigervnc version. I tested with a loop of vncserver -kill :1 ; vncserver :1 ; vncviewer :1 and the above mentioned xstartup, even without the .Xresources line. Now I'm out of ideas what to test next.
Can you please test the TigerVNC v1.3.0 java client (preferably as a standalone app rather than as an applet - eg: java -jar /usr/share/classes/vnc/VncViewer.jar)? I spent a great deal of time trying to improve support for non-US keyboards for the 1.3 release, in particular better support for AltGr, but if it's a server-side issue then all that won't help much... Thanks, -brian
It's the same with the v1.3.0 java client. But I think I do have new infos! It seems to be related to IBus (whatever that exactly is). While playing with that issue I realized that the IBus "input method" icon in the systray only contains "English - English (US)" while I installed and use the box with German layout. So I activated "Customize active input methods" in those IBus settings and added "Deutsch - German". After a reboot it seems to work fine! No more freezes. Removing "German" from that list or simply deactivating "Customize active input methods" again (to get automatic behaviour) lets the issue come back. Often switching between "No input method" and "IBus (recommended)" in the desktop preferences (openbox in this case) within the VNC session lets freeze the session completely.
Grmbl.. Most times the "solution" from #7 helps. But not always. :-(
Sorry for that many postings... Additional requirement: To make #7 work the "German" input method must not only be added but activated as well. The active entry seems to have to be the same as the physical keyboard or system language? In this context: Switching input method between German and English doesn't have any visual effect in the terminal if in VNC-session. All keyboard keys always produce German characters (tested with openbox and xfce4). On a real desktop it works as expected.
I hit this same problem after upgrading from Fedora 18 to Fedora 19. I'm using Finnish keyboard layout and for me the problem triggers when typing these two characters, ";" or "=" (at least these). Both of these are entered with shift in my keyboard layout. After this the symptoms are that many key presses do not result any result, some letters that do give capital letters etc, so behavior is a bit like shift would have been stuck down, but not logically. Additional detail vnc server starts to log this when the problem starts: Thu Aug 1 21:35:05 2013 Input: Unable to find the modifier key(s) for releasing Shift Thu Aug 1 21:35:09 2013 Input: Unable to find the modifier key(s) for releasing Shift Thu Aug 1 21:35:15 2013 Input: Unable to find the modifier key(s) for releasing Shift Thu Aug 1 21:35:21 2013 Input: Unable to find the modifier key(s) for releasing Shift Input: Unable to find the modifier key(s) for releasing Shift Input: Unable to find the modifier key(s) for releasing Shift ... Using: tigervnc-server-1.3.0-3.fc19.x86_64 TigerVNC Viewer 32-bit v1.3.0 (20130704)
So, I think somehow Shift is getting virtually "stuck" down. A work-around that seems to work locally is to press both Shift keys, one after the other.
Same issue here.
*** Bug 1005055 has been marked as a duplicate of this bug. ***
Here's how I'm reproducing the problem here: 1. Start vncserver as another user via systemd. 2. Connect using vncviewer on the same machine 3. In that viewer window: start System Settings, click on Region & Language 4. Under Input Sources click Add and select German -> German 5. Now click on the keyboard icon in the bottom right corner of that frame 6. Enter "<" (shift + "," on my UK-layout keyboard) What I see is this: when I hold down Shift R, Shift R becomes highlighted. When I press the "," key, the "<" (far left of bottom row) key is highlighted and so is Shift L. Once I've let go of ",", the "<" key is no longer highlighted but both Shift L and Shift R are highlighted. Finally, when I left go of Shift R, Shift R is no longer highlighted... but Shift L is still highlighted.
(In reply to Brian Hinz from comment #6) > Can you please test the TigerVNC v1.3.0 java client (preferably as a > standalone app rather than as an applet - eg: java -jar > /usr/share/classes/vnc/VncViewer.jar)? I spent a great deal of time trying > to improve support for non-US keyboards for the 1.3 release, in particular > better support for AltGr, but if it's a server-side issue then all that > won't help much... Tried this with tigervnc-server-applet-1.3.0-3.fc19 and it's the same as in comment #14 above. I guess that means it's a server-side issue.
I can reproduce this with Fedora's Xvnc, but not with our (Cendio's) own build, nor TigerVNC's official builds. So maybe it's because of patches that Fedora applies? Or the underlying Xorg version? Fedora has 1.14.2, we use 1.14.0 and TigerVNC has 1.7.7.
Thanks for that pointer... one of our patches was bad, yes. My fault, sorry.
tigervnc-1.3.0-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/tigervnc-1.3.0-7.fc19
Package tigervnc-1.3.0-7.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing tigervnc-1.3.0-7.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17650/tigervnc-1.3.0-7.fc19 then log in and leave karma (feedback).
Updating to tigervnc-1.3.0-7.fc19.x86_64 and tigervnc-server-1.3.0-7.fc19.x86_64 did not fix the problem for me. I'm using Windows TigerVNC Viewer 32-bit v1.3.0 (20130704)) as the VNC viewer.
Is it working for anyone but me? Trying to work out if there is more than one bug here.
At least on one of my test installations it is working now. I'll try it on the "main" installation tomorrow. BTW: The update command mentioned in comment #19 didn't update tigervnc completely and so it didn't work in the first place (still with the old tigervnc-server...). A 'yum update --enablerepo=updates-testing tigervnc*' updated completely to 1.3.0.7 and that is working as mentioned above.
Version 1.3.0-7 seems to have it fixed on my systems. Up to now I wasn't able to kill the keyboard again.
After upgrading all tigervnc* then this works for my system too.
tigervnc-1.3.0-7.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
tigervnc-1.3.0-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/tigervnc-1.3.0-7.fc20
tigervnc-1.3.0-7.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.