Speaker
Description
Abstract
Hardware testing can help catch regressions in driver code. One way to test is
to perform manual checks, however this is error-prone and doesn't scale. Another
approach is to build an automatic test suite (e.g. IGT), which calls special
driver interfaces or mocks resources to check whether they are doing the right
thing (for instance, checksums to check that the right frame is produced).
However it's not possible to test all features with driver helpers: link
training, hot-plug detection, DisplayPort Multi-Stream Transport and Display
Screen Compression are examples of hard-to-test features. Moreover, some
regressions can be missed because they happen at a lower level than the driver
helpers.
For this reason, a board emulating a real screen has been developed: Chamelium.
It can be used to test display features from the KMS client to the screen and
make sure the whole software and hardware stack works properly. An overview of
the Chamelium board features (and limitations) will be presented.
Outline
- Why:
- Automated testing is essential to merging patches with confidence
- It's not possible to test all display-related features without real
hardware - Some features can only be tested by adding knobs in the kernel (e.g. by
forcing an EDID on a disconnected connector) - The tests aren't checking that the feature works correctly with a real
screen - How:
- Google has developed a Chamelium board that emulates a screen
- Chamelium features
- Chamelium support in IGT
- Example of a Chamelium test (quick demo?)
- Current limitations and possible improvements
- Features supported by the receiver chips but not exposed by the Chamelium
API - Features not supported (would require a new board)
| Code of Conduct | Yes |
|---|---|
| GSoC, EVoC or Outreachy | No |
