2018-09-08 01:41:36 +08:00
|
|
|
.. _vkms:
|
|
|
|
|
|
|
|
|
|
==========================================
|
|
|
|
|
drm/vkms Virtual Kernel Modesetting
|
|
|
|
|
==========================================
|
|
|
|
|
|
|
|
|
|
.. kernel-doc:: drivers/gpu/drm/vkms/vkms_drv.c
|
|
|
|
|
:doc: vkms (Virtual Kernel Modesetting)
|
|
|
|
|
|
|
|
|
|
TODO
|
|
|
|
|
====
|
|
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
If you want to do any of the items listed below, please share your interest
|
|
|
|
|
with VKMS maintainers.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
IGT better support
|
|
|
|
|
------------------
|
2018-10-03 21:21:03 +08:00
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- Investigate: (1) test cases on kms_plane that are failing due to timeout on
|
|
|
|
|
capturing CRC; (2) when running kms_flip test cases in sequence, some
|
|
|
|
|
successful individual test cases are failing randomly.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- VKMS already has support for vblanks simulated via hrtimers, which can be
|
|
|
|
|
tested with kms_flip test; in some way, we can say that VKMS already mimics
|
|
|
|
|
the real hardware vblank. However, we also have virtual hardware that does
|
|
|
|
|
not support vblank interrupt and completes page_flip events right away; in
|
|
|
|
|
this case, compositor developers may end up creating a busy loop on virtual
|
|
|
|
|
hardware. It would be useful to support Virtual Hardware behavior in VKMS
|
|
|
|
|
because this can help compositor developers to test their features in
|
|
|
|
|
multiple scenarios.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- 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.
|
|
|
|
|
|
|
|
|
|
Prime Buffer Sharing
|
|
|
|
|
--------------------
|
2018-10-03 21:21:03 +08:00
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- Syzbot report - WARNING in vkms_gem_free_object:
|
|
|
|
|
https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0
|
|
|
|
|
|
|
|
|
|
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.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
|
|
|
|
Writeback support
|
|
|
|
|
-----------------
|
|
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- The writeback and CRC capture operations share the use of composer_enabled
|
|
|
|
|
boolean to ensure vblanks. Probably, when these operations work together,
|
|
|
|
|
composer_enabled needs to refcounting the composer state to proper work.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
- Add support for cloned writeback outputs and related test cases using a
|
|
|
|
|
cloned output in the IGT kms_writeback.
|
2018-10-03 21:21:03 +08:00
|
|
|
|
|
|
|
|
- As a v4l device. This is useful for debugging compositors on special vkms
|
|
|
|
|
configurations, so that developers see what's really going on.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2020-10-07 06:30:06 +08:00
|
|
|
CRC API Improvements
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()``
|
2018-10-03 21:21:03 +08:00
|
|
|
|
|
|
|
|
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.
|
