Commit Graph

6551 Commits

Author SHA1 Message Date
Pekka Paalanen
9b72eb7930 xwm: convert WM_DEBUG into a weston-debug scope
Instead of a compile time choice, offer the XWM debugging messages
through the weston-debug protocol and tool on demand. Users will not
need to recompile weston to get XWM debugging, and it won't flood the
weston log.

The debug scope needs to be initialized in launcher.c for it be
available from start, before the first X11 client tries to connect and
initializes XWM.

Signed-off-by: Pekka Paalanen <pq@iki.fi>

pass the wm_debug scope to weston_debug_scope_printf API to append
the scopename to the timestr

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>
2018-09-17 13:29:48 +01:00
Pekka Paalanen
b3b0065598 xwm: move FILE to the callers of dump_property()
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>
2018-09-17 13:29:48 +01:00
Pekka Paalanen
0a3ef9902a xwm: dump_property() to use FILE internally
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>
2018-09-17 13:29:48 +01:00
Pekka Paalanen
d3630ed489 compositor: offer logs via weston-debug
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>
2018-09-17 13:29:48 +01:00
Pekka Paalanen
b9fdc14b2a clients: add weston-debug
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>
2018-09-17 13:29:47 +01:00
Pekka Paalanen
771b7cfc11 compositor: add option to enable weston_debug
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>
2018-09-17 13:29:24 +01:00
Pekka Paalanen
a5630eafec libweston: add weston_debug API and implementation
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>
2018-09-17 13:29:23 +01:00
Pekka Paalanen
4fc1ee8d5b protocol: add weston-debug.xml
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>
2018-09-11 15:24:46 +01:00
Matteo Valdina
3ebbc6b5df gl-renderer: Explicitly zeroing the offset for 2^ plane of SHM_FOMRAT_YUYV
This fix a crash, when gl-renderer uploads the 2^ texture for YUYV.
The pixels buffer was offset of a random value.
2018-08-31 09:47:59 -05:00
Daniel Stone
7d0170cf8a CONTRIBUTING: How do I get started?
Attempt to answer the question on everyone's lips.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2018-08-28 17:55:02 +01:00
Pekka Paalanen
d117f33d9b man: make substitutions meson-friendly
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>
2018-08-27 10:52:35 +01:00
Derek Foreman
836b053091 configure.ac: Reopen master for regular development 2018-08-24 13:43:34 -05:00
Derek Foreman
030e7d40fe configure.ac: bump to version 5.0.0 for the official release 2018-08-24 12:39:33 -05:00
Stefan Agner
30e283de70 compositor-drm: add DPI connector type
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>
2018-08-20 17:11:38 +02:00
Derek Foreman
4533451028 configure.ac: bump to version 4.0.94 for the RC2 release 2018-08-17 11:20:27 -05:00
Derek Foreman
76829fc4ea input: Send unique keymap file descriptors to clients
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>
2018-08-17 09:25:24 -05:00
Derek Foreman
f8f7fd69df input: add weston_keyboard_send_keymap helper function
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>
2018-08-17 09:25:21 -05:00
Derek Foreman
dc1418ae8e configure.ac: bump to version 4.0.93 for the RC1 release 2018-08-10 13:03:57 -05:00
Harsha M M
46cbd0a7f5 ivi-shell: Remove the compositor destory listener from list during de-init
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>
2018-08-10 13:23:14 +03:00
Harsha M M
b8b2c72709 libweston: Remove signals from the list during de-init
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>
2018-08-08 12:22:24 +03:00
Will Thompson
103dc42b5e
doc: fix typos in CONTRIBUTING.md
* 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>
2018-08-07 15:19:01 +01:00
Daniel Stone
8798fa7fdf doc: Use GitLab MRs for patches, not the list
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>
2018-08-07 14:38:38 +01:00
Daniel Stone
f987cb98ef README: Move to Markdown, rewrite introduction
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>
2018-08-07 14:38:24 +01:00
Daniel Stone
3a6fa200b7 doc: Update CONTRIBUTING for Weston
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>
2018-08-06 11:55:43 +01:00
Pekka Paalanen
2e3915f1bf Add CONTRIBUTING.md document
Taken from Pekka's wayland/wayland@630c25f4c1 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>
2018-08-06 11:55:40 +01:00
Derek Foreman
0335e44731 configure.ac: bump to version 4.0.92 for the beta release 2018-07-27 11:45:59 -05:00
Daniel Stone
48687982b5 compositor-drm: Remove addfb warning for user buffers
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>
2018-07-27 11:21:10 -05:00
Daniel Stone
1178922590 compositor-drm: Don't test render-only atomic configuration
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>
2018-07-27 11:20:47 -05:00
Daniel Stone
8c9556c57d compositor-drm: Remove unnecessary libdrm defines
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>
2018-07-27 11:20:25 -05:00
Greg V
3ea5437dbd xwayland/selection: do not remove NULL property_source
Happened mostly with neovim's xclip usage.

