I'm adding features to VKMS! What would you like to see?

[Alex Deucher]

On Fri, Jul 29, 2022 at 1:28 PM Jonas Ådahl <jadahl at gmail.com> wrote:
>
> On Fri, Jul 29, 2022 at 12:07:20PM -0400, Alex Deucher wrote:
> > On Fri, Jul 29, 2022 at 3:30 AM Jim Shargo <jshargo at chromium.org> wrote:
> > >
> > > Hi Wayland folks!
> > >
> > > TL;DR: I'm working on extending VKMS and wanted feedback from other
> > > compositor/wayland devs.
> > >> // Background
> > >
> > > I work on the ChromeOS compositor, and recently I've been doing a
> > > bunch of stuff to improve our testing setup. At the moment, my main
> > > focus is improving our ability to write integration tests against
> > > DRM/KMS.
> > >
> > > It's pretty tricky to get right. Working with mocks of DRM loses all
> > > the useful helpers that live within the kernel, which would need to be
> > > rewritten (and kept up-to-date) in userspace. Stuff like writeback
> > > support would be even harder.
> > >
> > > Earlier this year, VKMS came up as a potential solution. I was happy
> > > to see that Weston is already using it. I've started thinking about
> > > what features from the wild we'd need, and started digging into the
> > > code.
> > >
> > > // Current Status
> > >
> > > I recently sent out my first patchset, which will let userspace build
> > > their own DRM drivers with ConfigFS. This implicitly adds support for
> > > multi-display setups which were impossible to test before. This also
> > > allows for multiple virtual DRM drivers to be created and used at the
> > > same time, which may increase test parallelism? Haven't tried it yet.
> > >
> > > v1 patchset: https://patchwork.kernel.org/project/dri-devel/list/?series=662676
> > > cover letter: https://lists.freedesktop.org/archives/dri-devel/2022-July/365647.html
> > >
> > > // Rough Plans
> > >
> > > The big features I want to target with this work are:
> > >   - Multi-display and movable planes. This is mostly covered by the
> > > ConfigFS changes.
> > >   - Hot plugging.
> > >   - Color, color management and HDR. Loads of new formats, support for
> > > color properties not currently implemented. Making sure writeback
> > > buffers are useful for this.
> > >   - Improve IGT testing for VKMS (for new features and existing skipped tests)
> > >
> > > // Questions
> > >
> > >   - What VKMS features could help your testing the most?
> > >   - How much do you care about writeback buffer support vs CRC checks
> > > in tests atm?
> > >   - What kinds of bugs do you get around DRM/KMS?
> > >   - Any thoughts in general?
> >
> > Hey, nice work!
> >
> > So, not really related to wayland, but it would be cool if we could
> > add a generic vkms helper library for drivers to use for virtual
> > display functionality.  E.g., for headless GPUs in data centers or for
> > virtualization.
>
> With a risk of continuing being a bit off topic...
>
> What use cases is there a need to pass this functionality via virtual
> mode setting to implement virtual monitors in display servers, for
> headless and virtualization?
>
> I realize that there is a use case for virtual mode setting outputs for
> virtual machines meant to e.g. test run distributions while imitating real
> hardware as close as possible, but for actual intended remote access to
> headless machines or virtual machines, compositors can just render to
> offscreen framebuffers and communicate in whatever way, e.g. using DMA
> buffers via some IPC, with the software solution intended to provide the
> actual access.

Being able to run any distro (or compositor) unmodified on headless
GPUs on servers is the big one.  But you can do other things like
fetch EDIDs from displays on your local system and then inject them
into the virtual connectors on the server and start a virtual desktop
with the same "displays" as the local one which you can then use to
stream to your local system which is useful for thin clients.  We also
use it for pre-silicon emulation and early silicon bring-up internally
when we still want a standard "desktop" on the GPU.

Alex