The backend headers are renamed from compositor-foo.h to backend-foo.h to
better describe their purpose. These headers are public libweston API for each
specific backend.
The headers will also be used like
#include <libweston/backend-drm.h>
instead of
#include <compositor-drm.h>
to give them a more explicit namespace.
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>
Copy the damage region to scanout drm_plane_state which will be sent to
kernel during atomic state update.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
The plane property FB_DAMAGE_CLIPS provides a way to mark damaged
regions on the plane in framebuffer coordinates of the framebuffer
attached to the plane.
This patch adds a new member "damage" to compositor version of
drm_plane_state and set FB_DAMAGE_CLIPS property whenever damage is
available.
v2: Rebase, check if plane support FB_DAMAGE_CLIPS property before
setting it.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Since commit ee1d968e64 ("compositor-drm: Fall back if GBM surface fails with
modifiers"), drm_output_init_egl requires output->gbm_surface to be NULL, or
gbm_surface_create will not be called if HAVE_GBM_MODIFIERS is enabled but no
modifiers are supported by the plane. This could happen if _init_egl is called
after drm_ouptut_fini_egl drom drm_output_switch_mode.
Add an assert to guarantee the requirement and clears the gbm_surface pointer
after the surface is destroyed.
Signed-off-by: Philipp Zabel <p.pzabel@pengutronix.de>
If we cannot create a gbm_surface using a list of modifiers, fall back
to using the old pre-modifier version.
This fixes initialisation on systems where KMS supports modifiers but
the GBM driver does not, such as old i915 systems like Pine View using
the unified KMS driver but the old i915 Mesa driver.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Implement the get_release request of the zwp_surface_synchronization_v1
interface.
This commit implements the zwp_buffer_release_v1 interface. It supports
the zwp_buffer_release_v1.fenced_release event for surfaces rendered by
the GL renderer, and the zwp_buffer_release_v1.immediate_release event
for other cases.
Note that the immediate_release event is safe to be used for surface
buffers used as planes in the DRM backend, since the backend releases
them only after the next page flip that doesn't use the buffers has
finished.
Changes in v7:
- Remove "partial" from commit title and description.
- Fix inverted check when clearing used_in_output_repaint flag.
Changes in v5:
- Use the new, generic explicit sync server error reporting function.
- Introduce and use weston_buffer_release_move.
- Introduce internally and use weston_buffer_release_destroy.
Changes in v4:
- Support the zwp_buffer_release_v1.fenced_release event.
- Support release fences in the GL renderer.
- Assert that pending state buffer_release is always NULL after a
commit.
- Simplify weston_buffer_release_reference.
- Move removal of destroy listener before resource destruction to
avoid concerns about use-after-free in
weston_buffer_release_reference
- Rename weston_buffer_release_reference.busy_count to ref_count.
- Add documentation for weston_buffer_release and ..._reference.
Changes in v3:
- Raise NO_BUFFER for get_release if no buffer has been committed,
don't raise UNSUPPORTED_BUFFER for non-dmabuf buffers,
so get_release works for all valid buffers.
- Destroy the buffer_release object after sending an event.
- Track lifetime of buffer_release objects per commit, independently
of any buffers.
- Use updated protocol interface names.
- Use correct format specifier for resource ids.
Changes in v2:
- Raise UNSUPPORTED_BUFFER at commit if client has requested a
buffer_release, but the committed buffer is not a valid linux_dmabuf.
- Remove tests that are not viable anymore due to our inability to
create dmabuf buffers and fences in a unit-test environment.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
Implement the set_acquire_fence request of the
zwp_surface_synchronization_v1 interface.
The implementation uses the acquire fence in two ways:
1. If the associated buffer is used as GL render source, an
EGLSyncKHR is created from the fence and used to synchronize
access.
2. If the associated buffer is used as a plane framebuffer,
the acquire fence is treated as an in-fence for the atomic
commit operation. If in-fences are not supported and the buffer
has an acquire fence, we don't consider it for plane placement.
If the used compositor/renderer doesn't support explicit
synchronization, we don't advertise the protocol at all. Currently only
the DRM and X11 backends when using the GL renderer advertise the
protocol for production use.
Issues for discussion
---------------------
a. Currently, a server-side wait of EGLSyncKHR is performed before
using the EGLImage/texture during rendering. Unfortunately, it's not clear
from the specs whether this is generally safe to do, or we need to
sync before glEGLImageTargetTexture2DOES. The exception is
TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
and then glBindTexture for any changes to take effect.
Changes in v5:
- Meson support.
- Make explicit sync server error reporting more generic, supporting
all explicit sync related interfaces not just
wp_linux_surface_synchronization.
- Fix typo in warning for missing EGL_KHR_wait_sync extension.
- Support minor version 2 of the explicit sync protocol (i.e., support
fences for opaque EGL buffers).
Changes in v4:
- Introduce and use fd_clear and and fd_move helpers.
- Don't check for a valid buffer when updating surface acquire fence fd
from state.
- Assert that pending state acquire fence fd is always clear
after a commit.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
renderer.
- Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
- Dup the acquire fence before passing to EGL.
Changes in v3:
- Keep acquire_fence_fd in surface instead of buffer.
- Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
renderer.
- Move comment about non-ownership of in_fence_fd to struct
drm_plane_state definition.
- Assert that we don't try to use planes with in-fences when using the
legacy KMS API.
- Remove unnecessary info from wayland error messages.
- Handle acquire fence for subsurface commits.
- Guard against self-update in fd_update.
- Disconnect the client if acquire fence EGLSyncKHR creation or wait
fails.
- Use updated protocol interface names.
- User correct format specifier for resource ids.
- Advertise protocol for X11 backend with GL renderer.
Changes in v2:
- Remove sync file wait fallbacks.
- Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
fence, but the committed buffer is not a valid linux_dmabuf.
- Don't put buffers with in-fences on planes that don't support
in-fences.
- Don't advertise explicit sync protocol if backend does not
support explicit sync.
Signed-off-by: Alexandros Frantzis <alexandros.frantzis@collabora.com>
This will cause gbm_surface_create_with_modifiers to fail on drivers
where modifiers are not yet supported (e.g. amdgpu). We need to make
sure we only end up using gbm_surface_create in this case.
This fixes the remoting plugin on these drivers.
Signed-off-by: Scott Anderson <scott.anderson@collabora.com>
In patch 5d767416c1 we simplified a bit the way in which the
compositing mode was being printed with the purpose to improve
weston-debug. It seems we forgot to use the mode when RENDER-only mode
is being used, so this patch fixes that.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
Add missing drm_plane_state_put_back in case the view's pixel format
does not match any of the tested plane's supported formats.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
This fixes the situation when using only plane-state mode for
compositing there's no obvious debug message stating that. This patch
makes it slightly better/easier to dermine what mode the compositor is
using currently.
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
This fixes warnings like ``may be used uninitialized''
libweston/compositor-drm.c: In function 'drm_device_is_kms':
libweston/compositor-drm.c:6374:12: warning: 'id' may be used uninitialized in this function [-Wmaybe-uninitialized]
b->drm.id = id;
Signed-off-by: Marius Vlad <marius.vlad0@gmail.com>
Use the pixel format table to parse format names. This makes the parser
recognize almost all DRM format names.
Not all formats are usable, but we rely on the use to fail
appropriately. What we can use depends on the drivers anyway.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add support virtual output for streaming image to remote output by
remoting-plugin which will be added by the patch:
"Add remoting plugin for output streaming."
The gbm bo of virtual output is the linear format.
Virtual output is implemented based on a patch by Grigory Kletsko
<grigory.kletsko@cogentembedded.com>.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Store usage flags of gbm bo in drm_output in order to specify the bo
format for each output. A following patch will add a new type of
drm_output which requires different gbm_bo_flags.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Not every output will have a backlight control, and even if it does we
may just not be able to find it. Not having backlight control isn't an
error, so don't spam the log with it, as doing so can confuse users into
thinking this is an actual error which is responsible for their real
problems.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Use the DRM connector "non-desktop" property to mark weston_heads that
represent head mounted displays and other non-standard displays that the
desktop should not be extended to.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Implement drm_view_is_opaque() using weston_view_is_opaque(). Also, use
weston_view_is_opaque() directly in drm_output_propose_state(), with the
clipped_view.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Add a 'drm-debug' scope which prints verbose information about the DRM
backend's repaint cycle, including the decision tree on how views are
assigned (or not) to planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Shift up our calculation of the flags we use for atomic commits. We will
later use this to differentiate between test-only and full commits when
printing debug information inside drm_output_state_apply_atomic.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Linux v4.7 introduced a new connector type for display parallel
interface (DPI). Add DPI to the list of connectors in the DRM
backend of Weston as well. This avoid DPI connectors showing up
as UNNAMED.
Signed-off-by: Stefan Agner <stefan@agner.ch>
THe KMS AddFB call can fail for any reason at all: format/modifier not
suitable, stride not aligned, allocation not contiguous, etc. If this
happens with Weston's own buffers, the result is bad - no composition
output.
Failing AddFB from user-supplied buffers though, is not an error. The
user can't necessarily allocate suitable buffers, nor does it have to.
Don't spam the log with warnings when we fail on user buffers.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>
In the RENDERER_ONLY state proposal mode, we don't actually have a
viable configuration to test, because we won't get a renderer buffer
until after assign_planes - where we're called from - has completed.
This can result in us trying to test a configuration with the CRTC and
connectors active, but no planes active, which the kernel can
legitimately fail.
If we're working in renderer-only mode, just return the state we have
without trying to test it first, and let the kernel fill it in later.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Derek Foreman <derek.foreman.samsung@gmail.com>
The backend begins with a series of #defines of libdrm tokens, in case
the libdrm we build against is too old.
Commit efdebbc4e8 ("configure.ac: bump libdrm requirement to 2.4.68")
did what it said on the box; since we now depend on a relatively modern
libdrm, we can get rid of most of our compatibility defines.
DRM_CAP_TIMESTAMP_MONOTONIC was added in libdrm 2.4.47 (f8f1f6e37ae2).
DRM_CLIENT_CAP_UNIVERSAL_PLANES was added in libdrm 2.4.55
(8fc62ca8ac01).
DRM_CAP_CURSOR_WIDTH and HEIGHT were added in libdrm 2.4.68
(cc9a53f076d4).
Remove these four fallback definitions.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derek.foreman.samsung@gmail.com>
Now that we can sensibly test proposed plane configurations with atomic,
sprites are not broken.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Since we now incrementally test atomic state as we build it, we can
loosen restrictions on what we can do with planes, and let the kernel
tell us whether or not it's OK.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
a0f8276fe8 ("compositor-drm: Disallow overlapping overlay planes") was
a little too pessimistic in rejecting occluded views. Whilst it
correctly prevented overlay planes from occluding each other, it also
prevented overlay planes from occluding the scanout plane.
This is undesirable: the primary/scanout plane is specified to stack
strictly below all overlay planes, so there is no need to reject a plane
from consideration for scanout due to being occluded by an overlay
plane.
Shift the check downwards so it only applies to overlay rather than
scanout planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In the plane-only mode, we try to place every view on a hardware plane,
and fail if we can't do this. This requires a full walk of the scene
graph to come up with a complete configuration in order to be able to
test.
In mixed mode, we know at least some visible views will fail to be
promoted to planes and must be composited via the renderer. In order to
still use some planes where possible, we use atomic modesetting's
test-only mode to incrementally test configurations.
We know that the renderer output will always be visible, and because it
is the renderer, that it will be occupying the scanout plane underneath
everything else. The actual renderer buffer doesn't materialise until
after assign_planes, because it cannot know what to render until then.
However, in order to test whether a configuration is valid, we need the
renderer buffer in the scanout plane. For testing, we fake this by
temporarily stealing the old buffer - if it seems sufficiently
compatible - and placing it in the state we construct. This is used to
test whether or not a renderer buffer will work with the addition of
overlay planes.
Doing this incremental testing will allow us to enable plane usage for
atomic by default, since we know ahead of time that our chosen plane
configuration will work.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add a new mode, which attempts to construct a scene exclusively using
planes. This is a building block for incrementally testing and
constructing state: in the plane-only mode, we test the state exactly
once, when we have constructed a full set of planes and want to know if
it works or not.
When using the renderer, we need to incrementally test views one by one
to see if they will work on planes, falling back to the renderer if not.
This test is different, since the scanout plane will be occupied by the
renderer's buffer. Testing using the renderer or client buffers may have
completely different characteristics, so we need two passes: first,
constructing a state with only planes and testing if that succeeds,
falling back later to a mixed renderer/plane mode which tests
incrementally.
This implements the first mode, and preferentially attempts to use it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This will never work, so don't even try to do it.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The atomic API can allow us to test state before we apply it, to see if
it will be valid. Use this when we construct a plane configuration, to
see if it has a chance of ever working. If not, we can fail
assign_planes early.
This will be used in later patches to incrementally build state by
proposing and testing potential configurations one at a time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Return a pointer to the plane state, rather than returning its
underlying weston_plane. This eliminates any ambiguity between placing
client buffers on planes, and placing them through the renderer.
drm_output_propose_state is only concerned with preparing, testing, and
returning DRM state objects. Assigning views to weston_planes only
happens later, inside drm_assign_planes. This makes that split more
clear.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add support for multiple modes to drm_output_propose_state. Currently we
intend to operate in three modes: planes-only (no renderer buffer,
client buffers in planes only), mixed-mode (promote client buffers to
planes where possible, falling back to the renderer where not), and
renderer-only (no plane usage at all).
We want to use the first (planes-only) mode where possible: it can avoid
us having to allocate buffers for the renderer, and it also gives us the
best chance of the optimal configuration, with no composition. In this
mode, we walk the scene looking at all views, trying to put them in
planes, and failing as soon as we find a view we cannot place in a
plane.
In the second mode, rather than failing, we assign those views which
cannot be on a plane to the renderer, and allow the renderer to
composite them.
In the third mode, planes are not usable, so everything but the cursor
goes to the renderer. We will use this when we cannot use the planes-only
mode (because some views cannot be placed in planes), but also cannot
use the 'mixed' mode because we have no renderer buffer yet. Since we
walk the scene graph from top to bottom, using atomic modesetting we
will determine if planes can be promoted in mixed mode by placing a
renderer buffer at the bottom of the scene, placing a cursor buffer if
applicable, then testing if we can add overlay planes to this mode.
Without a buffer from the renderer, we cannot do these tests, so we push
everything through the renderer and then switch to mixed mode on the
next repaint.
This patch implements the mixed and renderer-only modes (previously
differentiated only by the sprites_are_broken flag), with the
planes-only mode being left for a later patch.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When the sprites_are_broken variable is set, do not attempt to promote
client surfaces to the scanout plane.
We are currently assuming that every client buffer will be compatible
with the scanout plane, but that is not the case, particularly with more
exotic tiled/compressed buffers. Once we promote the client buffer to
scanout, there is no going back: if the repaint fails, we do not mark
this as failed and go back to repaint through composition.
This permanently removes the ability for scanout bypass when using the
non-atomic path. Future patches lift the restriction when using atomic
modesetting, as we can actually test and ensure that the view is
compatible with scanout.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The scanout plane strictly stacks under all overlay planes, and the
cursor plane above. However, the stacking of overlay planes with respect
to each other is undefined.
We can control the stacking order of overlay planes with the zpos
property, though this significantly complicates plane assignment. In the
meantime, simply disallow assigning a view to an overlay, when it
overlaps another view which is already on an overlay. This ensures
stacking order is irrelevant, since the planes never intersect each
other.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
When trying to assign planes, keep track of the areas which are
already occluded, and ignore views which are completely occluded. This
allows us to build a state using planes only, when there are occluded
views which cannot go into a plane behind views which can.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Tested-by: Emre Ucan <eucan@de.adit-jv.com>
Pekka Paalanen
Deepak Rawat
Philipp Zabel
Philipp Zabel
Daniel Stone
Marius Vlad
Alexandros Frantzis
Thomas Zimmermann
Scott Anderson
Marius Vlad
Pekka Paalanen
Arkadiusz Hiler
Tomohito Esaki
Stefan Agner