This is preparation for using the weston-debug infrastructure for
WM_DEBUG. dump_property() may be called from different debugging
contexts and often needs to be prefixed with more information.
An alternative to this patch would be to pass in the weston_debug_scope
as an argument to dump_property(), but then all callers would need to be
converted to weston-debug infra in a single commit.
Therefore require the callers to provide the FILE* to print to.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Write the output of dump_property() out in one log call. When multiple
processes (weston and Xwayland) are writing to the same file, this will
keep the property dump uninterrupted by Xwayland debug prints.
This is also preparation for more development in the same direction.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This registers a new weston-debug scope "log" through which one can get
live log output interspersed with possible other debugging prints. This
is implemented by passing the format and varargs received in our usual
logging entrypoints through to the debug scope as well.
Anywhere where the varargs set is used twice (once for vfprintf, another
for the debug scope), we copy the va_list in order to avoid reusing it,
which leads to memory safety issues.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
A tool for accessing the zcompositor_debug_v1 interface features.
Installed along weston-info, because it should be potentially useful for
people running libweston-based compositors.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Added a man page for weston-debug client
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
[Pekka: fixed 'missing braces aroudn initializer' warning]
Add --list and --all arguments, using interface advertisement.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Let users enable the compositor debug protocol on the compositor command
line. This allows weston-debug tool to work.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
weston_debug is both a libweston API for relaying debugging messages,
and the compositor-debug wayland protocol implementation for accessing those
debug messages from a Wayland client.
weston_debug_compositor_{create,destroy}() are private API, hence not
exported.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
append the debug scope name along with the timestamp in
weston_debug_scope_timestamp API
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add explicit advertisement of debug scope names.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
This is a new debugging extension for non-production environments. The
aim is to replace all build-time choosable debug prints in the
compositor with runtime subscribable debug streams.
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Added new libweston-$MAJOR-protocols.pc file and install that
for external projects to find the XML files installed by libweston.
Signed-off-by: Maniraj Devadoss <Maniraj.Devadoss@in.bosch.com>
Use noarch_pkgconfig_DATA instead, add ${pc_sysrootdir}, drop
unnecessary EXTRA_DIST of weston-debug.xml.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Add explicit advertisement of available debug interfaces.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emre Ucan <eucan@de.adit-jv.com>
Change format of substituted variables to follow the pattern used by
configure_file() in Meson.
This helps the migration to Meson, making man/meson.build much cleaner.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
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>
Client may map any file descriptor opened for writing with PROT_WRITE
themselves. On linux, even a read-only file descriptor to an unlinked
file can be re-opened with write permission through /proc/self/fd.
The only way to prevent this is to create a memfd which
is subsequently write-sealed. Unfortunately this prevents clients
from mapping with MAP_SHARED, which is already in widespread usage.
To isolate and protect the keymap, whilst allowing MAP_SHARED clients
to continue to work, use a unique file descriptor for each
wl_keyboard resource.
Reviewed-by: Daniel Stone <daniels@collabora.com>
We've always had "send_keymap" internally, but some places failed to use
it. Since we also use this in the text backend, export it.
Reviewed-by: Daniel Stone <daniels@collabora.com>
During de-init ensure removal of compositor destroy notification
from list. Otherwise a dongling pointer is left behind which will
affect other plugins.
Signed-off-by: Harsha M M <harsha.manjulamallikarjun@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
During de-init ensure removal of added signals from list. Otherwise
a dongling pointer is left behind which will affect other plugins.
Signed-off-by: Harsha M M <harsha.manjulamallikarjun@in.bosch.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
* Cover letters are no more; presumably the changes since the previous
revision should be summarised in the MR
* Code should be indented with tabs, not implemented with tabs
Signed-off-by: Will Thompson <will@willthompson.co.uk>
Though Wayland and the protocols still use mail-based patch review,
Weston can now move to GitLab MRs with review through that system.
Add some documentation on how to submit patches through GitLab,
specifically targeted at people who may be familiar with GitLab review,
but not familiar with our rebasing microcommit workflow.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Move the README file to Markdown, and update it to attempt to explain
the current status and use of Weston.
The first sections are user-facing, so they can quickly understand what
Weston is, what it does, what it doesn't do, and how to go about using
it. The following sections on libweston and for distribution packagers
are left intact, but should probably be moved to separate documents.
This includes a screenshot of Weston running weston-terminal, Chrome and
simple-egl, which was taken by myself and subject to the same licensing
terms as the rest of the tree.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Change some Wayland-specific references to instead refer to Weston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Taken from Pekka's wayland/wayland@630c25f4c160 and follow-ups, use
Wayland's CONTRIBUTING document as a basis for Weston.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
The example weston.ini file uses source and build
directory paths. Therefore, it is only useful when
used on the same system that is used to build Weston.
We can use install paths instead of build/source paths
to fix this problem.
v2 changes:
- use $(westondatadir) instead of $(datadir)
Reported-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
If compositor wakes up from sleep state, we have
to trigger repaint for all outputs.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Just rely on getting the supported formats through the dmabuf
extension.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
We effectively require it as we don't react to dmabuf_format,
only to dmabuf_modifiers, so there's a chance we may not get
the supported formats information at all.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.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>
Since the repaint status of the flushed output may be reset if a output
repaint is failed, it is necessary to clear the repainted flag
immediately after output repaint flush/cancel.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
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>
When we come to assign_planes, try very hard to ignore views which are
only visible on other outputs, rather than forcibly moving them to the
primary plane, which causes damage all round and unnecessary repaints.
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>
Move drm_assign_planes into two functions: one which proposes a plane
configuration, and another which applies that state to the Weston
internal structures. This will be used to try multiple configurations
and see which is supported.
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>
Now that we collect information about which modifiers are supported for
KMS display, and are able to create KMS framebuffers with modifiers,
begin using the modifier-aware GBM API.
Client buffers from dmabuf already store multi-plane and modifier
information into drm_fb. Extend this to drm_fb_get_from_bo(), used for
wl_buffer, cursor, and gbm_surface buffers. wl_buffer buffers should by
convention not require modifiers. Cursor buffers must not require
modifiers, as they should be linear. Prior to this patch, GBM buffers
must have been single-planar, and able to used without explicitly naming
modifiers.
Using gbm_surface_create_with_modifiers allows us to pass the list of
modifiers acceptable to KMS for scanout to GBM, so it can allocate
multi-planar buffers or those which are otherwise only addressible with
modifiers. On platforms supporting and preferring modifiers for scanout,
this means that the gbm_bos we get from our scanout surface need to use
the extended API to query multiple planes, offsets, modifiers, etc.
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
Matteo Valdina
Daniel Stone
Pekka Paalanen
Derek Foreman
Stefan Agner
Harsha M M
Will Thompson
Greg V
Emre Ucan
Emilio Pozuelo Monfort
Tomohito Esaki