Bug 2504 - Default Xvnc xmodmap lists Multi_key in second column, rather than Mode_switch
Summary: Default Xvnc xmodmap lists Multi_key in second column, rather than Mode_switch
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.6.0
Hardware: PC Linux
: P2 Normal
Target Milestone: 4.1.0
Assignee: Pierre Ossman
URL:
Keywords: astrand_tester
Depends on:
Blocks:
 
Reported: 2007-08-13 14:52 CEST by Peter Åstrand
Modified: 2013-05-20 13:49 CEST (History)
0 users

See Also:
Acceptance Criteria:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Peter Åstrand cendio 2007-08-13 14:52:05 CEST 
Transferred from Issue5314. Our hardcoded and default xmodmap in Xvnc has this definition:

    /* 113 */
    XK_Mode_switch,  XK_Multi_key,  NoSymbol,  NoSymbol,

However, when Xvnc is trying to generate a keysym in the 4th column, such as Oslash, it presses shift first, then the Mode_switch, which ends up as Multi_key, (which is used for composing) instead of Mode_switch or ISO_Level3_switch. The result is that an event is generated with "XFilterEvent returns: True", and the applications ignores the event. 

Executing:

xmodmap -e "keycode 113 = Mode_switch Mode_switch"

fixes the problem. However, we should probably change xvnc.cc to contain:


    /* 113 */
    XK_Mode_switch,  XK_Mode_switch,  NoSymbol,  NoSymbol,

rather than:

    /* 113 */
    XK_Mode_switch,  XK_Multi_key,  NoSymbol,  NoSymbol, 

Another alternative would be to list XK_oslash/XK_Ooblique in some other column than the 4th one.
Comment 1 Peter Åstrand cendio 2013-01-24 15:58:42 CET 
This bug does not exist any longer. In revision r25409, the reference to Multi_key was removed. 

(We had a "bugg-2504.sh" workaround on the demo system, which I have now removed.)
Comment 2 Peter Åstrand cendio 2013-05-20 13:49:56 CEST 
There's no Multi_key included in the keymap any longer, at least not by default on RHEL6. I also tried mapping oslash to the "paragraph" key on my workstation, and it generates correctly in the remote session.
Note You need to log in before you can comment on or make changes to this bug.