libmems: Move static functions and GetContext to base IioDevice class iio_device static functions (to process iio:device string) can be in the virtual iio_device object, they don't need to be in the real iio device implementation object. Also the iio_context the iio_device belongs to can also be in the virtual class. The test iio_context class is created and manipulated outside of the iio_device object, so it is fine if GetContext() return the virtual iio_context class, not the test one. BUG=none TEST=Unit test. Change-Id: Ie87d90d842e0e5dba52a0b8121e0644f2e256f22 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/6164340 Tested-by: Gwendal Grignou <gwendal@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> NOKEYCHECK=True GitOrigin-RevId: dd508dd6bfb468999521395e4316fe097f6af935
Project goal and motivationThis library provides a set of wrapper and test helpers around libiio.
It is meant to provide a common foundation for Chrome OS to access and interface IIO sensors, with:
At the root of the hierarchy, there exists the IioContext, which represents the IIO devices currently available on the system. These can be retrieved by name and inspected, via instances of IioDevice.
An IioDevice allows reading and writing attributes of an IIO device via type-safe helper APIs. It also offers support for configuring the buffer and trigger of an IIO device, which we use in order to allow the Chrome UI to read accelerometer data and support screen rotation.
An IioDevice also exposes a list of IioChannels, which can individually be enabled and disabled.
Useful mocks for the core classes are provided, such that a test author can focus on the logic of the unit tests and share a common testing language with other engineers working in this space. Sharing the foundation of testing IIO sensor access helps ensure that any improvement in this area can benefit all clients.