Google Git
Sign in
chromium / chromiumos / platform2 / libmems / 9fad7e4b2348a11efb158ad19ab3ce9909ae9cec
commit9fad7e4b2348a11efb158ad19ab3ce9909ae9cec[log] [tgz]
authorGwendal Grignou <gwendal@chromium.org>Fri Jan 10 08:37:44 2025
committerCopybara-Service <copybara-worker@google.com>Thu Feb 13 06:32:26 2025
treee62ec7da852a83af46a7ea3cb8fd2c1057d335db
parent14529a4593f2faca09b53e0646df4c6b794e50ef [diff]
libmems: Stop exposing internal implementation Add a factory object to create the iio context. From there, iio device objects are added. No ..impl.h files are exported anymore. BUG=none TEST=Unit tests. Change-Id: Ib24fd46ca69b85e98e0767c16a2880b6f1fe1db7 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/6164341 Reviewed-by: Harvey Yang <chenghaoyang@chromium.org> Tested-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Cheng-Han Yang <chenghan@chromium.org> Commit-Queue: Gwendal Grignou <gwendal@chromium.org> NOKEYCHECK=True GitOrigin-RevId: 6872e3b5b5c53dc0f68c656ca551d1729ea04c07
4 files changed
tree: e62ec7da852a83af46a7ea3cb8fd2c1057d335db
  1. BUILD.gn
  2. common_types.cc
  3. common_types.h
  4. DIR_METADATA
  5. export.h
  6. iio_channel.h
  7. iio_channel_impl.cc
  8. iio_channel_impl.h
  9. iio_context.h
  10. iio_context_factory.cc
  11. iio_context_factory.h
  12. iio_context_impl.cc
  13. iio_context_impl.h
  14. iio_device.cc
  15. iio_device.h
  16. iio_device_impl.cc
  17. iio_device_impl.h
  18. iio_device_test.cc
  19. iio_device_trigger_impl.cc
  20. iio_device_trigger_impl.h
  21. iio_event.cc
  22. iio_event.h
  23. iio_event_impl.cc
  24. iio_event_impl.h
  25. iio_event_impl_test.cc
  26. iio_event_test.cc
  27. OWNERS
  28. README.md
  29. test_fakes.cc
  30. test_fakes.h
README.md

Chrome OS IIO Sensor Utility Library

Project goal and motivation

This 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:

  • a strong emphasis on testability;
  • readable code, with the ergonomics typical of platform2;
  • high performance.

Class hierarchy

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.

Test mocks

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.