I am using Apple to Apple screen sharing with the standard Leopard apps - and find that xterms on the target machine don't get modifiers - no shift and no control characters are seen. My original report talked about control characters - I hadn't looked at the shifting at that time.

Hadn't thought to try and eliminate the client or server:

If I use Chicken of VNC on my source machine - then I can get Modified characters in to the xterm on the remote machine.

So it's a problem with the client side of Screen Sharing.app - but then that's to be expected?

It's definitely an problem provoked by X11 - other apps are apparently OK. I haven't tried vncing to or from another non-Apple system into an X server there - I don't have any systems really set up to do that.

Here's my full original bug report:

21-Aug-2008 12:48 AM Peter Collinson: Summary: 
If I screen share from my laptop to my main machine - I cannot get any control characters through to X apps on the main machine. It looks as if screen sharing is sending incorrect[NSEvent modifiers] with the keypress... (diagnosis courtesy of Jeremy Huddlestone). The X server on the target machine version X11 2.3.1 release candidate 1. Steps to Reproduce: 
1) Install the new release of X11 on the target machine 2) Open an xterm window 3) Screen share from another machine into the target machine 4) Select the xterm window - and press Control-C 5) Observe the character 'c' appearing in the window 6) Now start xev on the target machine and press 'Control' and 'c' Expected Results:
 KeyPress event, serial 22, synthetic NO, window 0x600001, root 0x45, subw 0x0, time 3665126062, (78,117), root:(162,507),    state 0x0, keycode 67 (keysym 0xffe3, Control_L), same_screen YES,    XLookupString gives 0 bytes:  "" KeyPress event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127000, (78,117), root:(162,507),    state 0x0, keycode 16 (keysym 0x63, c), same_screen YES,    XLookupString gives 1 bytes:  "c" KeyRelease event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127073, (78,117), root:(162,507),    state 0x0, keycode 16 (keysym 0x63, c), same_screen YES,    XLookupString gives 1 bytes:  "c" KeyRelease event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127000, (78,117), root:(162,507),    state 0x4, keycode 67 (keysym 0xffe3, Control_L), same_screen YES,    XLookupString gives 0 bytes:  "" Ie - press Control - Press c - release c - release control Actual Results:
KeyPress event, serial 22, synthetic NO, window 0x600001, root 0x45, subw 0x0, time 3665126062, (78,117), root:(162,507),    state 0x0, keycode 67 (keysym 0xffe3, Control_L), same_screen YES,    XLookupString gives 0 bytes:  "" KeyRelease event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127000, (78,117), root:(162,507),    state 0x4, keycode 67 (keysym 0xffe3, Control_L), same_screen YES,    XLookupString gives 0 bytes:  "" KeyPress event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127000, (78,117), root:(162,507),    state 0x0, keycode 16 (keysym 0x63, c), same_screen YES,    XLookupString gives 1 bytes:  "c" KeyRelease event, serial 22, synthetic NO, window 0x600001,    root 0x45, subw 0x0, time 3665127073, (78,117), root:(162,507),    state 0x0, keycode 16 (keysym 0x63, c), same_screen YES,    XLookupString gives 1 bytes:  "c" Ie press Control - Release Control - press c - release c. Regression:
This worked OK in previous releases of X11 - but probably because these releases were not handling Key Presses correctly anyway. Notes: 
I was asked to report this bug by Jeremy Huddleston. 21-Aug-2008 12:51 AM Peter Collinson: Here is the full mail from Jeremy with his diagnosis: From: jeremyhu@apple.com Subject: Re: [Xquartz-dev] 'Screen sharing problem' Date: 20 August 2008 15:38:55 BST Ok, then I'm pretty certain it's a bug in screen sharing sending an incorrect [NSEvent modifiers] with the keypress... We didn't notice it before because we used to wait for an NSFlagsChanged event to update our modifier keys. Waiting like that caused us to actually *MISS* changes to the modifiers (such as the space-change stuck control). Now we update the modifiers on every NSEvent we receive. I'm affraid this bug will not be fixed in 2.3.1. Please file a bug at http://bugreport.apple.com and let me know the number so I can track it. Thanks, Jeremy

On 14 Dec 2008, at 06:23, Andrew Farmer wrote:

On 13 Dec 08, at 22:15, Jeremy Huddleston wrote:
That diagnosis was actually resulting from this bit of information from the list reported last month:
<snip>

For the record, I've seen the same behavior with the Vine VNC server and the Linux vncviewer client. Modifiers (including the shift key!) worked in all applications except X11... it was pretty clearly specific to X11.

I can grab some xev output (or whatnot) if you think that'd be helpful.
_______________________________________________
Xquartz-dev mailing list
Xquartz-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev