Implement the content/renderer and content/browser part of the Device Motion API.

content/common/device_motion_hardware_buffer.h

Index: content/common/device_motion_hardware_buffer.h
diff --git a/content/common/device_motion_hardware_buffer.h b/content/common/device_motion_hardware_buffer.h
new file mode 100644
index 0000000000000000000000000000000000000000..ac63d88deb9a1212b124d6aeb4b80b34466cab7c
--- /dev/null
+++ b/content/common/device_motion_hardware_buffer.h
@@ -0,0 +1,37 @@
+// Copyright (c) 2013 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.
+
+#ifndef CONTENT_COMMON_DEVICE_MOTION_HARDWARE_BUFFER_H_
+#define CONTENT_COMMON_DEVICE_MOTION_HARDWARE_BUFFER_H_
+
+#include "content/common/gamepad_seqlock.h"
+#include "third_party/WebKit/Source/Platform/chromium/public/WebDeviceMotionData.h"
+
+namespace content {
+
+/*

[jamesr, 2013/05/16 19:53:05]

we pretty much never use /* style comments in chromium

[timvolodine, 2013/05/20 18:18:48]

it is actually used in gamepad_hardware_buffer, on which this class is based.
I've changed it to // comments on each line.

+This structure is stored in shared memory that's shared between the browser
+which does the hardware polling, and the consumers of the device motion
+data, i.e. the renderers. The performance characteristics are that
+we want low latency (so would like to avoid explicit communication via IPC
+between producer and consumer) and relatively large data size.
+
+Writer and reader operate on the same buffer assuming contention is low, and
+contention is detected by using the associated SeqLock.
+*/
+
+struct DeviceMotionHardwareBuffer {
+  GamepadSeqLock sequence;

[jamesr, 2013/05/16 19:53:06]

Gamepad? What does this have to do with game pad?

[timvolodine, 2013/05/20 18:18:48]

As a first step the GamepadLock can be used for shared buffer sync. In a
subsequent step we can implement a generalization of this (as noted in the
GamepadLock itself).

Also, does it make sense to subdivide content/common into
content/common/device_orientation, or maybe content/common/shared_memory to put
the shared mem related code e.g. locks there?

+  WebKit::WebDeviceMotionData buffer;
+
+  // This boolean flag indicates that the values in the buffer are reliable and
+  // ready for reading. This is needed in cases where no motion information is
+  // available, but the event should be fired anyway (with null values)
+  // according to spec: http://dev.w3.org/geo/api/spec-source-orientation.html.
+  bool is_ready_for_read;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_COMMON_DEVICE_MOTION_HARDWARE_BUFFER_H_