--- $xmodmap -pke|grep Z keycode 63 = z Z $xmodmap -e 'keycode 63 = Greek_zeta Greek_ZETA' --- 4. Go to the st window started in step 2. 5. Press the Z key. EXPECTED: 6. A ζ character is produced. ACTUAL: 6. A z character is produced. 7. Restore your setup. --- $xmodmap -e 'keycode 63 = z Z' --- While the above example might be a bit contrived, the problem happens frequently in the wild. This is how: 1. The user presses a key on the client and a keyevent is sent to vncclient by the local OS. 2. Irrespective of what platform the VNC Client is running on, per the VNC standard it translates the local native keyevent to an X11 Keysym in integer form, and transmits this to the connected VNC Server. 3. The VNC Server, which is also an X Server, translates the Keysym to a corresponding key code according to its own (server-side) keymap. If no such code exists, it will first remap an empty key code to the received Keysym, which produces a MappingNotify event that is sent to all connected X clients. It would appear that some applications handle the MappingNotify event to synchronize their keymaps to that of the X Server while others, like st, don't. At this point, the non-conforming applications' keymap is out of sync with that of the X Server. 4. The (remote VNC and) X Server produces a KeyEvent using the potentially newly mapped key code. 5. A receiving application handles the KeyEvent, typically by translating it to the corresponding Keysym. In case the application's and X Server's keymaps are out of sync, the application might produce an erroneous Keysym.Received on Thu Jan 24 2019 - 23:41:47 CET
This archive was generated by hypermail 2.3.0 : Thu Jan 24 2019 - 23:48:22 CET