Sorry for the late reply on my end (last week was a holiday week in Japan).
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. On Sat, Apr 29, 2023 at 12:10 PM Jim Shargo <jsha...@chromium.org> wrote: > Hey, all! > > I am so excited to see other folks excited about extending VKMS. I > think it's a great project and has outstanding potential! > > Life stuff made me AFK for the last few months, but I'm back now and > I've been wrapping up the work on the patchset Brandon linked. > > The current WIP patches are here: > > https://gitlab.freedesktop.org/jshargo/compositor-kernel-explorations/-/merge_requests/4 > > They even come with matching IGT tests! > > https://gitlab.freedesktop.org/jshargo/igt-gpu-tools/-/commit/8375cf128f0811d54ecb4a0b5cf044942ffc67b9 > > I'm hoping to send them out again soon, hopefully next week. > > As a suggestion for how to move forward: the first three patches are > little refactors that are separable from the core ConfigFS ones (which > might have more back-and-forth design iterations). With those three, > the param you're adding should be easy to put on top. I can try to get > those out sooner for review. > > What do you think? > > > On Thu, Apr 27, 2023 at 10:51 PM Brandon Ross Pollack > <br...@chromium.org> wrote: > > > > 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.v...@collabora.com> > 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:yi...@google.com> 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.v...@collabora.com > > > > <mailto:marius.v...@collabora.com>> 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 > > > > >
