Fix some surprising reverse key mappings.

ui/events/keycodes/keyboard_code_conversion_x.cc

Index: ui/events/keycodes/keyboard_code_conversion_x.cc
diff --git a/ui/events/keycodes/keyboard_code_conversion_x.cc b/ui/events/keycodes/keyboard_code_conversion_x.cc
index 0a226fcef288331b983ee292914fcd5ab7bb0d76..e6686bcd38d19cc75ea1c3980aac4abd3a542509 100644
--- a/ui/events/keycodes/keyboard_code_conversion_x.cc
+++ b/ui/events/keycodes/keyboard_code_conversion_x.cc
@@ -1276,4 +1276,30 @@ int XKeysymForWindowsKeyCode(KeyboardCode keycode, bool shift) {
     }
 }
 
+unsigned int XKeyCodeForWindowsKeyCode(ui::KeyboardCode key_code,

[kpschoedel, 2014/07/14 18:41:21]

Function moved from ui/events/test/events_test_utils_x11.cc — no changes to
code, only comments.

+                                       int flags,
+                                       XDisplay* display) {
+  // SHIFT state is ignored in the call to XKeysymForWindowsKeyCode() here
+  // because we map the XKeysym back to a keycode, i.e. a physical key position.
+  // Using a SHIFT-modified XKeysym would sometimes yield X keycodes that,
+  // while technically valid, may be surprising in that they do not match
+  // the keycode of the original press, and conflict with assumptions in
+  // other code.
+  //
+  // For example, in a US layout, Shift-9 has the interpretation XK_parenleft,
+  // but the keycode KEY_9 alone does not map to XK_parenleft; instead,
+  // XKeysymToKeycode() returns KEY_KPLEFTPAREN (keypad left parenthesis)
+  // which does map to XK_parenleft -- notwithstanding that keyboards with
+  // dedicated number pad parenthesis keys are currently uncommon.
+  //
+  // Similarly, Shift-Comma has the interpretation XK_less, but KEY_COMMA
+  // 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));

[Shu Chen, 2014/07/15 04:23:55]

XKeysymForWindowsKeyCode() method doesn't consider other latin language layouts,
especially for VKEY_OEM_[1-8].

Although I'm not sure whether it would be a big deal to make accurate conversion
from VKEY to keysym, I have a little concern for shortcut key "Ctrl+Alt+/",
which is to show the key mapping on screen.
On US layout, "/" key is VK_OEM_2; but on FR layout, VK_OEM_2 is "." key with
":" keysym.
And DE layout, VK_OEM_2 is "\" key with "#" keysym.

[kpschoedel, 2014/07/15 14:35:05]

I agree. Changing the keyboard event rewriting to a ui::EventRewriter made it
necessary to map back to the X keycode, because some event consumers still need
it, but after crbug.com/380349 that should no longer be necessary.

[Shu Chen, 2014/07/15 14:42:12]

Got it. I think it's ok for a temporary fix. And you don't need my lgtm so
removing myself from the reviews.


On 2014/07/15 14:35:05, kpschoedel wrote:

+}
+
 }  // namespace ui