Wrong keysyms sent - XK_2 instead of XK_at
Project superseded by http://chicken.sourceforge.net/
Brought to you by:
smeger
It seems like the keyboard implementation in Cotvnc
2.0b4 is incorrectly designed. When I press Alt+2 on a
Swedish keyboard to generate a "@", the keysyms sent
via VNC are:
down XK_Meta_L
down XK_2
up XK_2
up XK_Meta_L
This is incorrect: it's XK_at that should be
transmitted, not XK_2. The same type of problem exists
for other symbols such as:
'
`
^
"
|
For reference, see
http://www.realvnc.com/docs/rfbproto.pdf.
newtgb.patch
Logged In: YES
user_id=344921
I've done a fairly large overhaul of the keyboard
implementation. The attached patch solves the problem in
this bug description, as well as several other problems:
* It is now possible to enter symbols using the Option
modifier, such as "@" on a swedish keyboard (Option-2).
* Dead keys are now supported, since Cotvnc now implements
the NSTextInput protocol. The code is prepared for full
input method support, which is required for
Hiragana/Katakana etc. A few things are missing for this,
though; keyboard events are still sent from keyDown
rather than insertText. Using input methods over VNC
probably needs some thought.
* RFBConnection.m was using two large tables with hardcoded
keysym values. There were also several other keysym
constants spread out over different files. This is very hard
to maintain. I've added keysymdef.h to the project and
replaced the custom constants.
In general, I believe the keyboard code is much more sound
now. Being able to enter symbols such as "@" and "~", even
when using international keyboards, is crucial so I hope
that this patch can be applied in a near future.
I invite all listeners to test this patch and report any
problems found.
Logged In: YES
user_id=344921
Note: The attached patch doesn't modify "Chicken of the
VNC.xcodeproj" so that keysymdef.h gets included, since the
patch format isn't able to cope with whitespace characters,
at least not on my Fedora system.
Logged In: YES
user_id=815112
I can verify that this works as intended: With CotVNC 2.04b the keyboard
handling is indeed broken (Mac OS X 10.4.8, Swedish keyboard layout) and no
Alt-combined characters appear correctly. With this patch however, it works
flawlessly. Thank you Åstrand!
Logged In: YES
user_id=815112
Additional information: It seems as if @,$ and other such alt-modified
characters are not recognized by Firefox. Evolution and the gnome-terminal
interprets them correctly though. Is this in any way related to cotvnc?
Logged In: YES
user_id=344921
>Additional information: It seems as if @,$ and other such
>alt-modified characters are not recognized by Firefox.
>Evolution and the gnome-terminal interprets them correctly
>though. Is this in any way related to cotvnc?
This is probably an issue of modifier keys. Which
Xserver/Xvnc are you running, and what's the output of
"xmodmap"? By default, CotVNC uses Meta as the modifier for
the Option key. This might interfere with X11, if Meta is
setup as a modifier. The version of Cotvnc that Cendio ships
in ThinLinc is altered so that "Windows" (that is, "Super")
is used instead; this is a safer choice.
Logged In: NO
Also - there is no support for å, ä, ö and if I copy a
webbadress, and use the paste in-function from the menu -
all the / has become + instead.
Logged In: YES
user_id=344921
>Also - there is no support for å, ä, ö and if I copy a
>webbadress, and use the paste in-function from the menu -
>all the / has become + instead.
This seems strange; I've explicitly tested åäö. Have you
tested a CotVNC version with this patch applied? Which
server are you using?
Logged In: YES
user_id=344921
Originator: YES
I'm still waiting for this patch to be applied. In the meantime, you can grab binaries from http://www.cendio.se/~astrand/cotvnc/.
Logged In: YES
user_id=351330
Originator: NO
Peter, your patch kills a connection to Apple's default VNC implementation on Tiger when I try to send option-e, e on a US keyboard. The option e shows up fine on the other end (I get the indication that the next character to be sent will be accented), but the subsequent "e" causes the connection to die.
Also, what happens with pasteString: in EventFilter.m? Does it need to be decomposed and go through the translateNonControl:charactersIgnoringModifiers: selector somehow?
Logged In: YES
user_id=344921
Originator: YES
>Peter, your patch kills a connection to Apple's default VNC implementation on Tiger when I try to send option-e, e on a US keyboard. The option e
>shows up fine on the other end (I get the indication that the next character to be sent will be accented), but the subsequent "e" causes the connection to die.
True, I've been able to reproduce this. It seems like the server is crashing or disconnecting. One problem with Apples Remote Desktop is that it's not really VNC compatible (see http://www.realvnc.com/pipermail/vnc-list/2006-September/055898.html\), but I guess we are trying to be compatible anyway?
With the patch, CotVNC sends:
XK_Meta_L down
XK_eacute down
XK_eacute up
XK_Meta_L up
which is fully correct, according to the VNC protocol, as far as I understand. I don't know why ARD bails out on this.
Does accented e work without my patch? With some other VNC or ARD client?
About pasteString: I haven't changed it, but you think it might need adaption? Good question, I don't know. Does pasting work correctly?
Logged In: YES
user_id=351330
Originator: NO
Yes, both Apple's ARD and OSXVnc work fine without the patch applied. I did the majority of my testing against those two servers and RealVNC.
I think that both of the OS X servers expect to see "e down" and "e up" rather than "e acute down" and "e acute up". But what's interesting to me is that ARD dies on the "e" _following_ the accented one.
meta down
e down
e up
meta up
e down
-crash-
Logged In: NO
I would like to use Åstrands patch. However, i'm not a programmer - the downloaded patch file doesn't seem to be something easily installable ;-)
Questionmarks as well as dashes (as well as Swedish ÅÄÖ) do not transfer properly. (With OSXvnc)
anders.grassman@trivselgodis.se
Logged In: YES
user_id=344921
Originator: YES
I think we need to implement some kind of workaround for the ARD case. Does CotVNC detect if the server is ARD or VNC?
Logged In: YES
user_id=681913
Originator: NO
Hi!
I tried the patched version 2.04b (both the binary version from www.denicos as well as compiled from source), but the keys @|\~ and other option-key produced symbols do not work.
I am using a MacBook (13" white, 2.16GHz Intel, German keyboard and language settings) with Mac OS X 10.4.10 as client and try to connect to a "Xvnc Free Edition 4.1.1 - built Feb 26 2007 20:43:44 - Copyright (C) 2002-2005 RealVNC Ltd." server runing on Debian 4.
Modifiers in CoTVNC are configured as follows:
Command -> Meta (Option)
Option -> Alt (Command)
Control -> Control
Shift -> Shift
Emulation s configured as follows:
Center Mouse Button: Modifier Click, "Option" Key
Right Mouse Button: Modifier Click, "Command" Key
(With these settings, CoTVNC should behave like Apples X11.app)
Pressing the option key and an other key to compse e.g. @ or | does not produce the desired key. Running "xev" on the remote side and typing option-l (should result in a "@") shows:
---------------------- First, unpatched version ---------
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185192981, (1,75), root:(823,261),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185192981, (1,75), root:(823,261),
state 0x8, keycode 46 (keysym 0x6c, l), same_screen YES,
XLookupString gives 1 bytes: (6c) "l"
XmbLookupString gives 1 bytes: (6c) "l"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185193055, (1,75), root:(823,261),
state 0x8, keycode 46 (keysym 0x6c, l), same_screen YES,
XLookupString gives 1 bytes: (6c) "l"
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185193372, (1,75), root:(823,261),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
---------------------- Same key sequence with the patched version ---------
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185991882, (2,118), root:(824,304),
state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185991882, (2,118), root:(824,304),
state 0x8, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185991882, (2,118), root:(824,304),
state 0x9, keycode 11 (keysym 0x40, at), same_screen YES,
XLookupString gives 1 bytes: (40) "@"
XmbLookupString gives 1 bytes: (40) "@"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185991882, (2,118), root:(824,304),
state 0x9, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185991970, (2,118), root:(824,304),
state 0x8, keycode 11 (keysym 0x32, 2), same_screen YES,
XLookupString gives 1 bytes: (32) "2"
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3185993394, (2,118), root:(824,304),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
-----------------------------------------------------------------------
In the XTerm at the remote side eith appears nothing or an "ì", depending on the utf-8 setting of the terminal.
Using the X11-based vncviewer from www.macports.org, these keys work and generate the following even sequence
---------------------- Same key sequence with X11-base vncviwer (macports.org) ---------
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186808058, (1,103), root:(823,289),
state 0x0, keycode 240 (keysym 0xff7e, Mode_switch), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186811210, (1,103), root:(823,289),
state 0x0, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186811210, (1,103), root:(823,289),
state 0x1, keycode 11 (keysym 0x40, at), same_screen YES,
XLookupString gives 1 bytes: (40) "@"
XmbLookupString gives 1 bytes: (40) "@"
XFilterEvent returns: False
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186811210, (1,103), root:(823,289),
state 0x1, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186811298, (1,103), root:(823,289),
state 0x0, keycode 11 (keysym 0x32, 2), same_screen YES,
XLookupString gives 1 bytes: (32) "2"
KeyRelease event, serial 30, synthetic NO, window 0xe00001,
root 0x2e, subw 0x0, time 3186813682, (1,103), root:(823,289),
state 0x0, keycode 240 (keysym 0xff7e, Mode_switch), same_screen YES,
XLookupString gives 0 bytes:
-----------------------------------------------------------------------
I hope this helps to solve to problem. Please let me know if I can further help in sorting this out. (I am really new to the Mac OS X world, but I have several years of coding experience on linux.)