Menu

#10 Wrong keysyms sent - XK_2 instead of XK_at

open
nobody
None
5
2007-03-16
2006-09-19
No

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.

Discussion

  • Peter Åstrand

    Peter Åstrand - 2006-09-28

    newtgb.patch

     
  • Peter Åstrand

    Peter Åstrand - 2006-09-28

    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.

     
  • Peter Åstrand

    Peter Åstrand - 2006-09-28

    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.

     
  • Ola Leifler

    Ola Leifler - 2006-09-30

    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!

     
  • Ola Leifler

    Ola Leifler - 2006-09-30

    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?

     
  • Peter Åstrand

    Peter Åstrand - 2006-10-02

    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.

     
  • Nobody/Anonymous

    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.

     
  • Peter Åstrand

    Peter Åstrand - 2006-11-02

    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?

     
  • Peter Åstrand

    Peter Åstrand - 2007-02-06

    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/.

     
  • Jason Harris

    Jason Harris - 2007-03-16
    • milestone: 427031 -->
     
  • Jason Harris

    Jason Harris - 2007-03-16

    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?

     
  • Peter Åstrand

    Peter Åstrand - 2007-03-22

    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?

     
  • Jason Harris

    Jason Harris - 2007-03-22

    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-

     
  • Nobody/Anonymous

    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

     
  • Peter Åstrand

    Peter Åstrand - 2007-05-10

    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?

     
  • Bjoern Kahl

    Bjoern Kahl - 2007-08-31

    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.)

     

Log in to post a comment.