Orange Pi5 kernel

Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards

3 Commits   0 Branches   0 Tags
^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.