Re: [Xquartz-dev] Possible white rectangle fix
http://www.opensource.apple.com/darwinsource/tarballs/other/X11-0.46.4.tar.g...
I see an obvious difference: the Tiger code sets the window level in RootlessRepositionWindow(), and the new code doesn't. I don't know whether that's significant - is there a window level that means "invisible"? -- Richard -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
On Dec 10, 2008, at 16:10, Richard Tobin wrote:
http://www.opensource.apple.com/darwinsource/tarballs/other/X11-0.46.4.tar.g...
I see an obvious difference: the Tiger code sets the window level in RootlessRepositionWindow(), and the new code doesn't. I don't know whether that's significant - is there a window level that means "invisible"?
No.... I saw that too, but the new code just sets it in a different location... =/
Just to refresh memories my bug report is: 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' there is some more in the report whcih diagnoses the problem. Well.................... I've just had a response: 14-Dec-2008 12:53 AM Stoney Gamble : Engineering has determined this issue behaves as intended based on the following information: This is an issue in your vncviewer application. To which I have replied: But.. my vncviewer application is provided by Apple - it's screen sharing from the Finder - and exactly what I was hoping you would fix. Can you apply some sense Jeremy??
Hi Peter, That diagnosis was actually resulting from this bit of information from the list reported last month: Begin forwarded message:
From: "Brian Bender" <zt4q4o402@sneakemail.com> Date: October 27, 2008 09:56:09 PDT To: xquartz-dev@lists.macosforge.org Subject: Re: [Xquartz-dev] Modifier keys don't work (with 3-btn emulation disabled) Reply-To: Developer talk about Xquartz <xquartz-dev@lists.macosforge.org
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
So, it looks like the Leopard Screen Sharing.app is working for Brian but not for you... this is most off. Brian, can you confirm that the modifier settings are working as expected with Screen Sharing.app? On Dec 13, 2008, at 20:24, Peter Collinson wrote:
Just to refresh memories my bug report is:
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'
there is some more in the report whcih diagnoses the problem.
Well.................... I've just had a response:
14-Dec-2008 12:53 AM Stoney Gamble : Engineering has determined this issue behaves as intended based on the following information:
This is an issue in your vncviewer application.
To which I have replied:
But.. my vncviewer application is provided by Apple - it's screen sharing from the Finder - and exactly what I was hoping you would fix.
Can you apply some sense Jeremy??
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
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.
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
Thanks Peter, I've reopened the issue and will pass on anything to you that might be of help... On Dec 14, 2008, at 00:30, Peter Collinson wrote:
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
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Dec 14, 2008, at 00:30, Peter Collinson wrote:
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. [snip] 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"
state should actually be 0x4 for ControlMask here, and XLookupString should be ""
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"
state should be 0x4 here too, and XLookupString should not provide "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: ""
George -- http://people.freedesktop.org/~gstaplin/
On Dec 14, 2008, at 1:15 AM, Jeremy Huddleston wrote:
So, it looks like the Leopard Screen Sharing.app is working for Brian but not for you... this is most off. Brian, can you confirm that the modifier settings are working as expected with Screen Sharing.app?
I can confirm that X11 modifier keys under the Screen Sharing.app doesn't work for me (including with the newly minted 10.5.6), but CotVNC does. Modifier keys under the Screen Sharing.app hasn't worked for me since 2.3.1-rc1. I thought this was a reported bug to Apple. It's troubling that they have blamed it on someone else, this bug causes significant usability issues for me with X11. I guess I should file a radar? Jamie
On Dec 15, 2008, at 10:57, Jamie Kennea wrote:
On Dec 14, 2008, at 1:15 AM, Jeremy Huddleston wrote:
So, it looks like the Leopard Screen Sharing.app is working for Brian but not for you... this is most off. Brian, can you confirm that the modifier settings are working as expected with Screen Sharing.app?
I can confirm that X11 modifier keys under the Screen Sharing.app doesn't work for me (including with the newly minted 10.5.6), but CotVNC does. Modifier keys under the Screen Sharing.app hasn't worked for me since 2.3.1-rc1.
I thought this was a reported bug to Apple. It's troubling that they have blamed it on someone else, this bug causes significant usability issues for me with X11. I guess I should file a radar?
It was a previously reported bug, but *I* (not some bigger-than-life "they") closed it and "blamed it on someone else" based on the information in the email you just responded to in which Brian said, "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." After closing the radar, Peter wrote back here (and in the radar) that "hey, wait, that's not right" and I reopened the radar based on his additional information indicating that this *IS* a problem when using 100% apple provided ScreenSharing. If anything, I'd think that the effort going into X11 shows that I'm not trying to ignore bugs and blame other developers. I genuinely want to make X11.app 100% rock solid and feature rich on OSX and made a judgement based on the information provided. Unfortunately this information is a bit convoluted since some people say X works with Y server but not Z server and W works with Z server and not Y server... but since Peter's case is using 100% apple-provided software, we know there's an issue in our stack, so I will be pushing to get it fixed. --Jeremy
On Dec 15, 2008, at 3:44 PM, Jeremy Huddleston wrote:
It was a previously reported bug, but *I* (not some bigger-than-life "they")
You'll forgive my feelings of "Big Brother" towards Radar, the system is rather faceless sometimes to those of us outside of Apple. I hadn't realised that it was your decision, obviously.
If anything, I'd think that the effort going into X11 shows that I'm not trying to ignore bugs and blame other developers. I genuinely want to make X11.app 100% rock solid and feature rich on OSX and made a judgement based on the information provided.
Yes, and my response was not an attack on your work here Jeremy in any way, I sincerely appreciate all the work you've put in to making X11 work on Leopard. I'm glad to hear the problem is back on the active bug list where it belongs. Cheers, Jamie
On 15 Dec 2008, at 21:01, Jamie Kennea wrote:
On Dec 15, 2008, at 3:44 PM, Jeremy Huddleston wrote:
It was a previously reported bug, but *I* (not some bigger-than- life "they")
You'll forgive my feelings of "Big Brother" towards Radar, the system is rather faceless sometimes to those of us outside of Apple. I hadn't realised that it was your decision, obviously.
I find that one of the problems with Radar is that when you report a 'duplicate bug' - then you are dismissed and left in limbo. You can email asking for progress and you do get a reply. But what should happen is that you are 'included', you should be: a) given access to any previous dialogue b) put on the mailing list for the bug. Apple is missing a trick here - if I've reported a bug then I've generally expended energy in researching it and generating evidence and I am quite likely to want to help fix it - but I am excluded. The other problem is that fixes can sometimes take a long time - when I started with Apple I discovered that Mail.app was reporting times in the summer as BDT - and not BST. This smacked of old US Centric date coding in the app itself rather than using the code in the actual underlying operating system that had been working OK for over 20 years. The one good thing Nixon did was mess with US daylight saving time and as a result UNIX got a world quality date system that worked properly everywhere. I reported the Mail.app bug in 2005 - it was a duplicate - it wasn't fixed until Leopard. However, it IS fixed - sometimes good things come to those who wait. I note that most of the bugs I reported when I started were duplicates - and after getting essentially zero response - I stopped reporting bugs until X11 started to be worked on. Well - putting my money where my mouth is - I've filed this in Radar too.. it will probably be a duplicate:-)
On Dec 15, 2008, at 23:40, Peter Collinson wrote:
On 15 Dec 2008, at 21:01, Jamie Kennea wrote:
On Dec 15, 2008, at 3:44 PM, Jeremy Huddleston wrote:
It was a previously reported bug, but *I* (not some bigger-than- life "they")
You'll forgive my feelings of "Big Brother" towards Radar, the system is rather faceless sometimes to those of us outside of Apple. I hadn't realised that it was your decision, obviously.
I find that one of the problems with Radar is that when you report a 'duplicate bug' - then you are dismissed and left in limbo. You can email asking for progress and you do get a reply. But what should happen is that you are 'included', you should be: a) given access to any previous dialogue b) put on the mailing list for the bug.
Apple is missing a trick here - if I've reported a bug then I've generally expended energy in researching it and generating evidence and I am quite likely to want to help fix it - but I am excluded.
The other problem is that fixes can sometimes take a long time - when I started with Apple I discovered that Mail.app was reporting times in the summer as BDT - and not BST. This smacked of old US Centric date coding in the app itself rather than using the code in the actual underlying operating system that had been working OK for over 20 years. The one good thing Nixon did was mess with US daylight saving time and as a result UNIX got a world quality date system that worked properly everywhere. I reported the Mail.app bug in 2005 - it was a duplicate - it wasn't fixed until Leopard. However, it IS fixed - sometimes good things come to those who wait.
I note that most of the bugs I reported when I started were duplicates - and after getting essentially zero response - I stopped reporting bugs until X11 started to be worked on.
Well - putting my money where my mouth is - I've filed this in Radar too.. it will probably be a duplicate:-)
Well... to make you feel better, I think I'll mark mine a duplicate of yours... that way you're still in the loop too ;p
Quoted Peter Collinson <pc@hillside.co.uk>:
Just to refresh memories my bug report is:
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'
there is some more in the report whcih diagnoses the problem.
Well.................... I've just had a response:
I have some ideas of what may be the cause, though I'm not certain. I implemented a VNC widget earlier this year based on what I learned from this protocol document: http://www.realvnc.com/docs/rfbproto.pdf In particular I wonder if the key handling is correct here: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xquartz/X11Application.m?h=... If say the user does: "Shift a" the resulting key may be a symbol A to XQuartz, but really we want it to be: Shift, and a, and to let X11 produce an A if needed. The user should also be able to remap "shift a" to be entirely different than A too (via tools like xmodmap). Some of the X i18n support also relies on the ability to coalesce multiple events into a single event for a composed character (see XFilterEvent and friends). Jeremy, is that how it works now? From page 23 of rfbproto.pdf: "The ?shift state? (i.e. whether either of the Shift keysyms are down) should only be used as a hint when interpreting a keysym. For example, on a US keyboard the ?#? character is shifted, but on a UK keyboard it is not. A server with a US keyboard receiving a ?#? character from a client with a UK keyboard will not have been sent any shift presses. In this case, it is likely that the server will internally need to ?fake? a shift press on its local system, in order to get a ?#? character and not, for example, a ?3?." Peter, what happens with the shift key in the same xterm over VNC? This could also be a bug in the VNC implementation. Another idea (from page 24): "On a viewer where modifiers like Control and Alt can also be used to generate character-based keysyms, the viewer may need to send extra ?release? events in order that the keysym is interpreted correctly." George -- http://people.freedesktop.org/~gstaplin/
On 14 Dec 2008, at 09:25, George Peter Staplin wrote:
Peter, what happens with the shift key in the same xterm over VNC?
What do you need from me to help? Actually I have my UK keyboard set to US - and use Alt-# to generate £ As for Shift For Chicken of VNC - trying just a shift key I get KeyPress event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894124015, (-4,-173), root:(134,262), state 0x0, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894124630, (-4,-173), root:(134,262), state 0x1, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False The press and release events are clearly tied to the keypresses. For Shift Z - I get KeyPress event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894285604, (72,168), root:(210,603), state 0x0, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894288369, (72,168), root:(210,603), state 0x1, keycode 14 (keysym 0x5a, Z), same_screen YES, XLookupString gives 1 bytes: (5a) "Z" XmbLookupString gives 1 bytes: (5a) "Z" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894288371, (72,168), root:(210,603), state 0x1, keycode 14 (keysym 0x5a, Z), same_screen YES, XLookupString gives 1 bytes: (5a) "Z" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0xa00001, root 0x27d, subw 0x0, time 894289597, (72,168), root:(210,603), state 0x1, keycode 64 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False For Screen Sharing.app - I get events in the incorrect order shown by my previous postings. This is to the same instance of xev running on the same remote machine.
participants (6)
-
Andrew Farmer
-
George Peter Staplin
-
Jamie Kennea
-
Jeremy Huddleston
-
Peter Collinson
-
Richard Tobin