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 If you want to do any of the items listed below, please share your interest
  14 with VKMS maintainers.
  15
  16 IGT 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
  32 Add Plane Features
  33 ------------------
  34
  35 There'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
  49 For all of these, we also want to review the igt test coverage and make sure
  50 all relevant igt testcases work on vkms.
  51
  52 Prime Buffer Sharing
  53 --------------------
  54
  55 - Syzbot report - WARNING in vkms_gem_free_object:
  56   https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
  57
  58 Runtime Configuration
  59 ---------------------
  60
  61 We want to be able to reconfigure vkms instance without having to reload the
  62 module. 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
  73 The currently proposed solution is to expose vkms configuration through
  74 configfs.  All existing module options should be supported through configfs
  75 too.
  76
  77 Writeback 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
  90 Output 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
 100 CRC API Improvements
 101 --------------------
 102
 103 - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
 104
 105 Atomic Check using eBPF
 106 -----------------------
 107
 108 Atomic drivers have lots of restrictions which are not exposed to userspace in
 109 any explicit form through e.g. possible property values. Userspace can only
 110 inquiry about these limits through the atomic IOCTL, possibly using the
 111 TEST_ONLY flag. Trying to add configurable code for all these limits, to allow
 112 compositors to be tested against them, would be rather futile exercise. Instead
 113 we could add support for eBPF to validate any kind of atomic state, and
 114 implement a library of different restrictions.
 115
 116 This needs a bunch of features (plane compositing, multiple outputs, ...)
 117 enabled already to make sense.