diff options
Diffstat (limited to 'Documentation/gpu')
| -rw-r--r-- | Documentation/gpu/drm-kms-helpers.rst | 19 | ||||
| -rw-r--r-- | Documentation/gpu/drm-uapi.rst | 3 | ||||
| -rw-r--r-- | Documentation/gpu/todo.rst | 10 | ||||
| -rw-r--r-- | Documentation/gpu/vkms.rst | 101 |
4 files changed, 126 insertions, 7 deletions
diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index f9cfcdcdf024..4b4dc236ef6f 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -59,19 +59,28 @@ Implementing Asynchronous Atomic Commit .. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c :doc: implementing nonblocking commit +Helper Functions Reference +-------------------------- + +.. kernel-doc:: include/drm/drm_atomic_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c + :export: + Atomic State Reset and Initialization ------------------------------------- -.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c :doc: atomic state reset and initialization -Helper Functions Reference --------------------------- +Atomic State Helper Reference +----------------------------- -.. kernel-doc:: include/drm/drm_atomic_helper.h +.. kernel-doc:: include/drm/drm_atomic_state_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_atomic_helper.c +.. kernel-doc:: drivers/gpu/drm/drm_atomic_state_helper.c :export: Simple KMS Helper Reference diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index a2214cc1f821..4b4bf2c5eac5 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -197,6 +197,9 @@ EPERM/EACCESS: difference between EACCESS and EPERM. ENODEV: + The device is not (yet) present or fully initialized. + +EOPNOTSUPP: Feature (like PRIME, modesetting, GEM) is not supported by the driver. ENXIO: diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 77c2b3c25565..5c9d86c962af 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -339,6 +339,16 @@ Some of these date from the very introduction of KMS in 2008 ... leftovers from older (never merged into upstream) KMS designs where modes where set using their ID, including support to add/remove modes. +- Make ->funcs and ->helper_private vtables optional. There's a bunch of empty + function tables in drivers, but before we can remove them we need to make sure + that all the users in helpers and drivers do correctly check for a NULL + vtable. + +- Cleanup up the various ->destroy callbacks. A lot of them just wrapt the + drm_*_cleanup implementations and can be removed. Some tack a kfree() at the + end, for which we could add drm_*_cleanup_kfree(). And then there's the (for + historical reasons) misnamed drm_primary_helper_destroy() function. + Better Testing ============== diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 0a6ea6216e41..7dfc349a4508 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,8 +10,8 @@ TODO ==== -CRC API -------- +CRC API Improvements +-------------------- - Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` @@ -22,3 +22,100 @@ CRC API - Add igt test to check extreme alpha values i.e. fully opaque and fully transparent (intermediate values are affected by hw-specific rounding modes). + +Vblank issues +------------- + +Some IGT test cases are failing. Need to analyze why and fix the issues: + +- plain-flip-fb-recreate +- plain-flip-ts-check +- flip-vs-blocking-wf-vblank +- plain-flip-fb-recreate-interruptible +- flip-vs-wf_vblank-interruptible + +Runtime Configuration +--------------------- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of + compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs too. + +Add Plane Features +------------------ + +There's lots of plane features we could add support for: + +- Real overlay planes, not just cursor. + +- Full alpha blending on all planes. + +- Rotation, scaling. + +- Additional buffer formats, especially YUV formats for video like NV12. + Low/high bpp RGB formats would also be interesting. + +- Async updates (currently only possible on cursor plane using the legacy cursor + api). + +For all of these, we also want to review the igt test coverage and make sure all +relevant igt testcases work on vkms. + +Writeback support +----------------- + +Currently vkms only computes a CRC for each frame. Once we have additional plane +features, we could write back the entire composited frame, and expose it as: + +- Writeback connector. This is useful for testing compositors if you don't have + hardware with writeback support. + +- As a v4l device. This is useful for debugging compositors on special vkms + configurations, so that developers see what's really going on. + +Prime Buffer Sharing +-------------------- + +We already have vgem, which is a gem driver for testing rendering, similar to +how vkms is for testing the modeset side. Adding buffer sharing support to vkms +allows us to test them together, to test synchronization and lots of other +features. Also, this allows compositors to test whether they work correctly on +SoC chips, where the display and rendering is very often split between 2 +drivers. + +Output Features +--------------- + +- Variable refresh rate/freesync support. This probably needs prime buffer + sharing support, so that we can use vgem fences to simulate rendering in + testing. Also needs support to specify the EDID. + +- Add support for link status, so that compositors can validate their runtime + fallbacks when e.g. a Display Port link goes bad. + +- All the hotplug handling describe under "Runtime Configuration". + +Atomic Check using eBPF +----------------------- + +Atomic drivers have lots of restrictions which are not exposed to userspace in +any explicit form through e.g. possible property values. Userspace can only +inquiry about these limits through the atomic IOCTL, possibly using the +TEST_ONLY flag. Trying to add configurable code for all these limits, to allow +compositors to be tested against them, would be rather futile exercise. Instead +we could add support for eBPF to validate any kind of atomic state, and +implement a library of different restrictions. + +This needs a bunch of features (plane compositing, multiple outputs, ...) +enabled already to make sense. |