There is artefacts when I use "gst-launch-1.0 videotestsrc ! waylandsink"
I am using wayland 1.14.0, weston 3.0.0 and have no X support installed.
I can reproduce the same issue on two hardware imx6 riotboard and raspberrypi3.
I can provide an sdcard image with debug symbol if needed.
I can also do some tests.
Something's wrong with either Weston's I420/SHM import path (wouldn't be surprised if it was that), or GStreamer's usage of the same. This works around it, with obvious performance consequences:
gst-launch-1.0 videotestsrc ! videoconvert ! video/x-raw,format=(string)RGB ! waylandsink
First, it would be interesting to validate how GStreamer is rendering the buffer. It should be laid out, in order:
Y plane: offset == 0, stride == (width * 1), i.e. 1bpp, size == (stride * height), i.e. full height
U plane: offset == size[Y], stride == (width/2 * 1), i.e. 1bpp but half width, size == (stride * height/2), i.e. half height
V plane: offset == offset[U] + size[U], stride == (width/2 * 1), size == (stride * height/2), i.e. half width/height
If GStreamer is rendering correctly, this comes in to Weston at libweston/gl-renderer.c's gl_renderer_attach_shm(). In the YUV420 case (aka GStreamer's I420), this sets up the textures as described above. It then uploads the content in gl_renderer_flush_damage(), where it uploads according to the parameters set in attach_shm.
It looks from a quick inspection of the code that this is done correctly (i.e. dividing by hsub/vsub to halve the dimensions of the U/V planes), but it would be good to validate the parameters passed to glTex(Sub)Image2D() for the upload, after validating GStreamer's buffer layout.
Weston fix: https://patchwork.freedesktop.org/patch/180767/
I test the patch and everything works fine now.
This landed in the tree a while ago.