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