| .. _vkms: | |
| ========================================== | |
| drm/vkms Virtual Kernel Modesetting | |
| ========================================== | |
| .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c | |
| :doc: vkms (Virtual Kernel Modesetting) | |
| 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 | |
| -------------------- | |
| - Syzbot report - WARNING in vkms_gem_free_object: | |
| https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 | |
| 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. |