Chrome already supports readings from IIO sensors in the Generic Sensors API. We have reimplemented Device Motion on top of Generic Sensors and Device Orientation is coming soon. If this isn't working for a particular Chrome OS device can you help us figure out what is missing in:

https://cs.chromium.org/chromium/src/services/device/generic_sensor/linux/sensor_data_linux.cc

based on internal testing, at least two of the new convertible Chromebook devices (Pixelbook and Asus) don't support this (the test page reports that it's not implemented).

Enabling the following flags and visiting https://genericsensors.appspot.com/ will let you test individual sensor support:

chrome://flags/#enable-experimental-web-platform-features
chrome://flags/#enable-generic-sensor
chrome://flags/#enable-generic-sensor-extra-classes

On the Chromebooks we tested, both of the samples above work in the Android version of Chrome Canary but not in the native Chrome browser. So the sensors are present and working, but they are not being exposed to the web.

Is this is a known issue? What are the plans for enabling the sensors in the browser?

Note: offenwanger@ also was unable to get VR magic window working (issue 773829). It's not clear yet whether that is due to VR-specific code or the Chrome internals (not just Blink) not having access to the sensors.

The refactoring mentioned above is complete so platform_sensor_provider_linux.cc is the right place to start for adding support for the IMUs on Chrome OS devices.

For comparison, look at how platform_sensor_provider_android.cc mixes sensor types nativly supported by the hardware platform with fusion sensors that fill in the gaps based on low-level sensor data.

There have been some recent changes to platform_sensor_provider_linux.cc, so this may now work.

I have built a current version (68.0.3418 Developer Build) of chromium on a ChromeOS device, sensors are still not working.

The link from comment #4 is out of date. Here is a new link to the Generic Sensors demo app:

https://intel.github.io/generic-sensor-demos/sensor-info/build/bundled/

What is useful about this app is that it lets you request individual sensor types so you can debug which sensors are available on your platform.

Enable chrome://flags/#enable-generic-sensor-extra-classes to give it access to the magnetometer.

Sensors that are getting data: Ambient light, Accelerometer, LinearAcceleration

Sensors that are not getting data: Magnetometer, Gyroscope, RelativeOrientation, AbsoluteOrientation

We can probably get his resolved if you're willing to dig into what IIO interfaces this hardware exposes for its sensors. They probably just don't line up with what the existing code is expecting. Which Chrome OS device are you testing with?

I just checked and this issue is reproducible on a Pixelbook. The accelerometer is correctly detected though the output values seem completely off. The gyroscope and magnetometer are not.

Only accelerometer is available to chrome (for lid angle calculation and device orientation) via a polling interface. Accelerometer and all other sensors (gyroscope, magnetometer) are taken over by ARC++.

Sharing sensors between chrome and arc++ is not trivial and require some redesign. I started an investigation here:
https://docs.google.com/document/d/107LQL6dNmR6jGlnTKmzwmznp68n7FthgndmTQuZDQ1U/edit#

If we fix Chrome's access to all the sensors on the platform can we expose the SensorProvider Mojo interface over the ARC++ bridge to give Android access?

We can make Chrome become the Sensor HAL for ARC++, chrome would be responsible for managing the sensors, set frequency/batch mode, handle different settings.
Last time Jon (jonross@) and I talk about it, we concluded having a service outside chrome was more elegant.

Just for some added context, at the moment the implementation of SensorProvider is in the Chrome browser process but as part of the servicification effort it has been placed in the "device service" which will eventually run out-of-process on Chrome OS.

Is there any update on the architecture changes necessary to allow Chrome and ARC++ to share the device sensors?