I was able to reproduce the state you described, by doing the following: -- Press Caps Lock within the TurboVNC Viewer window. You should now see the same sequence of keys as you describe below when pressing Ctrl-C in xev. -- Switch to another window on the client. -- Press Caps Lock again. Now the Caps Lock state becomes disconnected between the Mac client and the VNC server. -- Switch to the TurboVNC Viewer window again. You should still see the sequence of keys as you describe below when pressing Ctrl-C in xev. -- However, pressing Caps Lock again in the viewer window doesn't make it go away. You have to press Caps Lock 3 times in the viewer window to return to the initial state. And furthermore, you have to do this from a Mac client. There is no way to return to the initial state using any other type of client.
Hopefully this is describing the issue you were observing. I could readily imagine that you could have been accidentally hitting Caps Lock, but the confusing behavior of that key on the server side was making you think that it was impossible to reset the server-side state. Here's what's happening: The TurboVNC Viewer transmits the keycode for "lock modifiers" (Caps Lock, Num Lock, and Scroll Lock) to the TurboVNC Server. Historically, the TurboVNC Server has passed those lock modifiers through to the X server. However, this is problematic with the new XKEYBOARD-based keyboard handler, for a couple of reasons: (1) OS X doesn't handle Caps Lock the same way that other platforms do. On Linux and Windows, pressing Caps Lock will cause the O/S (and subsequently the TurboVNC Viewer) to generate both a KeyPress and KeyRelease for that key in rapid succession. The remote X server will store the state of the lock modifier internally and toggle the state every time it receives a KeyPress/KeyRelease combination for that key. OS X, however, generates a KeyPress when turning Caps Lock on and a KeyRelease when turning Caps Lock off. Thus, in order for the remote X server to realize that Caps Lock has been turned on, the key has to be pressed twice on a Mac client, and in order for the remote X server to realize that Caps Lock has been turned off, the key has to be pressed twice again. (2) The XKEYBOARD-based keyboard handler introduced in TurboVNC 2.0 is borrowed from TigerVNC, and when the handler converts the key symbols received from the viewer into key codes (which will be injected into the X server's input queue), the handler generates a fake shift press/release if it detects that the key symbol represents the equivalent of a shifted key code but Shift hasn't been pressed. The reason for this is that uppercase and lowercase letters both have the same keycode, so the only way to inform the X server that a key event represents an uppercase letter is to precede the key event by a Shift key press or a Caps Lock press/release. So if Caps Lock is on and you press a letter key, the TurboVNC Viewer transmits the uppercase key symbol, and the TurboVNC Server translates that into Shift press + letter key press + letter key release + Shift release. (3) Even on Windows and Linux clients, where toggling Caps Lock generates a press/release event combination, the server and client Caps Lock state can still become decoupled if Caps Lock is toggled while the TurboVNC Viewer window is not active. The TigerVNC keyboard handler ignores lock modifier events on the server side, in order to avoid the client/server lock state synchronization issues described above, but when I was implementing the keyboard handler in TurboVNC 2.0, I chose not to ignore those events, thinking I was maintaining backward compatibility with TurboVNC 1.2.x. That decision was wrong, and this issue highlights why. So what happens with the Mac viewer is that, as you keep pressing Caps Lock, it cycles between the client and server respectively thinking that Caps Lock is on/off, off/on, on/on, off/off. Any of the states other than off/off will cause a fake shift to be inserted into the Ctrl-C sequence. In the case of on/off and on/on, this happens because the client is actually sending an uppercase C to the server. In the off/on case, the server is detecting that the lock key is down and is converting the lowercase key symbol to uppercase. I can envision some scenarios under which it might be beneficial to maintain the current behavior of not ignoring lock modifiers (games, for instance.) However, I think the default should be to ignore those like TigerVNC does. I just checked in a patch to master and 2.0.x that changes the default behavior and adds a new environment variable (TVNC_XKBIGNORELOCK) that, when set to 0, will revert to the older behavior. New pre-release build should be available tomorrow. On 12/8/15 5:42 PM, Brett Williams wrote: > I have Press and Hold disabled thanks to your advice. As a vim user, it > is unusable if Press and Hold is enabled. > > Java version for server: >>> java -version > java version "1.7.0_45" > OpenJDK Runtime Environment (rhel-2.4.3.3.el6-x86_64 u45-b15) > OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode) > > Java version for client: >>> java -version > java version "1.8.0_60" > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > On Tue, Dec 8, 2015 at 3:47 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > I think you may be running into the "fake shift" feature in our > XKEYBOARD handler. This feature was inherited from TigerVNC, and I > haven't thoroughly tested it myself. Let me do some additional testing > and see if it might be possible to reproduce this bug consistently. > > One question: Do you have the Press and Hold feature enabled in OS X? > When that feature is enabled (which is the default), it prevents key > repeating for certain keys from working properly in Java, so I generally > recommend that P&H be disabled when using the TurboVNC Viewer > > (http://lifehacker.com/5826055/make-your-keyboard-keys-repeat-properly-when-held-down-in-mac-os-x-lion). > I could also imagine a scenario under which Press and Hold might be > causing one of the alternate symbols for a particular letter key > (accented "a" or "e", for instance) to be sent to the server under rare > circumstances, and this might be causing something wonky to occur with > the XKEYBOARD handler. > > Also, which version of Java are you using? > > > On 12/7/15 4:27 PM, Brett Williams wrote: > > Hi all, > > > > I've had a key map/sticky problem occur twice now (over the course of a > > couple months of heavy use). TurboVNC 2.0.1 (client and server, client > > is Mac OSX Mavericks, server is RedHat 6.5). > > > > Somehow a key gets stuck, or something starts getting misinterpreted. > > Currently, when I try to press Ctrl-C (or Ctrl plus possibly any > > letter), I get some very strange output from xev. The last time, the > > only thing I could do to solve it was to restart the VNC server. I've > > wondered if there is a kind of "key reset" or something that could be > > done to clear the server's mind (for example if a lost packet caused it > > to get in a strange state or something). I've no idea if such a thing > > is even possible. > > > > Any tips for how to narrow things down? This same session has been up > > since Nov 16 without trouble (and I probably type Ctrl-C dozens of times > > a day). It is just this afternoon that I find myself without proper > > keys. Ctrl-V also doesn't seem to work correctly (it may be all Ctrl > > key combinations). > > > > Here is my xev output. I'm pressing Ctrl, then c, then releasing both. > > Notice the extra things in here (unprintable chars and a Shift_L). Note > > that on my screen, the "" actually have a strange character in there (it > > doesn't paste over). It almost appears that when I press c, I also get > > a Shift_L and another unknown key. > > > > KeyPress event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121230667, (87,160), root:(2006,179), > > state 0x2, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, > > XLookupString gives 0 bytes: > > XmbLookupString gives 0 bytes: > > XFilterEvent returns: False > > > > KeyPress event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121233491, (87,160), root:(2006,179), > > state 0x6, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, > > XLookupString gives 0 bytes: > > XmbLookupString gives 0 bytes: > > XFilterEvent returns: False > > > > KeyPress event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121233491, (87,160), root:(2006,179), > > state 0x7, keycode 54 (keysym 0x63, c), same_screen YES, > > XLookupString gives 1 bytes: (03) "" > > XmbLookupString gives 1 bytes: (03) "" > > XFilterEvent returns: False > > > > KeyRelease event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121233491, (87,160), root:(2006,179), > > state 0x7, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, > > XLookupString gives 0 bytes: > > XFilterEvent returns: False > > > > KeyRelease event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121233595, (87,160), root:(2006,179), > > state 0x6, keycode 54 (keysym 0x43, C), same_screen YES, > > XLookupString gives 1 bytes: (03) "" > > XFilterEvent returns: False > > > > KeyRelease event, serial 31, synthetic NO, window 0x2c00001, > > root 0x6a, subw 0x0, time 2121233811, (87,160), root:(2006,179), > > state 0x6, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, > > XLookupString gives 0 bytes: > > XFilterEvent returns: False > > > > > > > > > ------------------------------------------------------------------------------ > > Go from Idea to Many App Stores Faster with Intel(R) XDK > > Give your users amazing mobile app experiences with Intel(R) XDK. > > Use one codebase in this all-in-one HTML5 development environment. > > Design, debug & build mobile apps & 2D/3D high-impact games for > multiple OSs. > >http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 > > > > > > > > _______________________________________________ > > TurboVNC-Users mailing list > >[email protected] > <mailto:[email protected]> > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > TurboVNC-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/turbovnc-users > ------------------------------------------------------------------------------ _______________________________________________ TurboVNC-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/turbovnc-users
