drm/vkms Virtual Kernel Modesetting

VKMS is a software-only model of a KMS driver that is useful for testing and for running X (or similar) on headless machines. VKMS aims to enable a virtual display with no need of a hardware display capability, releasing the GPU in DRM API tests.

TODO

If you want to do any of the items listed below, please share your interest with VKMS maintainers.

IGT better support

  • Investigate: (1) test cases on kms_plane that are failing due to timeout on capturing CRC; (2) when running kms_flip test cases in sequence, some successful individual test cases are failing randomly.
  • VKMS already has support for vblanks simulated via hrtimers, which can be tested with kms_flip test; in some way, we can say that VKMS already mimics the real hardware vblank. However, we also have virtual hardware that does not support vblank interrupt and completes page_flip events right away; in this case, compositor developers may end up creating a busy loop on virtual hardware. It would be useful to support Virtual Hardware behavior in VKMS because this can help compositor developers to test their features in multiple scenarios.

Add Plane Features

There’s lots of plane features we could add support for:

  • Real overlay planes, not just cursor.
  • Full alpha blending on all planes.
  • Rotation, scaling.
  • Additional buffer formats, especially YUV formats for video like NV12. Low/high bpp RGB formats would also be interesting.
  • Async updates (currently only possible on cursor plane using the legacy cursor api).

For all of these, we also want to review the igt test coverage and make sure all relevant igt testcases work on vkms.

Prime Buffer Sharing

Runtime Configuration

We want to be able to reconfigure vkms instance without having to reload the module. Use/Test-cases:

  • Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of compositors).
  • Configure planes/crtcs/connectors (we’d need some code to have more than 1 of them first).
  • Change output configuration: Plug/unplug screens, change EDID, allow changing the refresh rate.

The currently proposed solution is to expose vkms configuration through configfs. All existing module options should be supported through configfs too.

Writeback support

  • The writeback and CRC capture operations share the use of composer_enabled boolean to ensure vblanks. Probably, when these operations work together, composer_enabled needs to refcounting the composer state to proper work.
  • Add support for cloned writeback outputs and related test cases using a cloned output in the IGT kms_writeback.
  • As a v4l device. This is useful for debugging compositors on special vkms configurations, so that developers see what’s really going on.

Output Features

  • Variable refresh rate/freesync support. This probably needs prime buffer sharing support, so that we can use vgem fences to simulate rendering in testing. Also needs support to specify the EDID.
  • Add support for link status, so that compositors can validate their runtime fallbacks when e.g. a Display Port link goes bad.

CRC API Improvements

  • Optimize CRC computation compute_crc() and plane blending blend()

Atomic Check using eBPF

Atomic drivers have lots of restrictions which are not exposed to userspace in any explicit form through e.g. possible property values. Userspace can only inquiry about these limits through the atomic IOCTL, possibly using the TEST_ONLY flag. Trying to add configurable code for all these limits, to allow compositors to be tested against them, would be rather futile exercise. Instead we could add support for eBPF to validate any kind of atomic state, and implement a library of different restrictions.

This needs a bunch of features (plane compositing, multiple outputs, …) enabled already to make sense.