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 <jsha...@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
