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 13If you want to do any of the items listed below, please share your interest 14with VKMS maintainers. 15 16IGT better support 17------------------ 18 19- Investigate: (1) test cases on kms_plane that are failing due to timeout on 20 capturing CRC; (2) when running kms_flip test cases in sequence, some 21 successful individual test cases are failing randomly. 22 23- VKMS already has support for vblanks simulated via hrtimers, which can be 24 tested with kms_flip test; in some way, we can say that VKMS already mimics 25 the real hardware vblank. However, we also have virtual hardware that does 26 not support vblank interrupt and completes page_flip events right away; in 27 this case, compositor developers may end up creating a busy loop on virtual 28 hardware. It would be useful to support Virtual Hardware behavior in VKMS 29 because this can help compositor developers to test their features in 30 multiple scenarios. 31 32Add Plane Features 33------------------ 34 35There's lots of plane features we could add support for: 36 37- Real overlay planes, not just cursor. 38 39- Full alpha blending on all planes. 40 41- Rotation, scaling. 42 43- Additional buffer formats, especially YUV formats for video like NV12. 44 Low/high bpp RGB formats would also be interesting. 45 46- Async updates (currently only possible on cursor plane using the legacy 47 cursor api). 48 49For all of these, we also want to review the igt test coverage and make sure 50all relevant igt testcases work on vkms. 51 52Prime Buffer Sharing 53-------------------- 54 55- Syzbot report - WARNING in vkms_gem_free_object: 56 https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 57 58Runtime Configuration 59--------------------- 60 61We want to be able to reconfigure vkms instance without having to reload the 62module. Use/Test-cases: 63 64- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling 65 of compositors). 66 67- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of 68 them first). 69 70- Change output configuration: Plug/unplug screens, change EDID, allow changing 71 the refresh rate. 72 73The currently proposed solution is to expose vkms configuration through 74configfs. All existing module options should be supported through configfs 75too. 76 77Writeback support 78----------------- 79 80- The writeback and CRC capture operations share the use of composer_enabled 81 boolean to ensure vblanks. Probably, when these operations work together, 82 composer_enabled needs to refcounting the composer state to proper work. 83 84- Add support for cloned writeback outputs and related test cases using a 85 cloned output in the IGT kms_writeback. 86 87- As a v4l device. This is useful for debugging compositors on special vkms 88 configurations, so that developers see what's really going on. 89 90Output Features 91--------------- 92 93- Variable refresh rate/freesync support. This probably needs prime buffer 94 sharing support, so that we can use vgem fences to simulate rendering in 95 testing. Also needs support to specify the EDID. 96 97- Add support for link status, so that compositors can validate their runtime 98 fallbacks when e.g. a Display Port link goes bad. 99 100CRC API Improvements 101-------------------- 102 103- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` 104 105Atomic Check using eBPF 106----------------------- 107 108Atomic drivers have lots of restrictions which are not exposed to userspace in 109any explicit form through e.g. possible property values. Userspace can only 110inquiry about these limits through the atomic IOCTL, possibly using the 111TEST_ONLY flag. Trying to add configurable code for all these limits, to allow 112compositors to be tested against them, would be rather futile exercise. Instead 113we could add support for eBPF to validate any kind of atomic state, and 114implement a library of different restrictions. 115 116This needs a bunch of features (plane compositing, multiple outputs, ...) 117enabled already to make sense. 118