In commit "libweston: add struct weston_drm_format" struct
weston_drm_format and its helper functions were added to libweston.
The functions query_dmabuf_formats and query_dmabuf_modifiers are very
specific to GL-renderer and its internals. So instead of exposing them
in libweston, query and store DRM formats and modifiers internally in
GL-renderer. Also, add a vfunction to struct weston_renderer in order
to retrieve the formats.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
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>
Adds a new callback 'can_scanout_dmabuf' in weston_backend, which
can be set by the back-end do determine if the buffer supplied can be
imported directly by KMS.
This patch adds a wrapper over it, 'weston_compositor_dmabuf_can_scanout'
which is called before importing the dmabuf in the GPU if the
direct_display dmabuf is being set. If that's true and the check
failed, we refuse to create a wl_buffer.
This patch avoids importing in the GPU.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
This comment was added in 230f3b1bf8 with the
intent that if we had an information table about pixel formats (which we do
have today), we could implement more sanity checks like ensuring that width
pixels fit into stride.
Daniel Vetter said on #dri-devel IRC recently:
< danvet> since userspace shouldn't look at stride for buffers with
modifiers, only pass it around unchanged
I asked for clarification. It was expected that userspace would not do any kind
of sanity checks as modifiers could change everything.
Let's remove the misleading code comment so that people don't get the idea of
adding more well-intended but ill-advised sanity checks. If more checks are
added, they must take the modifier into account, which the existing checks do
not do.
After 5 years, it is far too late to remove our existing sanity checks, but we
can attempt to not cause any more damage that would restrict what people can do
in the kernel.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main idea is to make libweston users use the form
#include <libweston/libweston.h>
instead of the plain
#include <compositor.h>
which is prone to name conflicts. This is reflected both in the installed
files, and the internal header search paths so that Weston would use the exact
same form as an external project using libweston would.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Although the format event is deprecated, some clients, especially the
GStreamer waylandsink, only support zwp_linux_dmabuf_v1 version 1 and
require the deprecated format event.
Send format events instead of the modifier event, if the client binds on
a protocol version before version 3, skipping formats that only support
non-linear modifiers.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Daniel Stone <daniels@collabora.com>
modifier_hi and modifier_lo are set to 0 by clients,
which are not supporting modifiers. Modifier attributes
of buffers of these clients set to 0 too in linux-dmabuf.c
import_simple_dmabuf function in gl-renderer.c compares
modifier attribute of the buffer with DRM_FORMAT_MOD_INVALID.
DRM_FORMAT_MOD_INVALID is equal to ((1ULL<<56) - 1).
Therefore, modifer 0 is accepted as valid. Then, the function
checks support for eglQueryDmaBufModifiersEXT.
If it is not supported import_simple_dmabuf function is returning
NULL.
This patch sets the modifier attribute to DRM_FORMAT_MOD_INVALID
for clients which are not supporting modifiers. Without this patch
linux-dmabuf protocol is not working for not supporting clients.
Fixes: b138d7afb3 ("gl-renderer: Ignore INVALID modifier")
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Tested-by: Tomohito Esaki <etom@igel.co.jp>
We need to make sure the client bound dmabuf with a high enough
version to receive modifier events before sending them or the
client will crash.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We shouldn't free &modifier_invalid because it wasn't allocated
with malloc()
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
implement 'modifier' event to communicate available formats and modifiers
to the client and support zwp_linux_dmabuf_v1 interface version 3.
v2: handle zero modifiers case, deprecate 'format' event.
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
handle create_immed() dmabuf import requests and support
zwp_linux_dmabuf_v1_interface version 2.
v2: terminate client with INVALID_WL_BUFFER when reason
for create_immed failure is unknown.
[daniels: Bump wayland-protocols dependency.]
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
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 clarifies what is supposed to be the libweston code.
v2: screen-share.c is already in compositor/ instead.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Tested-by: Benoit Gschwind <gschwind@gnu-log.net>
Acked-by: Benoit Gschwind <gschwind@gnu-log.net>
[Pekka: rebased]
If we break; when lseek fails we can fail to do some legitimate tests
on remaining planes in a multi-plane buffer.
Signed-off-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This allows renderers to use that struct to create their own dmabufs,
in case they can’t import the one provided by the client directly but
know how to convert it into a format they can render.
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Differential Revision: https://phabricator.freedesktop.org/D332
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
v2 changes:
- implement the revised protocol
- add basic sanity checks when creating buffer and check for support
- add way to attach user data to the dmabuf for renderer use
- bump max number of planes to 4 to follow DRM AddFb2 ioctl
- improve errors handling
- use separate linux_dmabuf_buffer fields for the different wl_resource
types
- as SERVER_ERROR code is no more, use a wl_display "generic" error for
emergency-disconneting a client we fail to process
- more documentation
- change y-invert from per-plane boolean to per-buffer flag
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Signed-off-by: Louis-Francis Ratté-Boulianne <lfrb@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>