According to v4l2 documentation, DQBUF always clears FLAG_DONE, so
this assert can be expected to fire 100% of the time.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
A handful of source files were not using the MIT Expat text in
COPYING. Update these files to bring them inline with the rest,
standardizing on the MIT Expat text.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This reverts commit 0fee977c46.
This commit introduces a requirement on v4l2_query_ext_ctrl and
VIDIOC_QUERY_EXT_CTRL, which were introduced in kernel 3.17. Some Ubuntu
LTS releases ship with much older kernels (and, significantly, UAPI),
which don't have these.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
The v4l2 API can be queried to detect if the input video image is
horizontally or vertically flipped. If the image is y-flipped, we can
set the ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT flag to notify the
compositor. If the image is h-flipped, we can only print a warning
since linux_buffer_params_v1 does not support horizontal flipping.
Signed-off-by: Micah Fedke <micah.fedke@collabora.co.uk>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Invert the Y_INVERT flag for the EGL import fo dmabufs. This fixes
weston-simple-dmabuf-intel to show the same image on both GL-composited
and with direct scanout on a hardware plane. Before, the image would
y-flip when switching between these two cases. Now the orientation also
matches the color values written in simple-dmabuf-intel.c.
The GL-renderer uses the OpenGL convention of texture coordinates, where
the origin is at the bottom-left of an image. This can be observed in
texture_region() where the texcoords are inverted if y_invert is false,
since the surface coordinates have origin at top-left. Both wl_shm and
dmabuf buffers have origin at the top-left.
When wl_shm buffer is imported with glTexImage2D, it gets inverted
because glTexImage2D is defined to read in the bottom row first. The shm
data is top row first. This incidentally also means, that buffer pixel
0,0 ends up at texture coordinates 0,0. This is now inverted compared to
the GL coordinate convention, and therefore gl_renderer_attach_shm()
sets y_inverted to true. This causes texture_region() to NOT invert the
texcoords. Wayland surface coordinates have origin at top-left, hence
the double-inversion.
Dmabuf buffers also have the origin at top-left. However, they are
imported via EGL to GL, where they should get the GL oriented
coordinates but they do not. It is as if pixel 0,0 ends up at texcoords
0,0 - the same thing as with wl_shm buffers. Therefore we need to invert
the invert flag.
Too bad EGL_EXT_image_dma_buf_import does not seem to specify the image
orientation. The GL spec implied result seems to conflict with the
reality in Mesa 11.2.2.
I asked about this in the Mesa developer mailing list. The question with
no answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120249.html
and the thread I hijacked to get some answers:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120733.html
which culminated to the conclusion:
https://lists.freedesktop.org/archives/mesa-dev/2016-June/120955.html
that supports this patch.
simple-dmabuf-v4l is equally fixed to not add Y_INVERT. There is no
rational reason to have it, and removing is necessary together with the
GL-renderer change to keep the image the right way up. This has been
tested with VIVID.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add very short explanation on how to set up Vivid driver, when you don't
have suitable V4L2 device to use.
Using the XR24 (DRM_FORMAT_XRGB8888) format practically guarantees that
you can test direct scanout on a hardware overlay, too. At least on PC
hardware that has overlays. Tested to work on Intel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Cannot find out why stropts.h is needed and Linux doesn't support
streams anyway, so there is no stropts.h.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
This client opens a V4L2 device, usually exposed as /dev/videoN, and
retrieves its frames as dmabuf for later import into the compositor.
It supports both single- and multi-planar devices, and any format
exposed by the V4L2 device the Wayland compositor accepts.
This client never changes the v4l2 settings, use `v4l2-ctl -c` if you
want to change those.
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Derek Foreman <derekf@osg.samsung.com>
Maniphest Tasks: T90
Differential Revision: https://phabricator.freedesktop.org/D339
