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

content/common/device_motion_messages.h

Index: content/common/device_motion_messages.h
diff --git a/content/common/device_motion_messages.h b/content/common/device_motion_messages.h
index 0d3303d4168ce79df95301c72c484e16e315cb19..b8aca3a0d67add5bcc9a81c57b8474479b62b8a7 100644
--- a/content/common/device_motion_messages.h
+++ b/content/common/device_motion_messages.h
@@ -6,9 +6,26 @@
 // Multiply-included message file, hence no include guard.
 
 #include "ipc/ipc_message_macros.h"
+#include "ipc/ipc_param_traits.h"
+#include "ipc/ipc_platform_file.h"
+#include "base/shared_memory.h"
 
 #define IPC_MESSAGE_START DeviceMotionMsgStart
 
+// Messages sent from the renderer to the browser.
+
+// Asks the browser process to start polling, and return a shared memory
+// handles that will hold the data from the hardware. See
+// device_motion_hardware_buffer.h for a description of how synchronization is
+// handled. The number of Starts should match the number of Stops.
+IPC_SYNC_MESSAGE_CONTROL0_1(DeviceMotionHostMsg_StartPolling,

[jamesr, 2013/05/16 19:58:21]

Why synchronous?

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

we need a valid handle to the shared memory from the browser before we start
polling.

The actual call is not completely synchronous anyway, in the sense that we don't
wait for sensors to start firing, just a shared memory buffer handle needs to be
returned.

+                            base::SharedMemoryHandle /* handle */)
+
+IPC_SYNC_MESSAGE_CONTROL0_0(DeviceMotionHostMsg_StopPolling)

[jamesr, 2013/05/16 19:58:21]

Ditto - why synchronous?

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

this can be async. Done.

+
+// TODO(timvolodine): remove the methods below once the Device Motion
+// is implemented.
+
 IPC_STRUCT_BEGIN(DeviceMotionMsg_Updated_Params)
   // These fields have the same meaning as in device_motion::Motion.
   IPC_STRUCT_MEMBER(bool, can_provide_acceleration_x)