1.. _vkms: 2 3========================================== 4 drm/vkms Virtual Kernel Modesetting 5========================================== 6 7.. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c 8 :doc: vkms (Virtual Kernel Modesetting) 9 10TODO 11==== 12 13CRC API Improvements 14-------------------- 15 16- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` 17 18- Use the alpha value to blend vaddr_src with vaddr_dst instead of 19 overwriting it in ``blend()``. 20 21- Add igt test to check cleared alpha value for XRGB plane format. 22 23- Add igt test to check extreme alpha values i.e. fully opaque and fully 24 transparent (intermediate values are affected by hw-specific rounding modes). 25 26Vblank issues 27------------- 28 29Some IGT test cases are failing. Need to analyze why and fix the issues: 30 31- plain-flip-fb-recreate 32- plain-flip-ts-check 33- flip-vs-blocking-wf-vblank 34- plain-flip-fb-recreate-interruptible 35- flip-vs-wf_vblank-interruptible 36 37Runtime Configuration 38--------------------- 39 40We want to be able to reconfigure vkms instance without having to reload the 41module. Use/Test-cases: 42 43- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of 44 compositors). 45 46- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of 47 them first). 48 49- Change output configuration: Plug/unplug screens, change EDID, allow changing 50 the refresh rate. 51 52The currently proposed solution is to expose vkms configuration through 53configfs. All existing module options should be supported through configfs too. 54 55Add Plane Features 56------------------ 57 58There's lots of plane features we could add support for: 59 60- Real overlay planes, not just cursor. 61 62- Full alpha blending on all planes. 63 64- Rotation, scaling. 65 66- Additional buffer formats, especially YUV formats for video like NV12. 67 Low/high bpp RGB formats would also be interesting. 68 69- Async updates (currently only possible on cursor plane using the legacy cursor 70 api). 71 72For all of these, we also want to review the igt test coverage and make sure all 73relevant igt testcases work on vkms. 74 75Writeback support 76----------------- 77 78Currently vkms only computes a CRC for each frame. Once we have additional plane 79features, we could write back the entire composited frame, and expose it as: 80 81- Writeback connector. This is useful for testing compositors if you don't have 82 hardware with writeback support. 83 84- As a v4l device. This is useful for debugging compositors on special vkms 85 configurations, so that developers see what's really going on. 86 87Prime Buffer Sharing 88-------------------- 89 90We already have vgem, which is a gem driver for testing rendering, similar to 91how vkms is for testing the modeset side. Adding buffer sharing support to vkms 92allows us to test them together, to test synchronization and lots of other 93features. Also, this allows compositors to test whether they work correctly on 94SoC chips, where the display and rendering is very often split between 2 95drivers. 96 97Output Features 98--------------- 99 100- Variable refresh rate/freesync support. This probably needs prime buffer 101 sharing support, so that we can use vgem fences to simulate rendering in 102 testing. Also needs support to specify the EDID. 103 104- Add support for link status, so that compositors can validate their runtime 105 fallbacks when e.g. a Display Port link goes bad. 106 107- All the hotplug handling describe under "Runtime Configuration". 108 109Atomic Check using eBPF 110----------------------- 111 112Atomic drivers have lots of restrictions which are not exposed to userspace in 113any explicit form through e.g. possible property values. Userspace can only 114inquiry about these limits through the atomic IOCTL, possibly using the 115TEST_ONLY flag. Trying to add configurable code for all these limits, to allow 116compositors to be tested against them, would be rather futile exercise. Instead 117we could add support for eBPF to validate any kind of atomic state, and 118implement a library of different restrictions. 119 120This needs a bunch of features (plane compositing, multiple outputs, ...) 121enabled already to make sense. 122