[sensors] Introduce Generic Sensor API interfaces

device/sensors/public/interfaces/sensor_provider.mojom

+// Copyright 2016 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.
+
+module device.mojom;
+
+import "sensor.mojom";
+
+struct SensorReadBuffer {
+  // The shared memory handle used to fetch the sensor reading.
+  handle<shared_buffer> memory;
+
+  // The offset at which shared buffer must be mapped.
+  uint64 offset;

[timvolodine, 2016/07/04 11:32:46]

why is this needed? isn't the handle to shared buffer above sufficient?

[shalamov, 2016/07/04 12:11:46]

Please check comment above, we use one sharedbuffer for all sensors.

+
+  // The ReportingMode supported by the sensor.
+  ReportingMode mode;
+
+  // Note: Each sensor's read buffer contains 4 tightly packed 64-bit floating
+  // point fields, its layout is: { double timestamp; double values[3] }.

[timvolodine, 2016/07/04 11:32:46]

I am probably missing something, but where is this info stored and why
values[3]?

[shalamov, 2016/07/04 12:11:46]

For the sensors that are defined in SensorType enum and the data that is
provided by platform APIs(Android, Windows), timestamp + 3 sensor reading values
should be enough. We can change it later if required, when we start adding
concrete sensor implementations.

[timvolodine, 2016/07/05 11:45:08]

I see, so is your plan to allocate the size of the 'largest' sensor for all
other sensors in the buffer? looking at various sensors like magnetometer and
rotation vector they may actually require more than 3 values. e.g.
https://developer.android.com/reference/android/hardware/SensorEvent.html#values

also, how scalable is using a single shared memory buffer? imagine that a
certain sensor receives an extra value in the future, will that be an issue?

+  // So it has a fixed size 4*8 = 32 bytes.
+  const uint64 kReadBufferSize = 32;
+};
+
+interface SensorProvider {
+  // Gets the sensor interface by the given type.
+  //
+  // |type| type of the sensor.
+  //
+  // |request| the Sensor interface instance to be initialized.
+  // |read_buffer| on success will contain the SensorReadBuffer describing the
+  //               sensor reading buffer details,
+  //               contains null on failure.
+  // |client_request| on success contains a request to be bound by the client,
+  //                  contains null on failure.
+  GetSensor(SensorType type, Sensor& sensor_request) => (

[timvolodine, 2016/07/04 11:32:46]

why not have something like RegisterListener(SensorType, SensorConfig,
SensorClient) => SensorReadBuffer ?

[shalamov, 2016/07/04 12:11:46]

Then we will need to add unregisterListener, in addition to that, we would need
to send updates to all (SensorClient<->SensorConfig) instances.
That would add unneeded IPC, as I mentioned before in
https://codereview.chromium.org/2078433002/#msg19

[timvolodine, 2016/07/05 11:45:08]

ok I am trying to understand how it would actually work on the renderer side, as
it is not immediately clear why all other SensorClient instances would need to
be updated. If there are two sensors of same type but different frequencies
would they have separate clients? if so, would e.g. GetSensor(SensorType,
SensorConfig) => .. work here as well?

Looks like depending on the choice how to treat various configs, i.e.
frequencies, the design could be different. And we should try to not
'overcomplicate' things where possible. My understanding was that frequency was
an indication not a hard constraint, e.g. that's the case on android which uses
the register/unregister approach (and I think windows has something similar).

How would this design compare e.g. with having a mojo service to just expose the
actual platform functionality i.e. one sensor of each type with one client in
the renderer and do the 'filtering' of configs on the renderer side?

+      SensorReadBuffer? read_buffer,
+      SensorClient&? client_request);
+};