Fixed odd behavior for keyboards using the AL_CONSUMER_CONTROL_CONFIG

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 742 matching lines @@
     case XK_guillemotleft:
     case XK_guillemotright:
     case XK_degree:
     // In the case of canadian multilingual keyboard layout, VKEY_OEM_102 is
     // assigned to ugrave key.
     case XK_ugrave:
     case XK_Ugrave:
     case XK_brokenbar:
       return VKEY_OEM_102;  // international backslash key in 102 keyboard.
 
     // When evdev is in use, /usr/share/X11/xkb/symbols/inet maps F13-18 keys

[Wez, 2014/08/06 21:17:53]

nit: Update this comment.

     // to the special XF86XK symbols to support Microsoft Ergonomic keyboards:
     // https://bugs.freedesktop.org/show_bug.cgi?id=5783
     // In Chrome, we map these X key symbols back to F13-18 since we don't have
     // VKEYs for these XF86XK symbols.
-    case XF86XK_Tools:
-      return VKEY_F13;
     case XF86XK_Launch5:
       return VKEY_F14;
     case XF86XK_Launch6:
       return VKEY_F15;
     case XF86XK_Launch7:
       return VKEY_F16;
     case XF86XK_Launch8:
       return VKEY_F17;
     case XF86XK_Launch9:
       return VKEY_F18;
 
+    // this was mapped to VKEY_F13 (see above), but this was causing odd

[Wez, 2014/08/06 21:17:53]

nit: Capitalization.

+    // behavior (trig lock screen) with all keyboard that send this usage
+    // in order to launch the media player(supported on Windows, Android)
+    // (see crbug=398345)

[Wez, 2014/08/06 21:17:53]

nit: Rather than describe the bug, describe the logic behind mapping "Tools" to
"Select Media", i.e. why this mapping? 

[mmeisser, 2014/08/07 17:46:41]

I will describe the mapping. This seems odd, but already the XK86XK_Tools is a
weird naming for AL_CONSUMER_CONTROL_CONFIG (0x0C 0x0183) in the first place.
The second weird thing is that this is used in Windows and Android in order to
launch a media player app. Multiple keyboards in the field (not only logitech's)
are using this usage on a hotkey with a music icon.

+    case XF86XK_Tools:

[Wez, 2014/08/06 21:17:53]

Can you move this to the appropriate order in this switch, i.e. near to whatever
the closest other XK values handled are?

[mmeisser, 2014/08/07 17:46:41]

The actual list of XK mappings are not really ordered in terms of values, rather
on meaning/features. But I guess putting this closer to launchA & co makes sense
since
those are the closer values and do belong to the same feature-set (ie launch an
app).

+      return VKEY_MEDIA_LAUNCH_MEDIA_SELECT;
+
     // For supporting multimedia buttons on a USB keyboard.
     case XF86XK_Back:
       return VKEY_BROWSER_BACK;
     case XF86XK_Forward:
       return VKEY_BROWSER_FORWARD;
     case XF86XK_Reload:
       return VKEY_BROWSER_REFRESH;
     case XF86XK_Stop:
       return VKEY_BROWSER_STOP;
     case XF86XK_Search:
@@ skipping 557 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