X11 via Screen Sharing no Shift Control Alt

[barry.j.mcinnes@…]

When using Screen Sharing to connect to a Mac running X11 2.3.1, the shift, control alt and Apple modifier keys are not operational in X11. xev display the correct keycodes, but for example in an Xterm window Control-C, executes as "c" and shift-number gives the number instead of the special character. This make xemacs unusable remotely. Other Applications like Terminal and Safari, Textedit accept the key modifiers. X11/xterm is the only problem. X11 modifiers give the same keycode locally and work locally.

[jeremyhu@…]

This is almost certainly a bug in screen sharing. Please report the bug to  http://bugreport.apple.com and provide the bug number to me here, so I can track it.

Thanks.

[jeremyhu@…]

This is a bug in vncviewer... so it's nothing on the VNC server's end:

On Oct 27, 2008, at 09:56, Brian Bender wrote:

On Mon, Oct 27, 2008 at 12:45 PM, Jeremy Huddleston jeremyhu-at-apple.com |Xquartz-dev/personal| <...> wrote: Yeah, I've heard reports of this problem over vnc. Is it really a bug with your vnc viewer or is it a bug with the OSX vnc server? I was under the impression it was the vnc server.

I'm pretty sure it's just the vncviewer. If I connect to the same vnc server with Leopard's Screen\ Sharing.app, the modifiers get passed as expected.

- Brian _ Xquartz-dev mailing list Xquartz-dev@…'  http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

[barry.j.mcinnes@…]

We have used UltraVNC on PCs for remote access to Macs using VINE server and port 5801, with no control char problem at all. We use VINE as we have ARD local use, and you cannot run ARD and Apple VNC at the same time.

The remote Mac clients use ScreenSharing, and all four going to 2.3.1 have the control/shift problem. When we revert to X11 2.3.0 as the only change, for Mac to Mac using ScreenSharing, there is no Control/Shift problem. We do not want a few X11 versions stuck at 2.3.0 while all other Macs get new releases ?

[jeremyhu@…]

The bug is *NOT* in X11. With 2.3.1, X11 changed how it maintained the modifier key state. With 2.3.0, there were bugs with stuck modifier keys, etc. We changed how we stored this modifier state by always updating the modifier state on *EVERY* keypress, not just modifier key presses. This eliminated the suck modifier key bug and opened up this issue.

The bug is NOT present using OSX ScreenSharing as the client ( http://lists.macosforge.org/pipermail/xquartz-dev/2008-October/001307.html). The bug IS present in tightvnc clients and I'm guessing your ultraVNC client. File a bug report with them.

The problem is that if you do the following key sequence

press control press e release e release control

VNC sends this to X11 as KeyPress {key=controll control_state=pressed} KeyPress {key=e control_state=released} KeyRelease {key=e control_state=released} KeyRelease {key=control control_state=released}

Before, we were only modifying our internal modifier state when key=control. ... now we ALWAYS check the state (because the state could've been changed while X11.app was not the front application).

This is either a bug in the VNC Server on OSX (which the Mac OSX VNC client just happens to work around) or a bug in the VNC client that you're using.