We had two non-pkg-config check paths in the configure script, to
support XCB functionality used before XCB had had an accompanying
release: xcb_poll_for_queued_event (released in 1.8, 2012), and a
usable XKB event mechanism (released in 1.9, 2013).
Convert the former to a version-based hard dependency, and the latter to
a version-based soft dependency. This avoids two compiler checks.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Some variables were previously only set inside conditions, making their
output empty.
Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Reviewed-by: Daniel Stone <daniels@collabora.com>
- ivi-shell/hmi-controller.c:41: a to an
- ivi-shell/hmi-controller.c:1296: Duplicated 'a'
- ivi-shell/ivi-layout-export.h:28: An to A
Signed-off-by: Abdur Rehman <arehmanq199@gmail.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
When we create a new view, assign it to the primary plane from the
beginning.
Currently, every view across the compositor will be assigned to a plane
during every repaint cycle of every output: the DRM renderer's
assign_planes hook will either move a view to a drm_plane, or to the
primary plane if a suitable drm_plane could not be found for the output
it is on. There are no other assign_planes implementation, and the
fallback when none is provided, is to assign every view to the primary
plane.
DRM's behaviour is undesirable in multi-output situations, since it
means that views which were on a plane on one output will be demoted to
the primary plane; doing this causes damage, which will cause a spurious
repaint for the output. This spurious repaint will have no effect on the
other output, but it will do the same demotion of views to the primary
plane, which will again provoke a repaint on the other output.
With a simple fix for this behaviour (i.e. not moving views which are
only visible on other outputs), the following behaviour is observed:
- outputs A and B are present
- views A and B are created for those outputs respectively, with SHM
buffers attached; view->plane == NULL for both
- current buffer content for views A and B are uploaded to the
renderer
- output A runs its repaint cycle, and sets keep_buffer to false on
surface B's output, as it can never be promoted to a plane; it does
not move view B to another plane
- output B runs its repaint cycle, and moves view B to the primary
plane
- weston_view_assign_to_plane has work to do (as the plane is changing
from NULL to the primary plane), calls weston_surface_damage and
calls weston_surface_damage
- weston_surface_damage re-uploads buffer content, possibly from
nowhere at all; e508ce6a notes that this behaviour is broken
Assigning views to the primary plane when created makes it possible to
fix the DRM assign_planes implementation: assign_planes will always set
keep_buffer to true if there is any chance the buffer can ever be
promoted to a plane, regardless of view configruation. If the buffer
cannot be promoted to a plane, it must by definition never migrate from
the primary plane. This means that there is no opportunity to hit the
same issue, where the buffer content has already been discarded, but
weston_view_assign_to_plane is not a no-op.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Try to harmonise the various plane-import paths a little bit, starting
with reshuffling and commenting the conditions to do so.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1413
Forcing DPMS on when we lose our session may force an expensive modeset
operation, which is pointless if the next consumer (another compositor,
or the console) is going to do a modeset. These should force DPMS on
regardless.
This actively causes problems for the DRM backend, in that it may
actually require a repaint to set coherent state for DPMS off -> DPMS on
transitions, which is very much not what we want when going offscreen.
As DRM is the only backend which actually implements DPMS, just remove
this call.
Differential Revision: https://phabricator.freedesktop.org/D1483
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This always changes the state to ACTIVE when we enter the session,
whereas the previous implementation preserved the state (i.e. if state
was SLEEPING on exit, it would be restored to SLEEPING, but also with a
repaint). This seems more helpful behaviour, however: if you enter a
session, it's probably in order to interact with it.
Differential Revision: https://phabricator.freedesktop.org/D1482
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Even if we do have a framebuffer matching the mode, we immediately
schedule a repaint, meaning we either do work for no reason, or show
stale content before we bring up the new content.
Delete this and just let repaint deal with it.
Differential Revision: https://phabricator.freedesktop.org/D1481
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
This will be used so we can later determine the compatibility of drm_fbs
without needing to introspect external state.
Differential Revision: https://phabricator.freedesktop.org/D1487
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
This makes it sign-compatible with weston_output->{width,height}.
Differential Revision: https://phabricator.freedesktop.org/D1486
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Everyone else uses fb->fd rather than pulling the FD back out of GBM.
Use that in the destroy callback too.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1406
No functional change.
Differential Revision: https://phabricator.freedesktop.org/D1484
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
No need to walk the CRTC list every time looking for CRTC indices, when we
already have the CRTC index stashed away. Taking the plane as an argument
also simplifies things a little for callers, and future-proofs for a
potential future KMS API which passes a list of supported CRTC IDs rather
than a bitmask of supported CRTC indices.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1407
Clarify the difference between crtc_id (DRM object) and pipe (index into
drmModeRes->crtcs array, possible_crtcs bitmask).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Differential Revision: https://phabricator.freedesktop.org/D1405
X client's don't have a wl_client associated with their
weston_desktop_client, so make sure to not use it.
Signed-off-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
We know we're not going to succeed if the binary isn't installed, so
skip the test in that case.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Avoid any buffer overflows here by checking we don't go over PATH_MAX
with stupid module names.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Destroying a wl_cursor will attempt to access the wl_display, which
we have just freed. Avoid a segfault by destroying the cursor images
before we destroy the display.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dima Ryazanov <dima@gmail.com>
No need to add protocol/, as it's already handled by an explicit
compiler include path.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dima Ryazanov <dima@gmail.com>
Add support for basic text file loading, to facilitate more expansive
testing of its UTF-8 text editing support.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Fixing 89c2f637b9, also set the output's frame_cb for the Pixman
renderer, not just GL. Fixes a segfault when using compositor-wayland
with --use-pixman.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Dima Ryazanov <dima@gmail.com>
Call eglMakeCurrent before destroying the native EGL window, similar to what
other sample clients are already doing.
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
When a window is being closed, the frame_done callback often runs after
the output is already destroyed, i.e:
wayland_output_start_repaint_loop
input_handle_button
wayland_output_destroy
frame_done
To fix this, destroy the callback before destroying the output.
(Also, fix the type of output in frame_done: it's passed in
a wayland_output, not a weston_output.)
Signed-off-by: Dima Ryazanov <dima@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
The xwayland window type XWAYLAND is not handled by the shell at all,
instead libweston-desktop maps such surfaces itself. However, it forgot
to set weston_surface::is_mapped and weston_view::is_mapped.
weston_surface::is_mapped affects the behaviour of weston_view_unmap()
and weston_surface_attach().
weston_view::is_mapped affects the behaviour of weston_view_unmap() and
weston_view_destroy().
When manually mapping a window of type XWAYLAND, mark both the view and
surface as mapped. This follows the expections in libweston, even though
the meaning of is_mapped is not clearly defined for either surface or
view.
Also, when the XWAYLAND window is manually unmapped, unmap the
weston_surface. This updates weston_surface::is_mapped to reflect the
state. However, as a side-effect it will also unmap all sibling views,
should any exist.
v2: rename surface_base to wsurface
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Add documentation (asserts) that show that windows of types XWAYLAND are
never registered with the shell.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Setting to a constant is much easier to read and grep for than setting to
a computed variable.
There are no functional changes.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Add an assert to ensure that a window of type XWAYLAND is never
attempted with a parent. Following the code though, the assert can be
made even stricter by allowing only TRANSIENT to have a parent.
This is essentially adding documentation.
v2: use stricter assert
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Helps debugging initial placement problems.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Helps debugging X11 window positioning issues.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Following on from b8c16c995b, extend the family tree being tested by
place_above and place_below a little, ensuring that subsurfaces can't be
placed above or below surfaces which are related to them, but aren't
their immediate parent or sibling.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Fix the following error from 'make distcheck':
CC libweston/wayland_backend_la-compositor-wayland.lo
../../libweston/compositor-wayland.c:54:51: fatal error: xdg-shell-unstable-v6-client-protocol.h: No such file or directory
#include "xdg-shell-unstable-v6-client-protocol.h"
Files generated with the scanner belong in nodist_*_SOURCES, not with
the regular sources.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Daniel Stone
Yann E. MORIN
Emmanuel Gil Peyrot
Abdur Rehman
Giulio Camuffo
Bryce Harrington
Dima Ryazanov
Pekka Paalanen
Ryo Munakata