[daniels: Added more cases.]

Reviewed-by: Daniel Stone <daniels@collabora.com>
2018-07-22 11:37:58 +01:00
Emre Ucan
67546bed04 ivi-shell: use install paths in example config
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>
2018-07-22 11:17:40 +01:00
Emre Ucan
cf4113c629 ivi-shell: listen compositor wake_signal
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>
2018-07-22 11:06:38 +01:00
Derek Foreman
280b730144 configure.ac: bump to version 4.0.91 for the alpha release 2018-07-13 11:32:29 -05:00
Emilio Pozuelo Monfort
cce820dcaf simple-dmabuf-drm: fix build with --disable-egl
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>
2018-07-13 16:13:32 +01:00
Emilio Pozuelo Monfort
1166f8e9a1 simple-dmabuf-drm: require zwp_linux_dmabuf_v1 v3
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>
2018-07-13 16:13:23 +01:00
Daniel Stone
678aabe829 compositor-drm: Enable planes for atomic
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
9fe4bf8863 compositor-drm: Relax plane restrictions for atomic
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
b41abf9c84 compositor-drm: Allow scanout plane to be occluded by overlay
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
a284d271f1 compositor-drm: Incrementally test plane states in mixed mode
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>
2018-07-11 14:17:52 +01:00
Daniel Stone
d12e51646a compositor-drm: Add planes-only mode to state proposal
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>
2018-07-11 13:08:57 +01:00
Daniel Stone
ca6fbe3c93 compositor-drm: Never lift solid surfaces to planes
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>
2018-07-11 12:50:23 +01:00
Daniel Stone
bb6c19f7bb compositor-drm: Add test-only mode to state application
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>
2018-07-11 12:49:53 +01:00
Daniel Stone
f829062ef4 compositor-drm: Return plane state from plane preparation
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>
2018-07-11 12:45:07 +01:00
Daniel Stone
f7a2f835ae compositor-drm: Add modes to drm_output_propose_state
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>
2018-07-11 12:24:55 +01:00
Daniel Stone
44abfaaffd compositor-drm: Use sprites_are_broken for scanout plane
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>
2018-07-11 12:24:55 +01:00
Daniel Stone
a0f8276fe8 compositor-drm: Disallow overlapping overlay planes
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>
2018-07-11 12:24:55 +01:00
Tomohito Esaki
ddaf95c5a1 libweston: Fix clear timing of output repainted flag
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>
2018-07-10 15:40:52 +03:00
Daniel Stone
8108239c39 compositor-drm: Ignore occluded views
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>
2018-07-10 11:12:27 +01:00
Daniel Stone
231ae2f33b compositor-drm: Ignore views on other outputs
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>
2018-07-10 11:12:27 +01:00
Daniel Stone
ee1aea7cd1 compositor-drm: Split drm_assign_planes in two
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>
2018-07-10 11:12:27 +01:00