<div dir="ltr">Sorry for the late reply on my end (last week was a holiday week in Japan).<div><br></div><div>I'm just getting to looking through these closer now, I spent much of my vacation reading about kernel/drivers and things make much more sense now to me so I'll have some notes (hopefully) as well shortly.</div></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 29, 2023 at 12:10 PM Jim Shargo <<a href="mailto:jshargo@chromium.org">jshargo@chromium.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey, all!<br>
<br>
I am so excited to see other folks excited about extending VKMS. I<br>
think it's a great project and has outstanding potential!<br>
<br>
Life stuff made me AFK for the last few months, but I'm back now and<br>
I've been wrapping up the work on the patchset Brandon linked.<br>
<br>
The current WIP patches are here:<br>
<a href="https://gitlab.freedesktop.org/jshargo/compositor-kernel-explorations/-/merge_requests/4" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/jshargo/compositor-kernel-explorations/-/merge_requests/4</a><br>
<br>
They even come with matching IGT tests!<br>
<a href="https://gitlab.freedesktop.org/jshargo/igt-gpu-tools/-/commit/8375cf128f0811d54ecb4a0b5cf044942ffc67b9" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/jshargo/igt-gpu-tools/-/commit/8375cf128f0811d54ecb4a0b5cf044942ffc67b9</a><br>
<br>
I'm hoping to send them out again soon, hopefully next week.<br>
<br>
As a suggestion for how to move forward: the first three patches are<br>
little refactors that are separable from the core ConfigFS ones (which<br>
might have more back-and-forth design iterations). With those three,<br>
the param you're adding should be easy to put on top. I can try to get<br>
those out sooner for review.<br>
<br>
What do you think?<br>
<br>
<br>
On Thu, Apr 27, 2023 at 10:51 PM Brandon Ross Pollack<br>
<<a href="mailto:brpol@chromium.org" target="_blank">brpol@chromium.org</a>> wrote:<br>
><br>
> I'm adding the original offer of those changes.  We talked recently<br>
> and they have the intent to push forward and merge them.  I'm still<br>
> getting up to speed a bit, but I will probably have a stronger opinion<br>
> by early next week.<br>
><br>
><br>
> On Wed, Apr 26, 2023 at 9:54 PM Marius Vlad <<a href="mailto:marius.vlad@collabora.com" target="_blank">marius.vlad@collabora.com</a>> wrote:<br>
> ><br>
> > Hi Brandon, Xie,<br>
> ><br>
> > Thanks for reaching out, and for the heads-up. I need to take a closer<br>
> > look, but by glancing over it, using configFS would be really awesome.<br>
> > Think we could really benefit from having that in our CI and being able<br>
> > to customize the entire pipeline. I'm totally for that.<br>
> ><br>
> > It looks like it requires some infra work so I guess landing that might<br>
> > require quite a bit of time. Not sure if there are recent updates for it.<br>
> ><br>
> > My changes are quite trivial and much more focused on just having<br>
> > multiple virtual displays, so IDK, I've submitted a version that seems<br>
> > to work, so I guess others should or would decide if we should drop mine<br>
> > and focus on the configFS series, or we should go with configFS as a<br>
> > follow-up. Would have liked to get something in the tree so we can at<br>
> > least have something to work with.<br>
> ><br>
> > Thoughts on the matter on how should we go about it?<br>
> ><br>
> > On 4/26/23 05:06, Brandon Ross Pollack wrote:<br>
> > > We're doing/planning on doing similar or related work here at chromium.<br>
> > ><br>
> > > <a href="https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both" rel="noreferrer" target="_blank">https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both</a> <<a href="https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both" rel="noreferrer" target="_blank">https://patchwork.kernel.org/project/dri-devel/list/?series=662676&submitter=&state=&q=&delegate=&archive=both</a>><br>
> > ><br>
> > > Here's the stuff we have now (we're currently rebasing and touching it<br>
> > > up, myself and @Yi Xie <mailto:<a href="mailto:yixie@google.com" target="_blank">yixie@google.com</a>> will be taking over<br>
> > > this work.<br>
> > ><br>
> > > Our plans are to add configFS changes and DRI VKMS changes to be able to<br>
> > > add and remove virtual displays at runtime (among other things needed<br>
> > > for our own testing purposes for our Exo wayland implementation).<br>
> > ><br>
> > > We're still learning how this all works and comes together, but it is<br>
> > > worth letting you know "us too"<br>
> > ><br>
> > > We can chat more and see where we overlap and can learn from each other :)<br>
> > ><br>
> > > On Tue, Apr 25, 2023 at 4:30 PM Marius Vlad <<a href="mailto:marius.vlad@collabora.com" target="_blank">marius.vlad@collabora.com</a><br>
> > > <mailto:<a href="mailto:marius.vlad@collabora.com" target="_blank">marius.vlad@collabora.com</a>>> wrote:<br>
> > ><br>
> > >     With multiple pipe available we can perform management of outputs at<br>
> > >     a more granular level, such that we're able to turn off or on several<br>
> > >     outputs at a time, or combinations that arise from doing that.<br>
> > ><br>
> > >     The Weston project use VKMS when running its test suite in CI, and we<br>
> > >     have now uses cases which would need to ability to set-up the outputs<br>
> > >     DPMS/state individually, rather than globally -- which would affect all<br>
> > >     outputs. This an attempt on fixing that by giving the possibility to<br>
> > >     create more than one pipe, and thus allowing to run tests that could<br>
> > >     exercise code paths in the compositor related to management of outputs.<br>
> > ><br>
> > >     v3:<br>
> > >        - Apply the series against drm-misc-next (Maíra Canal)<br>
> > >        - Add a lower range check to avoid passing negative values to<br>
> > >        max_pipes (Maíra Canal)<br>
> > ><br>
> > >     v2:<br>
> > >        - Replace 'outputs' with 'pipes' as to use the proper terminology<br>
> > >          (Thomas Zimmermann, Maíra Canal)<br>
> > >        - Fixed passing wrong possible_crtc bitmask when initializing the<br>
> > >          write back connector which address kms_writeback failure (Maíra<br>
> > >     Canal)<br>
> > >        - Add a feat. note about moving overlay planes between CRTCs<br>
> > >     (Melissa Wen)<br>
> > ><br>
> > >     Marius Vlad (3):<br>
> > >        vkms: Pass the correct bitmask for possible crtcs<br>
> > >        vkms: Add support for multiple pipes<br>
> > >        Documentation/gpu/vkms.rst: Added a note about plane migration<br>
> > ><br>
> > >       Documentation/gpu/vkms.rst            |  5 +++--<br>
> > >       drivers/gpu/drm/vkms/vkms_crtc.c      |  3 +--<br>
> > >       drivers/gpu/drm/vkms/vkms_drv.c       | 31 +++++++++++++++++++++------<br>
> > >       drivers/gpu/drm/vkms/vkms_drv.h       | 12 ++++++++---<br>
> > >       drivers/gpu/drm/vkms/vkms_output.c    |  7 +++---<br>
> > >       drivers/gpu/drm/vkms/vkms_writeback.c | 24 ++++++++++-----------<br>
> > >       6 files changed, 53 insertions(+), 29 deletions(-)<br>
> > ><br>
> > >     --<br>
> > >     2.39.2<br>
> > ><br>
</blockquote></div>