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