Revise DOM Level 3 US Layout maps.

ui/events/keycodes/dom_us_layout_data.h

Index: ui/events/keycodes/dom_us_layout_data.h
diff --git a/ui/events/keycodes/dom_us_layout_data.h b/ui/events/keycodes/dom_us_layout_data.h
index c85aef2b85d31960edae46596ad2ca5530ebc8fb..6af5d477882786df24064106f55d9d388736d326 100644
--- a/ui/events/keycodes/dom_us_layout_data.h
+++ b/ui/events/keycodes/dom_us_layout_data.h
@@ -60,7 +60,7 @@ const struct PrintableCodeEntry {
     {DomCode::COMMA, {',', '<'}},
     {DomCode::PERIOD, {'.', '>'}},
     {DomCode::SLASH, {'/', '?'}},
-    {DomCode::INTL_BACKSLASH, {'\\', '|'}},
+    {DomCode::INTL_BACKSLASH, {'<', '>'}},

[Wez, 2015/04/28 00:28:04]

Why do we need this and INTL_YEN, below, if this is a US-only table?

If we need these for some reason then note that this changes means that there's
no single round-trip mapping for this table any more, since < and > exist on
other keys under a US layout, for which this key has no meaning.

I notice we don't have INTL_HASH in here, which is equivalent to these keys, and
would also break the round-trip if added to this table?

Suggest updating the comment on the table to clarify that it is used only by
DomCodeToUsLayoutMeaning() to convert from a code to some sensible printable
character.

[kpschoedel, 2015/04/28 17:03:45]

The keys are normally supported in US layouts, when a keyboard generating them
is present. The pre-change value here ‘\|’ is what the XKB US layouts (from
which I derived the table) generate, and has some history
<http://commons.wikimedia.org/wiki/File:IBM_Model_F_XT.png>. The ‘<>’ value also
has history <http://deskthority.net/wiki/File:LK201AA_top.jpg>, but the change
here is because GetCharacterFromKeyCode() returns ‘<>’ for the corresponding
VKEY_OEM_102. (MS helpfully says that VK_OEM_102 is ‘"<>" or "\|" on RT 102-key
keyboard’.) I'd be comfortable using ‘\|’ and changing GetCharacterFromKeyCode()
and the test to match. I'm pretty sure nothing actually depends on the mapping.
Right, but there has never been round-trip mapping for characters, because of
numpad keys.
Added. It wasn't in keycode_converter_data.h, but should be now that we use it
for DOM3 |code|, since 'IntlHash' exists there.
Done.

[Wez, 2015/05/05 00:16:00]

Mapping from VKEY to |code| is a legacy-compatibility special-case, so we should
be best-effort about supporting it.  To do this "properly" we'd need to know the
keyboard's physical layout so we can un-pick the VKEY or OEM-scancode back into
the "correct" USB/DOM-code value... :(

[kpschoedel, 2015/05/05 18:47:02]

Acknowledged — will keep GetCharacterFromKeyCode()'s values.

     {DomCode::INTL_YEN, {0x00A5, '|'}},
     {DomCode::NUMPAD_DIVIDE, {'/', '/'}},
     {DomCode::NUMPAD_MULTIPLY, {'*', '*'}},
@@ -580,7 +580,6 @@ const struct DomCodeToKeyboardCodeEntry {
 const DomCodeToKeyboardCodeEntry kFallbackKeyboardCodeToDomCodeMap[] = {
     {DomCode::ALT_LEFT, VKEY_MENU},
     {DomCode::ALT_RIGHT, VKEY_ALTGR},
-    {DomCode::BACKQUOTE, VKEY_DBE_SBCSCHAR},
 #if defined(OS_POSIX)
     {DomCode::CONTEXT_MENU, VKEY_COMPOSE},
 #endif
@@ -589,11 +588,12 @@ const DomCodeToKeyboardCodeEntry kFallbackKeyboardCodeToDomCodeMap[] = {
     {DomCode::LANG2, VKEY_HANJA},
     {DomCode::LANG5, VKEY_DBE_DBCSCHAR},
     {DomCode::NUMPAD_CLEAR, VKEY_OEM_CLEAR},
+    {DomCode::NUMPAD_DECIMAL, VKEY_SEPARATOR},
     {DomCode::PROPS, VKEY_CRSEL},
     {DomCode::SHIFT_LEFT, VKEY_SHIFT},
     {DomCode::SUPER, VKEY_OEM_8},
     //
-    // VKEYs with no existing corresponding DomCode, but a USB usage code:
+    // VKEYs with no directly corresponding DomCode, but a USB usage code:

[Wez, 2015/04/28 00:28:04]

Why do we have a DomCode::<name> in the comment for these, if they have no
corresponding DOM |code| value to map to?

[kpschoedel, 2015/04/28 17:03:45]

Left over from the (scripted) table entries. Removed.

     //  {DomCode::SYS_REQ, VKEY_ATTN},          // 0x07009A SysReq
     //  {DomCode::SEPARATOR, VKEY_SEPARATOR},   // 0x07009F Separator

[Wez, 2015/04/28 00:28:04]

Remove this?

[kpschoedel, 2015/04/28 17:03:45]

Done.

     //  {DomCode::EX_SEL, VKEY_EXSEL},          // 0x0700A4 ExSel
@@ -603,20 +603,23 @@ const DomCodeToKeyboardCodeEntry kFallbackKeyboardCodeToDomCodeMap[] = {
     //  {DomCode::MEDIA_FAST_FORWARD, VKEY_OEM_104},
     //                                          // 0x0C00B3 MediaFastForward
     //
+    // VKEYs with no corresponding DomCode, but a Linux evdev usage code:
+    //  VKEY_KBD_BRIGHTNESS_DOWN                //  evdev KEY_KBDILLUMDOWN
+    //  VKEY_KBD_BRIGHTNESS_UP                  //  evdev KEY_KBDILLUMUP
+    //  VKEY_WLAN                               //  evdev KEY_WLAN
+    //
     // VKEYs with no corresponding DomCode and no obvious USB usage code:
     //  VKEY_ACCEPT
     //  VKEY_BACKTAB
+    //  VKEY_DBE_SBCSCHAR
     //  VKEY_EREOF
     //  VKEY_FINAL
     //  VKEY_JUNJA
-    //  VKEY_KBD_BRIGHTNESS_DOWN
-    //  VKEY_KBD_BRIGHTNESS_UP
     //  VKEY_MODECHANGE
     //  VKEY_NONAME
     //  VKEY_PA1
     //  VKEY_PACKET
     //  VKEY_PROCESSKEY
-    //  VKEY_WLAN
 };
 
 }  // namespace ui