1 .. _vkms: 1 .. _vkms: 2 2 3 ========================================== 3 ========================================== 4 drm/vkms Virtual Kernel Modesetting 4 drm/vkms Virtual Kernel Modesetting 5 ========================================== 5 ========================================== 6 6 7 .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv. 7 .. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c 8 :doc: vkms (Virtual Kernel Modesetting) 8 :doc: vkms (Virtual Kernel Modesetting) 9 9 10 Setup << 11 ===== << 12 << 13 The VKMS driver can be setup with the followin << 14 << 15 To check if VKMS is loaded, run:: << 16 << 17 lsmod | grep vkms << 18 << 19 This should list the VKMS driver. If no output << 20 you need to enable and/or load the VKMS driver << 21 Ensure that the VKMS driver has been set as a << 22 kernel config file. Do:: << 23 << 24 make nconfig << 25 << 26 Go to `Device Drivers> Graphics support` << 27 << 28 Enable `Virtual KMS (EXPERIMENTAL)` << 29 << 30 Compile and build the kernel for the changes t << 31 Now, to load the driver, use:: << 32 << 33 sudo modprobe vkms << 34 << 35 On running the lsmod command now, the VKMS dri << 36 You can also observe the driver being loaded i << 37 << 38 The VKMS driver has optional features to simul << 39 which are exposed as module options. You can u << 40 to see the module options for vkms:: << 41 << 42 modinfo vkms << 43 << 44 Module options are helpful when testing, and e << 45 can be done while loading vkms. For example, t << 46 use:: << 47 << 48 sudo modprobe vkms enable_cursor=1 << 49 << 50 To disable the driver, use :: << 51 << 52 sudo modprobe -r vkms << 53 << 54 Testing With IGT << 55 ================ << 56 << 57 The IGT GPU Tools is a test suite used specifi << 58 development of the DRM drivers. << 59 The IGT Tools can be installed from << 60 `here <https://gitlab.freedesktop.org/drm/igt- << 61 << 62 The tests need to be run without a compositor, << 63 only mode. You can do this by:: << 64 << 65 sudo systemctl isolate multi-user.target << 66 << 67 To return to graphical mode, do:: << 68 << 69 sudo systemctl isolate graphical.target << 70 << 71 Once you are in text only mode, you can run te << 72 or IGT_DEVICE variable to specify the device f << 73 to test. IGT_DEVICE can also be used with the << 74 tests for a specific driver:: << 75 << 76 sudo ./build/tests/<name of test> --device " << 77 sudo IGT_DEVICE="sys:/sys/devices/platform/v << 78 sudo IGT_DEVICE="sys:/sys/devices/platform/v << 79 << 80 For example, to test the functionality of the << 81 we can run the kms_writeback test:: << 82 << 83 sudo ./build/tests/kms_writeback --device "s << 84 sudo IGT_DEVICE="sys:/sys/devices/platform/v << 85 sudo IGT_DEVICE="sys:/sys/devices/platform/v << 86 << 87 You can also run subtests if you do not want t << 88 << 89 sudo ./build/tests/kms_flip --run-subtest ba << 90 sudo IGT_DEVICE="sys:/sys/devices/platform/v << 91 << 92 TODO 10 TODO 93 ==== 11 ==== 94 12 95 If you want to do any of the items listed belo !! 13 CRC API 96 with VKMS maintainers. !! 14 ------- 97 << 98 IGT better support << 99 ------------------ << 100 << 101 Debugging: << 102 << 103 - kms_plane: some test cases are failing due t << 104 << 105 Virtual hardware (vblank-less) mode: << 106 << 107 - VKMS already has support for vblanks simulat << 108 tested with kms_flip test; in some way, we c << 109 the real hardware vblank. However, we also h << 110 not support vblank interrupt and completes p << 111 this case, compositor developers may end up << 112 hardware. It would be useful to support Virt << 113 because this can help compositor developers << 114 multiple scenarios. << 115 << 116 Add Plane Features << 117 ------------------ << 118 << 119 There's lots of plane features we could add su << 120 << 121 - Add background color KMS property[Good to ge << 122 << 123 - Scaling. << 124 << 125 - Additional buffer formats, especially YUV fo << 126 Low/high bpp RGB formats would also be inter << 127 << 128 - Async updates (currently only possible on cu << 129 cursor api). << 130 << 131 For all of these, we also want to review the i << 132 all relevant igt testcases work on vkms. They << 133 project. << 134 << 135 Runtime Configuration << 136 --------------------- << 137 << 138 We want to be able to reconfigure vkms instanc << 139 module. Use/Test-cases: << 140 << 141 - Hotplug/hotremove connectors on the fly (to << 142 of compositors). << 143 << 144 - Configure planes/crtcs/connectors (we'd need << 145 them first). << 146 << 147 - Change output configuration: Plug/unplug scr << 148 the refresh rate. << 149 << 150 The currently proposed solution is to expose v << 151 configfs. All existing module options should b << 152 too. << 153 << 154 Writeback support << 155 ----------------- << 156 << 157 - The writeback and CRC capture operations sha << 158 boolean to ensure vblanks. Probably, when th << 159 composer_enabled needs to refcounting the co << 160 [Good to get started] << 161 << 162 - Add support for cloned writeback outputs and << 163 cloned output in the IGT kms_writeback. << 164 << 165 - As a v4l device. This is useful for debuggin << 166 configurations, so that developers see what' << 167 << 168 Output Features << 169 --------------- << 170 << 171 - Variable refresh rate/freesync support. This << 172 sharing support, so that we can use vgem fen << 173 testing. Also needs support to specify the E << 174 << 175 - Add support for link status, so that composi << 176 fallbacks when e.g. a Display Port link goes << 177 << 178 CRC API Improvements << 179 -------------------- << 180 15 181 - Optimize CRC computation ``compute_crc()`` a 16 - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` 182 17 183 Atomic Check using eBPF !! 18 - Use the alpha value to blend vaddr_src with vaddr_dst instead of 184 ----------------------- !! 19 overwriting it in ``blend()``. 185 20 186 Atomic drivers have lots of restrictions which !! 21 - Add igt test to check cleared alpha value for XRGB plane format. 187 any explicit form through e.g. possible proper << 188 inquiry about these limits through the atomic << 189 TEST_ONLY flag. Trying to add configurable cod << 190 compositors to be tested against them, would b << 191 we could add support for eBPF to validate any << 192 implement a library of different restrictions. << 193 22 194 This needs a bunch of features (plane composit !! 23 - Add igt test to check extreme alpha values i.e. fully opaque and fully 195 enabled already to make sense. !! 24 transparent (intermediate values are affected by hw-specific rounding modes).
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.