Fix Ozone keyboard layout to handle German Neo 2.

ui/events/ozone/evdev/keyboard_evdev.cc

Index: ui/events/ozone/evdev/keyboard_evdev.cc
diff --git a/ui/events/ozone/evdev/keyboard_evdev.cc b/ui/events/ozone/evdev/keyboard_evdev.cc
index 1def4c66a8bef5977b6066af3636e5516bfbb436..96eeeb0ed71c559746c1383ffec830d75d528456 100644
--- a/ui/events/ozone/evdev/keyboard_evdev.cc
+++ b/ui/events/ozone/evdev/keyboard_evdev.cc
@@ -18,6 +18,15 @@
 
 namespace ui {
 
+// We can't include ui/events/keycodes/dom/dom_code.h here because of
+// conflicts with preprocessor macros in <linux/input.h>, so we use the
+// same underlying data with an additional prefix.

[Wez, 2015/06/08 21:23:23]

nit: Is there some easy way to fix that issue in dom_code.h instead?

[kpschoedel, 2015/06/08 22:30:02]

I believe we could rename the DomCode constants for letters from DomCode::KEY_X
to just DomCode::X, since the conflicts are with preprocessor macros of the form
KEY_X. (That would touch many files, mostly tests, so I'd rather make it a
separate rename-only CL to simplify reviewing.) For the most part the DomCode
and DomKey enum constants are direct conversions of the W3C strings, but there
are already some exceptions arising from other name conflicts (DEL rather than
DELETE and FN_LOCK rather than F_LOCK).

[Wez, 2015/06/10 23:24:49]

Acknowledged.

+#define USB_KEYMAP(usb, xkb, win, mac, code, id) DOM_CODE_ ## id = usb
+#define USB_KEYMAP_DECLARATION enum class DomCode
+#include "ui/events/keycodes/dom/keycode_converter_data.inc"
+#undef USB_KEYMAP
+#undef USB_KEYMAP_DECLARATION
+
 namespace {
 
 const int kRepeatDelayMs = 500;
@@ -35,6 +44,8 @@ int EventFlagToEvdevModifier(int flag) {
       return EVDEV_MODIFIER_ALT;
     case EF_ALTGR_DOWN:
       return EVDEV_MODIFIER_ALTGR;
+    case EF_MOD3_DOWN:
+      return EVDEV_MODIFIER_MOD3;
     case EF_LEFT_MOUSE_BUTTON:
       return EVDEV_MODIFIER_LEFT_MOUSE_BUTTON;
     case EF_MIDDLE_MOUSE_BUTTON:
@@ -201,9 +212,7 @@ void KeyboardEvdev::DispatchKey(unsigned int key,
                                 int device_id) {
   DomCode dom_code =
       KeycodeConverter::NativeKeycodeToDomCode(EvdevCodeToNativeCode(key));
-  // DomCode constants are not included here because of conflicts with
-  // evdev preprocessor macros.
-  if (!static_cast<int>(dom_code))
+  if (dom_code == DomCode::DOM_CODE_NONE)
     return;
   int flags = modifiers_->GetModifierFlags();
   DomKey dom_key;
@@ -214,8 +223,15 @@ void KeyboardEvdev::DispatchKey(unsigned int key,
                                        &key_code, &platform_keycode)) {
     return;
   }
-  if (!repeat)
-    UpdateModifier(ModifierDomKeyToEventFlag(dom_key), down);
+  if (!repeat) {
+    int flag = ModifierDomKeyToEventFlag(dom_key);
+    UpdateModifier(flag, down);
+    // X11 XKB, using the configuration as modified for ChromeOS, always sets
+    // EF_MOD3_DOWN for the physical CapsLock key, so we imitate this to make
+    // certain layouts work. crbug.com/495277

[Wez, 2015/06/08 21:23:23]

nit: Consider explicitly saying "even if it is re-mapped to e.g. Search or
Control".

OTOH, the X11 XKB behaviour sounds broken to me... ;)

[kpschoedel, 2015/06/08 22:30:02]

Done.

The pure-X11 behaviour is fine, but the ChromeOS hybrid model, with patched XKB
configuration and modifier handling mixed between X11 and Chrome, is fragile,
and I'll be glad when all devices are Freonized and some of the hacks can be
undone.

[Wez, 2015/06/10 23:24:49]

Acknowledged.

+    if (dom_code == DomCode::DOM_CODE_CAPS_LOCK)
+      UpdateModifier(EF_MOD3_DOWN, down);
+  }
 
   KeyEvent event(down ? ET_KEY_PRESSED : ET_KEY_RELEASED, key_code, dom_code,
                  modifiers_->GetModifierFlags(), dom_key, character, timestamp);
@@ -224,5 +240,4 @@ void KeyboardEvdev::DispatchKey(unsigned int key,
     event.set_platform_keycode(platform_keycode);
   callback_.Run(&event);
 }
-
 }  // namespace ui