I'm adding the original offer of those changes. We talked recently and they have the intent to push forward and merge them. I'm still getting up to speed a bit, but I will probably have a stronger opinion by early next week. On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad <marius.vlad@xxxxxxxxxxxxx> wrote: > > 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 > >
