On Mon, 3 Jun 2019 15:19:13 +0000
"Ser, Simon" <simon.ser@intel.com> wrote:

> On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:

> > It's definitely a very suboptimal situation. Not sure there's a good way
> > out. The trouble here is that i915 ended up configuring crtc/connectors
> > differently than -modesetting (to allow fastboot, which I think is still
> > i915 exclusive). This then highlighted that modesetting can't do atomic
> > modesets if you try to reassign connectors.
> > 
> > One idea I have is that vgms would help compositors to play out a bunch of  
> 
> Just so people aren't confused: I think Daniel meant "vkms" here :P
> 
> > standard scenarios, even automated. But that's not there yet, and every
> > compositor project needs to care beyond "boots on my laptop, ship it". No
> > idea that's even possible.  
> 
> Having documentation for userspace is also important IMHO.
> 
> Regarding automated compositor testing, it's probably not possible to
> have a single place where all compositors are tested: vkms should
> probably be included as part of their CI. Thoughts?
> 
> Anyway, we could start a discussion to see if compositor people are
> interested. Or have you already talked to some compositor maintainers?

FWIW, I would absolutely *love* to be able to exercise Weston's
DRM-backend in Gitlab CI with anything, even just vkms, at least in
Weston's test suite to test Weston against KMS in general. Once that is
up, kernel people could replicate from that to their own CI for testing
drivers against known userspace.

I think it would be an awesome long term plan, whether uAPI specs
appear or not. Long term, because I have no idea who could work on it
when. In theory, all I would be waiting for is for vkms to be just
featureful enough and to figure out a way how to get that running
inside Gitlab CI.


Thanks,
pq