CRC API Improvements¶

• Optimize CRC computationcompute_crc() and plane blendingblend()
• Use the alpha value to blend vaddr_src with vaddr_dst instead ofoverwriting it inblend().
• Add igt test to check cleared alpha value for XRGB plane format.
• Add igt test to check extreme alpha values i.e. fully opaque and fullytransparent (intermediate values are affected by hw-specific rounding modes).

Runtime Configuration¶

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

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

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

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 cursorapi).

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

Writeback support¶

Currently vkms only computes a CRC for each frame. Once we have additional planefeatures, we could write back the entire composited frame, and expose it as:

• Writeback connector. This is useful for testing compositors if you don’t havehardware with writeback support.
• As a v4l device. This is useful for debugging compositors on special vkmsconfigurations, so that developers see what’s really going on.

Prime Buffer Sharing¶

We already have vgem, which is a gem driver for testing rendering, similar tohow vkms is for testing the modeset side. Adding buffer sharing support to vkmsallows us to test them together, to test synchronization and lots of otherfeatures. Also, this allows compositors to test whether they work correctly onSoC chips, where the display and rendering is very often split between 2drivers.

Output Features¶

• Variable refresh rate/freesync support. This probably needs prime buffersharing support, so that we can use vgem fences to simulate rendering intesting. Also needs support to specify the EDID.
• Add support for link status, so that compositors can validate their runtimefallbacks when e.g. a Display Port link goes bad.
• All the hotplug handling describe under “Runtime Configuration”.

Atomic Check using eBPF¶

Atomic drivers have lots of restrictions which are not exposed to userspace inany explicit form through e.g. possible property values. Userspace can onlyinquiry about these limits through the atomic IOCTL, possibly using theTEST_ONLY flag. Trying to add configurable code for all these limits, to allowcompositors to be tested against them, would be rather futile exercise. Insteadwe could add support for eBPF to validate any kind of atomic state, andimplement a library of different restrictions.

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