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

[Jonas Ådahl]

On Fri, Jul 29, 2022 at 12:09:27PM +0100, Daniel Stone wrote:
> Hi Jim,
> 
> On Fri, 29 Jul 2022 at 08:30, Jim Shargo <jshargo at chromium.org> wrote:
> > TL;DR: I'm working on extending VKMS and wanted feedback from other
> > compositor/wayland devs.
> 
> Awesome! :) Glad to see it, and yeah, I second everything Pekka said.
> Having hotplug in particular would be really great.

Enabling multi monitor and hotplug testing would be on my top wish list
too.

> 
> > // 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?
> 
> One thing I've really wanted is corner-case handling which just can't
> be done in generic code. Weston is really aggressive at trying to get
> things into planes, but we can only test those on actual systems with
> particular semantics.
> 
> I'd love to be able to programmatically fake those to be able to check
> our fallbacks in an automatic way. About the best idea I've come up
> with for that is being able to attach an eBPF hook to atomic_check.
> The absolute MVP would be no arguments and an errno return; if you
> completely control the environment, then you can store a counter in a
> map and return a particular error for the n'th attempt. But a better
> one would allow you to inspect the properties on each object in the
> atomic state, and also things like framebuffer attributes (dimensions,
> format, modifier, etc) so you could take action accordingly.

Being able to queue errors would be great indeed. So far I've done this
by mocking a subset of the libdrm API, which I could use to test e.g.
failed commits handling:

https://gitlab.gnome.org/jadahl/mutter/-/commit/93995754484536c61c7ddeffa2e50e4aef092a78


Jonas

> 
> Thanks for taking this on! Really looking forward to it.
> 
> Cheers,
> Daniel