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