Documentation/gpu/vkms.rst

   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
  10 TODO
  11 ====
  12
  13 CRC 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
  26 Vblank issues
  27 -------------
  28
  29 Some 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
  37 Runtime Configuration
  38 ---------------------
  39
  40 We want to be able to reconfigure vkms instance without having to reload the
  41 module. 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
  52 The currently proposed solution is to expose vkms configuration through
  53 configfs.  All existing module options should be supported through configfs too.
  54
  55 Add Plane Features
  56 ------------------
  57
  58 There'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
  72 For all of these, we also want to review the igt test coverage and make sure all
  73 relevant igt testcases work on vkms.
  74
  75 Writeback support
  76 -----------------
  77
  78 Currently vkms only computes a CRC for each frame. Once we have additional plane
  79 features, 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
  87 Prime Buffer Sharing
  88 --------------------
  89
  90 We already have vgem, which is a gem driver for testing rendering, similar to
  91 how vkms is for testing the modeset side. Adding buffer sharing support to vkms
  92 allows us to test them together, to test synchronization and lots of other
  93 features. Also, this allows compositors to test whether they work correctly on
  94 SoC chips, where the display and rendering is very often split between 2
  95 drivers.
  96
  97 Output 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
 109 Atomic Check using eBPF
 110 -----------------------
 111
 112 Atomic drivers have lots of restrictions which are not exposed to userspace in
 113 any explicit form through e.g. possible property values. Userspace can only
 114 inquiry about these limits through the atomic IOCTL, possibly using the
 115 TEST_ONLY flag. Trying to add configurable code for all these limits, to allow
 116 compositors to be tested against them, would be rather futile exercise. Instead
 117 we could add support for eBPF to validate any kind of atomic state, and
 118 implement a library of different restrictions.
 119
 120 This needs a bunch of features (plane compositing, multiple outputs, ...)
 121 enabled already to make sense.