| commit | 69141d56e44d96f7298bc38a2e5dba1a82f204cc | [log] [tgz] |
|---|---|---|
| author | hscham <hscham@chromium.org> | Thu Mar 17 06:06:21 2022 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri Apr 01 10:25:10 2022 |
| tree | e0d7d0d55b2819de06a9125d69c6e95c79656057 | |
| parent | 02eae65fca3e59dba406dcd8e41a883f1557ec4b [diff] |
platform2: migrate base or absl optional to std::optional libchrome base::Optional is replaced by absl::optional on chromium upstream and removed in r885735. Since Chrome OS uses c++17, it can also use std::optional (as opposed to Chrome which uses c++14). See go/use-std-optional-in-cros for discussion. Note, libchrome uses absl::optional because that is what upstream chromium uses. However, in CrOS, absl switched to always use std::optional implementation in crrev.com/c/2967691 so they are equivalent. LSC proposal: go/chromeos-lsc-optional-migration BUG=b:192529039 TEST=CQ Change-Id: Ie7b2497260e32766cabd4ba398cc7d94263d7ab0 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/3325832 Reviewed-by: Hidehiko Abe <hidehiko@chromium.org> Owners-Override: Dominick Ng <dominickn@google.com> Commit-Queue: Grace Cham <hscham@chromium.org> Tested-by: Grace Cham <hscham@chromium.org> NOKEYCHECK=True GitOrigin-RevId: a3c61bdb78ad8c2cc6f7790e26971c1844da6e78
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.