altgr / nxclient / compose key

altgr / nxclient / compose key

  • Written by
    Walter Doekes
  • Published on

Like various reports on the internet suggest, the AltGr compose key doesn’t work properly or not at all from an NXClient connected to an NXServer (FreeNX in my case).

Note that this is a different issue from the one where Alt_R (and Super_L, Super_R, Ctrl_R en Menu) remains pressed after which no normal typing is possible. That issue is described in Alt Gr keeps stuck and involves a new int sendKey = 0; in nxagent that should be reverted.

I run Ubuntu Lucid Lynx on my desktop with the NXClient, and we run the same on the terminal server. Normally getting the Compose Key to work is simple: go to the System menu, then Preferences, then Keyboard. Choose Layouts, Options and set the Compose Key to Right Alt:

Keyboard Preferences: composekey

However, on the server this has no effect. When comparing output of the xev(1) program, we see the following when pressing AltGr, single-quote, e (to get é):

$ diff -uw client_xev server_xev
--- client_xev 2010-08-02 12:38:23.923838872 +0200
+++ server_xev 2010-08-02 12:44:50.843839010 +0200
@@ -1,11 +1,11 @@
 KeyPress event, serial NN, synthetic NO, window 0xXXX,
-    state 0x10, keycode 108 (keysym 0xff20, Multi_key), same_screen YES,
+    state 0x10, keycode 113 (keysym 0xffea, Alt_R), same_screen YES,
     XLookupString gives 0 bytes:
     XmbLookupString gives 0 bytes:
-    XFilterEvent returns: True
+    XFilterEvent returns: False

 KeyRelease event, serial NN, synthetic NO, window 0xXXX,
-    state 0x10, keycode 108 (keysym 0xff20, Multi_key), same_screen YES,
+    state 0x18, keycode 113 (keysym 0xffea, Alt_R), same_screen YES,
     XLookupString gives 0 bytes:
     XFilterEvent returns: False

@@ -13,7 +13,7 @@
     state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
     XLookupString gives 1 bytes: (27) "'"
     XmbLookupString gives 1 bytes: (27) "'"
-    XFilterEvent returns: True
+    XFilterEvent returns: False

 KeyRelease event, serial NN, synthetic NO, window 0xXXX,
     state 0x10, keycode 48 (keysym 0x27, apostrophe), same_screen YES,
@@ -24,12 +24,6 @@
     state 0x10, keycode 26 (keysym 0x65, e), same_screen YES,
     XLookupString gives 1 bytes: (65) "e"
     XmbLookupString gives 1 bytes: (65) "e"
-    XFilterEvent returns: True
-
-KeyPress event, serial NN, synthetic NO, window 0xXXX,
-    state 0x10, keycode 0 (keysym 0xe9, eacute), same_screen YES,
-    XLookupString gives 0 bytes:
-    XmbLookupString gives 2 bytes: (c3 a9) "é"
     XFilterEvent returns: False

 KeyRelease event, serial NN, synthetic NO, window 0xXXX,

Two things stand out here:
(1) The right alt press is seen as Alt_R and not Multi_key and XFilterEvent returns False (meaning that the receiving application should take action on the keypress).
(2) The keycode observed is 113 instead of 108.

This information is enough to fix the issue. First get the Multi_key setting for xmodmap(1):

$ xmodmap -pke | grep Multi_key
keycode 108 = Multi_key Multi_key Multi_key Multi_key

Put that line in ~/.xmodmaprc on the server, changing the 108 to 113. You test if it works by running xmodmap(1) manually with the .xmodmaprc as argument. If everything works like it should, you should now have a working compose key again: ¡Vìctørý!


Back to overview Newer post: nxclient / locale passing Older post: python2.6 features / python2.5