If keysym is ASCII control or space keys, directly map to keycode.

ui/events/keycodes/keyboard_code_conversion_x.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/events/keycodes/keyboard_code_conversion_x.h"
 
 #include <algorithm>
 
 #define XK_3270  // for XK_3270_BackTab
 #include <X11/XF86keysym.h>
@@ skipping 441 matching lines @@
 
 template <class T_MAP>
 KeyboardCode FindVK(const T_MAP& key, const T_MAP* map, size_t size) {
   T_MAP comp = {0};
   const T_MAP* p = std::lower_bound(map, map + size, key, comp);
   if (p != map + size && !comp(*p, key) && !comp(key, *p))
     return static_cast<KeyboardCode>(p->vk);
   return VKEY_UNKNOWN;
 }
 
+// Check for ASCII Control or space keys which should directly map to key code
+// instead of stripping the modifier states and go through the fallback maps.

[Wez, 2014/10/24 22:29:18]

_Why_ should they do this, though?

What would Ctrl+Space result in without this fix?

What are the VKEYs we intend  to generate instead as a result of this?
KeyboardCodeFromXKeysym doesn't seem to have mappings for 0xff01-0xff1f, so
won't we generate VK_UNKNOWN...?

[Wez, 2014/10/24 22:31:22]

The example you give in CL description is AltGr+V -> Enter - but Enter isn't a
control nor space key, so won't match this case, nor is 'V'..?

[Shu Chen, 2014/10/25 05:46:19]

Enter is an ascii control key: keysym=0xff0d (XK_Return).

[Shu Chen, 2014/10/25 05:46:19]

The range 0xff01-0xff1f contains XK_Tab, XK_Return, XK_Backspace, etc. so
KeyboardCodeFromXKeysym can give out correct VKEYs.

+bool IsAsciiControlOrSpaceKey(KeySym keysym) {
+  // 0xff01 to 0xff1f (instead of 0x01 to 0x1f) represent ASCII control in
+  // keysym world.
+  return (keysym > 0xff00 && keysym <= 0xff1f) || keysym == XK_Delete ||
+      keysym == XK_Escape || keysym == XK_space;
+}
+
 }  // namespace
 
 // Get an ui::KeyboardCode from an X keyevent
 KeyboardCode KeyboardCodeFromXKeyEvent(const XEvent* xev) {
   // Gets correct VKEY code from XEvent is performed as the following steps:
   // 1. Gets the keysym without modifier states.
   // 2. For [a-z] & [0-9] cases, returns the VKEY code accordingly.
   // 3. Find keysym in map0.
   // 4. If not found, fallback to find keysym + hardware_code in map1.
   // 5. If not found, fallback to find keysym + keysym_shift + hardware_code
@@ skipping 13 matching lines @@
   } else {
     xkeyevent.xkey = xev->xkey;
   }
   KeyboardCode keycode = VKEY_UNKNOWN;
   XKeyEvent* xkey = &xkeyevent.xkey;
   // XLookupKeysym does not take into consideration the state of the lock/shift
   // etc. keys. So it is necessary to use XLookupString instead.
   XLookupString(xkey, NULL, 0, &keysym, NULL);
   if (IsKeypadKey(keysym) || IsPrivateKeypadKey(keysym) ||
       IsCursorKey(keysym) || IsPFKey(keysym) || IsFunctionKey(keysym) ||
-      IsModifierKey(keysym)) {
+      IsModifierKey(keysym) || IsAsciiControlOrSpaceKey(keysym)) {
     return KeyboardCodeFromXKeysym(keysym);
   }
 
   // If |xkey| has modifiers set, other than NumLock, then determine the
   // un-modified KeySym and use that to map, so that e.g. Ctrl+D correctly
   // generates VKEY_D.
   if (xkey->state & 0xFF & ~Mod2Mask) {
     xkey->state &= (~0xFF | Mod2Mask);
     XLookupString(xkey, NULL, 0, &keysym, NULL);
   }
@@ skipping 852 matching lines @@
   // alone does not map to XK_less; XKeysymToKeycode() returns KEY_102ND
   // (the '<>' key between Shift and Z on 105-key keyboards) which does.
   //
   // crbug.com/386066 and crbug.com/390263 are examples of problems
   // associated with this.
   //
   return XKeysymToKeycode(display, XKeysymForWindowsKeyCode(key_code, false));
 }
 
 }  // namespace ui