New build contains the fix for this issue: http://www.turbovnc.org/DeveloperInfo/PreReleases
On 12/10/15 4:29 PM, Brett Williams wrote: > I connected to that session (I kept it up just for testing purposes). I > wasn't able to get the correct behavior by pressing caps lock 3 times, > but after quite a few times of hitting it, it finally worked. > > I am able to precisely recreate the issue by following your steps, so > you have clearly identified the cause of my issue. > > Thank you. > > > On Thu, Dec 10, 2015 at 1:34 PM, DRC <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > > <mailto:[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]> > > <mailto:[email protected] > <mailto:[email protected]>> > > >https://lists.sourceforge.net/lists/listinfo/turbovnc-users > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > TurboVNC-Users mailing list > >[email protected] > <mailto:[email protected]> > > <mailto:[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] > <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
