Hi Brandon, Xie,
Thanks for reaching out, and for the heads-up. I need to take a closer
look, but by glancing over it, using configFS would be really awesome.
Think we could really benefit from having that in our CI and being able
to customize the entire pipeline. I'm totally for that.
It looks like it requires some infra work so I guess landing that might
require quite a bit of time. Not sure if there are recent updates for it.
My changes are quite trivial and much more focused on just having
multiple virtual displays, so IDK, I've submitted a version that seems
to work, so I guess others should or would decide if we should drop mine
and focus on the configFS series, or we should go with configFS as a
follow-up. Would have liked to get something in the tree so we can at
least have something to work with.
Thoughts on the matter on how should we go about it?
On 4/26/23 05:06, Brandon Ross Pollack wrote:
We're doing/planning on doing similar or related work here at chromium.
https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both <https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both>
Here's the stuff we have now (we're currently rebasing and touching it
up, myself and @Yi Xie <mailto:yixie@xxxxxxxxxx> will be taking over
this work.
Our plans are to add configFS changes and DRI VKMS changes to be able to
add and remove virtual displays at runtime (among other things needed
for our own testing purposes for our Exo wayland implementation).
We're still learning how this all works and comes together, but it is
worth letting you know "us too"
We can chat more and see where we overlap and can learn from each other :)
On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <marius.vlad@xxxxxxxxxxxxx
<mailto:marius.vlad@xxxxxxxxxxxxx>> wrote:
With multiple pipe available we can perform management of outputs at
a more granular level, such that we're able to turn off or on several
outputs at a time, or combinations that arise from doing that.
The Weston project use VKMS when running its test suite in CI, and we
have now uses cases which would need to ability to set-up the outputs
DPMS/state individually, rather than globally -- which would affect all
outputs. This an attempt on fixing that by giving the possibility to
create more than one pipe, and thus allowing to run tests that could
exercise code paths in the compositor related to management of outputs.
v3:
- Apply the series against drm-misc-next (Maíra Canal)
- Add a lower range check to avoid passing negative values to
max_pipes (Maíra Canal)
v2:
- Replace 'outputs' with 'pipes' as to use the proper terminology
(Thomas Zimmermann, Maíra Canal)
- Fixed passing wrong possible_crtc bitmask when initializing the
write back connector which address kms_writeback failure (Maíra
Canal)
- Add a feat. note about moving overlay planes between CRTCs
(Melissa Wen)
Marius Vlad (3):
vkms: Pass the correct bitmask for possible crtcs
vkms: Add support for multiple pipes
Documentation/gpu/vkms.rst: Added a note about plane migration
Documentation/gpu/vkms.rst | 5 +++--
drivers/gpu/drm/vkms/vkms_crtc.c | 3 +--
drivers/gpu/drm/vkms/vkms_drv.c | 31 +++++++++++++++++++++------
drivers/gpu/drm/vkms/vkms_drv.h | 12 ++++++++---
drivers/gpu/drm/vkms/vkms_output.c | 7 +++---
drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++-----------
6 files changed, 53 insertions(+), 29 deletions(-)
--
2.39.2
