[RFC weston 00/14] Atomic modesetting support

[Pekka Paalanen]

On Thu, 21 May 2015 12:29:28 -0700
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Thu, May 21, 2015 at 08:28:57AM +0100, Daniel Stone wrote:
> > Hi all,
> > This patchset is an experimental/RFC implementation of atomic modesetting
> > for Weston, as a proof-of-concept for the overall kernel API. It still
> > definitely has some rough edges, and safe to say it isn't 1.8 material,
> > but might be useful to look at regardless, especially for those of you
> > interested in compositor-drm internals.
> > 
> > This is largely based on Pekka's original work, and Louis-Francis's
> > work built on that, but with major changes since in the handling of
> > planes. compositor-drm now looks much more like a universal-plane user
> > internally; the major change from Pekka's branch is that the primary and
> > cursor planes are no longer so extensively special-cased.
> > 
> > These patches are essentially jointly authored between the three of us;
> > some of them have changed ownership along the way due to the amount of
> > rewriting performed, as well as splitting.
> > 
> > At the moment, this has only been validated on i915, using Maarten
> > Lankhorst's unify-flip-modeset branch, plus other changes to actually
> > expose atomic modesetting to userspace.
> 
> This is important code and thus should have test cases.  However, those
> will be hard to add after the fact, since they'll probably require a
> mock kernel, and thus may require some design modifications to permit
> easier testing.
> 
> I think you should consider testability in the design of this;
> otherwise, it's likely going to be difficult to add tests here after the
> fact.

Hi,

we have thought about testability *a lot*. Having Jon work on the test
suite is just the tip of the ice berg on the road to better testing.

Testing this stuff foremost requires running on real hardware and
drivers. We are planning on image based testing, the thing you are now
taking the very first steps with, but with hardware involved: either
using hardware CRC generators like Intel has in the scanout path, or an
external framegrabber device feeding the HDMI output back to the test
machine for verification, or a new KMS feature in the kernel which
allows grabbing the scanned out contents in a new buffer for
verification (screenshooting will not do, because overlay planes and
hardware cursors would be missing, or then the overlays would not be
used to begin with which is what our screenshot code does right now).
The common denominator for these approaces is that we tap into the pixel
stream generated by the scanout hardware and will get frame-accurate
results.

It's going to be complicated but awesome once it's in place, but
needless to say, a long long road ahead to get there. Until then, there
is very little we can do to test the DRM-backend automatically.

Simply getting an automated environment to even start Weston on various
real hardware platforms is a huge effort, but Collabora is working on
setting up the infrastructure for it.


Thanks,
pq