New to wayland, need help pls.

[Bryce W. Harrington]

On Wed, Apr 16, 2014 at 08:51:21AM +0300, Pekka Paalanen wrote:
> On Tue, 15 Apr 2014 19:08:12 +0000
> "Bryce W. Harrington" <b.harrington at samsung.com> wrote:
> 
> > On Tue, Apr 15, 2014 at 10:13:15AM +0300, Pekka Paalanen wrote:
> > > On Mon, 14 Apr 2014 12:11:11 +0530
> > > Srivardhan M S <srivardhanms at gmail.com> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > I am new to Wayland, and I would like to contribute to it. I have already,
> > > > downloaded the source code and have built it. Now reading the documentation
> > > > for understanding. Can you pls tell me how I can start involving and
> > > > contributing to wayland?
> > > 
> > > Hi,
> > > 
> > > if you have no idea where to start or any features you would like to
> > > add, here are some suggestions specific to Weston. If you want to work
> > > on a different compositor, or maybe toolkits, or maybe things like
> > > SDL's Wayland support, those would be welcome, too.
> > 
> > Maybe adding more tests?  Any particular features recently added that
> > could benefit from tests added?
> 
> Yes! That is a good one. Either adding completely new tests, or maybe
> working with Marek Chalupa in converting all possible FAIL_TEST cases to
> normal TEST cases, as permitted by Marek's
> http://lists.freedesktop.org/archives/wayland-devel/2014-April/014190.html
> 
> I can't list any features off-hand that would need new tests which would
> be easy to implement.

Would there be value to just basic unit tests on some of the established
API's?  E.g. like take xdg-shell's API, check passing in negative or
zero dimentions, crazy long strings for string params, stuff like that.
A lot of the protocol's code is generated so it's unclear to me whether
this level of testing would be useful or not, but if it is, it tends to
be pretty newbie-friendly.

> But I guess we should at some point hook up a
> real renderer to the headless backend, and add infrastructure for the
> test framework to do screencaptures, so we could test also rendering
> and things like window stacking and surface/buffer transformations.

That sounds keen, and could open up a lot of testing potential.  Shame
it's not already in place!  Could you elaborate on how you think this
could be created?  I'd like to explore this further myself.

> Pixman's fuzzer test might be a good inspiration on how to actually do
> the tests once the infrastructure is up:
> http://lists.freedesktop.org/archives/pixman/2014-April/003229.html
> Provided we can guarantee pixel-perfect rendering, which might not
> always be true, so a checksum-based checking might not always work.

I take it this is similar to the Cairo testsuite's perceptual diff
stuff?  (Checksumming two bitmaps pixel by pixel)

What we're seeing in Cairo is that sometimes pixel differences indicate
issues, but a lot of time it's ignorable, and deciding which is which is
fairly hard.  But used in situations where you are 100% sure exactly
what the images should look like, this can be quite effective.

In practice, just having all the different rendering tests can be a
handy workload for exposing crashes.  I suspect coupling it with some
timing measurements it might also help expose performance regressions.

> But I think that is getting quite heavy for just introductory work.

For something like this, 80% of the work is just deciding on a good
design.  Most of the implementation work is going to be basic coding.
There's going to be a few hard tasks (like attaching a snapshot renderer
functionality to the headless backend), but even those are likely to get
owners if they're well enough described.

Bryce