- lease will be revoked when the destructor is called
- destructors now actually destroy the resources
- remove revoked event entirely
- and a buch more

Signed-off-by: Marius Vlad <marius-cristian.vlad@nxp.com>

Attempt to answer the question on everyone's lips.

Signed-off-by: Daniel Stone <daniels@collabora.com>

Pekka Paalanen authored Aug 16, 2018 and Daniel Stone committed Aug 27, 2018

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>

Harsha Manjula Mallikarjun authored Aug 07, 2018 and Pekka Paalanen committed Aug 10, 2018

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>

Harsha Manjula Mallikarjun authored Aug 07, 2018 and Pekka Paalanen committed Aug 08, 2018

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>

Pekka Paalanen authored Jul 14, 2018 and Daniel Stone committed Aug 06, 2018

Taken from Pekka's wayland/wayland@630c25f4 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 efdebbc4 ("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>

Val Packett authored Jul 22, 2018 and Daniel Stone committed Jul 22, 2018

Happened mostly with neovim's xclip usage.

[daniels: Added more cases.]

Reviewed-by: Daniel Stone <daniels@collabora.com>

eucan authored May 24, 2018 and Daniel Stone committed Jul 22, 2018

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>

eucan authored Jun 05, 2018 and Daniel Stone committed Jul 22, 2018

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>

Emilio Pozuelo Monfort authored Jul 12, 2018 and Daniel Stone committed Jul 13, 2018

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>

Emilio Pozuelo Monfort authored Jul 12, 2018 and Daniel Stone committed Jul 13, 2018

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>

a0f8276f ("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>

Tomohito Esaki authored Jul 10, 2018 and Pekka Paalanen committed Jul 10, 2018

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>