Since clients using dmabuf require libgbm 21.1.1, there is no need to
support the old libgbm which does not support modifiers.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
glFinish() blocks until all commands have finished. This is
unnecessary: we can use glFlush() and rely on implicit sync
instead.
Signed-off-by: Simon Ser <contact@emersion.fr>
The motivations for this are:
- Y_INVERT is not used by most real-world clients.
weston-simple-dmabuf-egl and weston-simple-dmabuf-v4l are one only
known users. Thus this creates a special case just for these demo
clients.
- Some compositors (wlroots) have dropped support for DMA-BUF flags,
so the client no longer runs there.
- Dropping the flag allows compositors to use a KMS hardware plane to
display the buffer.
It keeps the same axis orientation we had in place where we had the
y-invert flag enabled by default, by doing a reflection about x-axis.
Signed-off-by: Simon Ser <contact@emersion.fr>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/weston/-/issues/675
It is used in Mesa. Lets switch to it as well in order to provide
good examples and encourage proper API usage.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
In certain situations these clients crash a lot due to the low
buffer limit. Four buffers is also what EGL allows without blocking
and what is arguably the upper limit of what a compositor should
demand.
Signed-off-by: Robert Mader <robert.mader@collabora.com>
While this is harmless because gbm_bo_create_with_modifiers will just
fail, it's easy to misunderstand that gbm_bo_create_with_modifiers
accepts MOD_INVALID. Let's just keep modifiers_count to zero instead
and stop even trying to call that function with invalid input.
Stop using modifiers_count to decide whether the compositor supports a
format. Instead use a separate format_supported flag.
Signed-off-by: Simon Ser <contact@emersion.fr>
References: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7601#note_778845
This allows to specify a custom DRM format. For instance, to test
XBGR2101010:
weston-simple-dmabuf-egl -f 0x30334258
Signed-off-by: Simon Ser <contact@emersion.fr>
This header is for sharing fallback definitions for drm_fourcc.h. A new
test in tests/yuv-buffer-test.c is going to be needing XYUV8888 format,
and more new formats will be expected with HDR supports.
Share these fallback definitions in one place instead of copying them
all over.
All users of drm_fourcc.h are converted to include weston-drm-fourcc.h
instead for consistency: have the same definitions available everywhere.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
MOD_INVALID came with libdrm 2.4.83 and MOD_LINEAR came with libdrm
2.4.82. libweston unconditionally depends on libdrm >= 2.4.95, so the
fallback is not necessary.
Since linux-dmabuf.h itself has no use for these and also forgets to
include drm_fourcc.h, .c files including drm_fourcc.h after this header
would trigger compiler warnings.
linux-dmabuf.c does need these, so add the proper include.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
protocol
As dmabuf uses a different coordinate (top-left) system than OpenGL
(bottom-left) using both direct-display with the Y_INVERT dmabuf attrib
flag would result in the image being inverted (direct-display will
remove the Y_INVERT flag, which caused the image to be displayed
correctly). Notifies users that direct-display is in use.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Some drivers expose the extension so they can expose
eglQueryDmaBufFormatsEXT, but don't support any modifiers. Treat this the
same as if the extension wasn't present.
All these have the printf format string wrong. "%*s" sets the field width but
does not limit the string to len bytes. You need to set precision instead to
limit to len bytes: "%.*s".
Found by grepping, after wondering why my WIP prints printed garbage at the
end.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
It is a public installed header used by libweston.h.
See "Rename compositor.h to libweston/libweston.h" for rationale.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
gbm_bo_get_handle_for_plane returns handle.s32 == -1 on error, at least
for the Mesa dri implementation.
Reported-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Since we are managing and rendering to buffers on our own with GBM,
create the EGL display using the GBM platform with the DRM render node,
instead of using the Wayland EGL platform.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Support drawing a mandelbrot set in the fragment shader, rendering it
with separate draw calls, one for each cell in a virtual 4x4 grid. This
more complex and heavy drawing will potentially help us to visually
discover any present or future explicit synchronization issues.
The mandelbrot set rendering is enabled with the -m/--mandelbrot
command-line switch.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Render a moving square instead of just clearing the buffer, to help
uncover rendering issues (e.g. modifier-related issues) which may not be
visible with a simple glClear.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Take into account format modifiers advertised by the compositor and the
EGL implementation and supported by the buffer creation mechanism, to
select the optimal buffer modifier.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Add a client that uses EGL/GLESv2 to draw to dmabuf buffers, utilizing
EGLImages and FBOs. The client uses GBM to create the dmabufs buffers.
The simple-dmabuf-egl client is partly based on patch [1] that changes
dmabuf clients to use GBM instead of libdrm code, but has been greatly
simplified since in this case we don't require direct pixel access or
non-RGBA formats.
[1] https://patchwork.freedesktop.org/patch/239796/
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>