EGL_EXT_image_dma_buf_import_modifiers supports importing upto four dmabuf
planes into an EGLImage.
v2: correct PLANE3_PITCH token (Daniel Stone)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
pass over the modifier attributes to EGL.
v2: ensure same modifier is passed for all planes (Daniel Stone)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
implement 'modifier' event to communicate available formats and modifiers
to the client and support zwp_linux_dmabuf_v1 interface version 3.
v2: handle zero modifiers case, deprecate 'format' event.
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
EGL_EXT_image_dma_buf_import_modifiers allows querying the formats
and modifiers supported by the platform. expose these to the compositor.
v2:
- change calloc args (Daniel Stone)
- check for modifier support before querying formats (Daniel Stone)
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
handle create_immed() dmabuf import requests and support
zwp_linux_dmabuf_v1_interface version 2.
v2: terminate client with INVALID_WL_BUFFER when reason
for create_immed failure is unknown.
[daniels: Bump wayland-protocols dependency.]
Signed-off-by: Varad Gautam <varad.gautam@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
I ran Weston on a Nexus 4 mobile phone, with a native GNU/Linux userland,
and the latest Android kernel for that device from LineageOS [1].
calculate_refresh_rate() returned 1 (mHz), which gets rounded to 0 Hz later
and results in nothing being drawn to the screen.
This patch makes sure, that there is at least a refresh rate of 1 Hz, because
it returns the default refresh rate of 60 Hz otherwise.
[1]: https://github.com/LineageOS/lge-kernel-mako
Signed-off-by: Oliver Smith <ollieparanoid@bitmessage.ch>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
wl_surface_damage_buffer landed ages ago, but in order for GL to
use it the client must bind a wl_compositor version >= 4 (the
version where damage_buffer was introduced).
This patch updates the bind version and allows
eglSwapBuffersWithDamage to actually use the provided damage
rectangles instead of performing full surface damage.
Reviewed-by: Daniel Stone <daniels@collabora.com>
At the bottom of weston_output_finish_frame(), code exists to account
for flips which have missed the repaint window, by shifting them to lock
on to the next repaint window rather than repainting immediately.
This code only accounted for flips which missed their target by one
repaint window. If they miss by multiples of the repaint window, adjust
them until the next repaint timestamp is in the future. This will only
happen in fairly extreme situations, such as Weston being scheduled out
for a punitively long period of time. Nevertheless, try to help recovery
by still aiming for more predictable timings.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
commit a7cba1d4cd changed the way
the cursor plane is setup. Previously it was pre-emptively set
disabled for the next frame, and that would be changed at next
frame time if the cursor plane was to be used. It was changed
to be disabled at plane assignment time.
We disable the use of planes entirely by setting disable_planes to
a non-zero value, which bypasses all calls to assign_planes - so
if the plane was set-up in the previous frame it will retain its
state post-disable.
This leads to desktop zoom leaving the cursor plane in place when
it sets disable_planes.
This patch clears any stale cursor plane state from the redraw
handler if disable_planes is set so drm_output_set_cursor()
will do the right thing.
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reported-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reorder some paragraphs to be more logically ordered. Rewrite the
description of the backend-specific disable function to explain the
semantics instead of the mechanics. Remove the paragraph about
pending_output_list as unnecessary details.
Add a big fat comment on why we call output->disable() always instead of
only for actually enabled outputs.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
We make the differentiation where planes are an abstract framebuffer
with a position within a CRTC/output, and sprites are special cases of
planes that are neither the primary (base/framebuffer) nor cursor plane.
drm_sprite, OTOH, contains nothing that's actually specific to sprites,
and we end up duplicating a lot of code to deal with them, especially
when we come to use an entirely plane-based interface with atomic
modesetting.
Rename drm_sprite to drm_plane, to reflect that it's actually generic.
No functional changes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
[Pekka: dropped the removal of an unrelated comment]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
page_flip_pending is only be set when do a pageflip to a newly-rendered
buffer; if the flag is not set, we have landed in the start_repaint_loop
path where the vblank query fails, and thus we must pageflip to the same
buffer.
This test was not sufficient for what it was supposed to guard:
releasing framebuffers back. When using client-supplied framebuffers, it
is possible to reuse the same buffer multiple times, and we would send a
framebuffer-release event too early.
However, since we have a properly reference-counted drm_fb now, we can
just drop this test, and rely on the reference counting to prevent
too-early release of client framebuffers.
page_flip_pending now becomes exactly what the name suggests: a flag
which indicates whether or not we are expecting a pageflip event. Add
asserts here to verify that we never receive a pageflip event we weren't
expecting.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
vblank_pending is currently a bool, which is reset on every vblank
requests (i.e. sprite pageflip). This can occur more than once per
frame, so turn it into a callback, so we only fire frame-done when we've
collected all the events.
This fixes unexpected behaviour when multiple views per output have been
promoted to DRM planes.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Previously, framebuffers were stored as fb_current and fb_pending.
In this scheme, current was the last buffer that the kernel/hardware had
acknowledged displaying: a framebuffer would be created, set as
fb_pending, and Weston would request the kernel display it. When the
kernel signals that the request was completed and the hardware had made
the buffer current (i.e. page_flip_handler / vblank_handler), we would
unreference the old fb_current, and promote fb_pending to fb_current.
In other words, the view is 'which buffer has turned to light?'.
This patch changes them to a tristate of fb_last, fb_current and
fb_pending, based around the kernel's view of the current state.
fb_pending is used purely as a staging area for request construction;
when the kernel acknowledges a request (e.g. drmModePageFlip returns 0),
the previous buffer is moved to fb_last, and this new buffer to
fb_current. When the kernel signals that the request has completed and
the hardware has made the buffer current, we simply unreference and
clear fb_last, without touching fb_current/fb_pending.
The view here is now 'which state is current in the kernel?'.
As all state changes are incremental on the last state submitted to the
kernel, even if the hardware has not yet been able to make it current,
this simplifies state tracking: all state submissions will always be
relative to fb_current, rather than the previous
(fb_pending) ? fb_pending : fb_current.
The use of fb_pending is strictly bounded between a repaint cycle
(including a grouped set of repaints) beginning, and those repaints
being flushed to the kernel.
fb_current will always be valid between an output's first repaint
flush, and when a disable/destroy request has been processed. For a
plane, it will be valid when a repaint cycle enabling that plane has
been flushed, and when a repaint cycle disabling that plane has been
flushed.
fb_last is only present when a repaint request for the output/plane has
been submitted, but not yet completed by the hardware.
This is the same set of constructs which will be used for storing
plane/output state objects in future patches.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
We implement v2 so use that instead of the DRM_EVENT_CONTEXT_VERSION
macro.
The latter defines the version of the drmEventContext struct declared in
the header [used in the current build] and can be 2, 3 or even 1000.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Instead of setting state members directly in the drm_output_render
functions (to paint using Pixman or GL), just return a drm_fb, and let
the core function place it in state.
This brings damage handling in line with repaint state, so we do not
clear damage if repaint fails.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Call drm_output_render unconditionally, doing an early exit if we're
already rendering a client buffer on the primary plane.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
'next' is used as a framebuffer which has either been rendered but not
had a configuration request (pageflip or CRTC set) applied to it, or
when for a framebuffer that has had configuration requested but not
applied (delayed pageflip where the event has not been applied).
'current' is used as the last framebuffer for which we know
configuration has been fully applied, i.e. CRTC set executed or pageflip
requested and event received.
Rename these members to fb_current and fb_pending, doing some small
reordering of drm_output whilst in the vicinity.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Now that we have better types in drm_fb, use it for cursor buffers as
well. This gives us easier refcounting for our cursors, as well as a
unified buffer-destruction path.
Currently this makes no difference, as the KMS legacy cursor update API
uses GEM names directly, and never touches DRM FBs. However, the cursor
plane becomes a regular KMS plane under atomic, at which point we
require DRM FBs.
Take the opportunity to move to drm_fb ahead of time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Sometimes we need to duplicate an existing drm_fb, e.g. when
pageflipping to the same buffer to kickstart the repaint loop. To handle
situations like these, and simplify resource management for dumb and
cursor buffers, refcount drm_fb.
drm_fb_get_from_bo has a path where it may reuse a drm_fb, if the BO has
been imported and not released yet. As drm_fb_unref now relies on actual
refcounting (backed up by asserts), we add a balancing drm_fb_ref() to
the path where we return a reused drm_fb.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
We only need it for the GBM surface the FB was originally created
against; a mismatch here is very bad indeed, so no reason to pass it in
explictly every time rather than store it.
Following patches change drm_fb to be explicitly reference counted; in
order to reduce churn, rename drm_output_release_fb to drm_fb_unref
whilst changing its call signature here, even though it does not yet
actually perform reference counting.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The drm_fb destroy callback to mostly the same thing regardless of
whether the buffer is a dumb buffer or gbm buffer. This patch refactors
the common parts into a new function that can be called for both cases.
[daniels: Rebased on top of fb->fd changes, cosmetic changes.]
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
This uses the new pixel-format helpers, so we can also replace depth/bpp
with these.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalaneN@collabora.co.uk>
Rather than magically trying to infer what the buffer is and what we
should do with it when we go to destroy it, add an explicit type
instead.
In doing so, the test for dumb images (destroying them, but only if
they're not the 'live' ones) is removed. This was dead code, as the only
path which could cause us to shuffle images is drm_output_switch_mode.
This calls drm_output_release_fb before the images are reallocated in
drm_output_fini_pixman / drm_output_init_pixman, with the reallocation
unconditionally destroying the images, so can never be hit.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Make drm_output_set_cursor more deterministic, by calculating more state
and performing more plane manipulation, inside
drm_output_prepare_cursor_view.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Rather than duplicating knowledge of pixel formats across several
components, create a custom central repository.
Signed-off-by: Daniel Stone <daniels@collabora.com>
[Pekka: fix include paths and two copy-pastas]
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
HAVE_LIBDRM was used as a condition for the launcher infrastructure to
call libdrm.so functions. It was set by an independent test for libdrm,
which would silently continue if libdrm was not found. It was assumed
that if you enabled a feature that used libdrm at runtime, the test for
that feature would imply that HAVE_LIBDRM is also set. This was quite
subtle.
The only feature that actually uses libdrm.so at runtime is the DRM
backend. No other backend needs the libdrm calls in the launcher
infrastructure.
Therefore to simplify things, stop using HAVE_LIBDRM and use
BUILD_DRM_COMPOSITOR instead. If you enable the DRM compositor, you
automatically also get libdrm support in the launchers.
There are still things depending on LIBDRM_CFLAGS and LIBDRM_LIBS, so
the test cannot be removed completely.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
This way Wayland compositors will be aware of Weston's
"visible bounds" (and ignore its shadows).
Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
If wayland_output_create_common returns NULL, it means that
the output creation failed.
Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
struct wayland_output::name was used but never initialized.
Also zxdg_toplevel_v6_set_title was only called for windowed outputs,
and some compositors let you see the client's name even when it is
fullscreen (GNOME Shell's Activities menu for example).
So rename struct wayland_output::name to struct wayland_output::title and
precompute it on wayland_output_create_common(), so it can be later used
on xdg's set_title and frame_create.
v2: Move zxdg_toplevel_v6_set_title() before the wl_surface_commit()
as per Quentin Glidic's suggestion.
Signed-off-by: Sergi Granell <xerpi.g.12@gmail.com>
Reviewed-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
When the wheel tilt source is present, gcc complains that we don't
handle all possible enumeration values. We already ensure this cannot
happen in its only caller (handle_pointer_axis), but gcc doesn't
recognise this. Give it a default value to quiet the warning.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Implement new repaint_begin and repaint_flush hooks inside
weston_backend, allowing backends to gang together repaints which
trigger at the same time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
In preparation for grouping output repaint together where possible,
switch the per-output repaint timer, to a global timer which iterates
across all outputs.
This is implemented by storing the absolute time for the next repaint
for each output locally, and maintaining a global timer which iterates
all of them, scheduling the repaint for the first available time.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Pekka: The comment about 1 ms delay.]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
glibc 2.25 produces a warning when sysmacros.h is not directly included
but major() is used, as it is intended to be moved to sysmacros.h and
only there. Include it to keep the build happy.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
repaint_scheduled is actually cleverly a quad-state, disguised as a
boolean. There are four possible conditions for the repaint loop to be
in at any time:
- loop idle; no repaint will occur until specifically requested, which
may be never (repaint_scheduled == 0)
- loop schedule to begin: the loop was previously idle, but due to a
repaint-schedule request, we will call the start_repaint_loop hook
in the next idle task
- repaint scheduled: the compositor has definitively scheduled a
repaint request for this output, which will occur in fixed time
- awaiting repaint completion: the backend has not yet signaled
completion of the last repaint request, and the compositor will not
schedule another until it does so
All but the first condition were previously conflated as
repaint_scheduled == 1, but break them out into separate conditions to
aid clarity, backed up by some asserts.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
On startup, we cannot lock on to the repaint timer because it is unknown
to us. We deal with this by claiming that the moment of entry into the
repaint loop is the moment a frame returned, causing finish_frame to
delay our initial repaint to (refresh_time - repaint_delay), typically
around 9ms of utterly wasted time.
Add an explicit stamp == NULL, to determine that we are just beginning
our repaint loop, that the timings are in fact totally invalid, and that
it would be beneficial to repaint the output immediately. This will only
trigger when the display had previously been disabled or the previous
state is unknown, e.g. at startup, or coming back from DPMS off.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Rather than determining the time until next-frame repaint in relative
space (time until repaint), determine it first in absolute space, and
then later convert this to relative.
This will later allow us to store these per-output, so we can have a
single idle timer which will allow us to aggregate multiple repaints
together when timing allows.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Paralleling timespec_to_nsec, converts to milliseconds.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
[Pekka: added doc about flooring]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Weston will not repaint until previous update has been acked by a
pageflip event coming from the drm driver. However, some buggy drivers
won’t return those events or will stop sending them at some point and
Weston output repaints will completely freeze. To ease developers’ task
in testing their drivers, this patch makes compositor-drm use a timer
to detect cases where those pageflip events stop coming.
This timeout implementation is software only and includes basic
features usually found in a watchdog. We simply exit Weston gracefully
with a log message and an exit code when the timout is reached.
The timeout value can be set via weston.ini by adding a
pageflip-timeout=<MILLISECONDS> entry under [core]
section. Setting it to 0 disables the timeout feature.
v2:
- Made sure we would get both the pageflip and the vblank events before
stopping the timer.
- Reordered the error and success cases in
drm_output_pageflip_timer_create() to be more in line with the rest
of the code.
v3:
- Reordered (de)arming of the timer with the code around it to avoid it
being rearmed before the current dearming.
- Return the proper value for the dispatcher in the pageflip_timeout
callback.
- Also display the output name in case the timer fires.
v4:
- Reordered a forgotten timer rearming after its drmModePageFlip().
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=83884
Signed-off-by: Frederic Plourde <frederic.plourde at collabora.co.uk>
Signed-off-by: Emmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Makes the code easier to read and browse through.
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Don't import buffers which span multiple outputs, short-cut any attempt
to import SHM buffers, and ignore buffers with a global alpha set.
I'm not convinced all of these conditions entirely make sense, but this
at least makes them equally nonsensical.
Differential Revision: https://phabricator.freedesktop.org/D1414
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
And properly deconstruct it in drm_output_destroy.
Might be useful for finding out which modes are supported
before even setting them, in case we want to extend the
modesetting API.
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Previously in picking CRTC -> encoder -> connecting routing, we went for
the first triplet we found which claimed to work.
Preserving the existing routing means that startup will be faster: on a
multi-head system, changing the routing implies disabling both CRTCs,
then re-enabling them with a new configuration, which may involve
retraining links etc.
Furthermore, the existing routing may be set for a reason; each
CRTC/encoder is not necessarily as capable as the other, so the routing
may be configured to stay within such device limits.
Try where possible to respect the routing we pick up, rather than
blithely configuring our own.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Given that we can have render-only devices, or vgem in a class of its
own, ignore any non-KMS devices in compositor-drm's device selection.
For x86 platforms, this is mostly a non-issue since we look at the udev
boot_vga issue, but other architectures which lack this, and have
multiple KMS devices present, will hit this.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Reported-by: Thierry Reding <treding@nvidia.com>
Reported-by: Daniel Vetter <daniel.vetter@intel.com>
A handful of source files were not using the MIT Expat text in
COPYING. Update these files to bring them inline with the rest,
standardizing on the MIT Expat text.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Acked-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Remove the last usage of connector_allocator, which was to check for
displays which have been hot-unplugged, and replace it with an array
which doesn't rely on the connector IDs remaining below 32 (or 64).
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reported-by: Peter Senna Tschudin <peter.senna@collabora.com>
Rather than using connector_allocator to determine whether an output is
newly connected or not, use a list walk across all outputs instead.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reported-by: Peter Senna Tschudin <peter.senna@collabora.com>
crtc_allocator was used as a bitmask of CRTC IDs, so we didn't try to
use the same CRTC for multiple outputs. Unfortunately, this only works
to the extent that CRTC object IDs fit within the bitmask; though they
were previously, they are not guaranteed to be under 32 or even 64.
Replace the only use of crtc_allocator with a list walk across outputs.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reported-by: Peter Senna Tschudin <peter.senna@collabora.com>
When a client changes the subsurfaces state, we need to damage
them so the result is visible. We do that by flagging the surfaces
when the state changes and causing damage when committing the
state. This prevents normal repaints from considering these changes
until a commit has happened, and allows the client to atomically
schedule several changes.
This fixes the subsurface_z_order test, which is now marked as expected
to succeed.
Signed-off-by: Emilio Pozuelo Monfort <emilio.pozuelo@collabora.co.uk>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Reviewed-by: Micah Fedke <micah.fedke@collabora.co.uk>
The connector option is a part of drm_backend struct.
Therefore, it is not needed to pass it as an argument
to create_outputs function.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
weston can be started with --connector option to be initialized
with a particular output. But in the update_outputs this option
is not considered and output is created for all the available
connectors. This patch fixes this issue by considering
the option for connectors in the update_outputs.
Signed-off-by: Emre Ucan <eucan@de.adit-jv.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Acked-by: Daniel Stone <daniels@collabora.com>
This patch checks the attribute flags on incoming dmabufs and refuses to
put them overlays if they have any of the flags set (currently:
ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_Y_INVERT,
ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_INTERLACED and
ZWP_LINUX_BUFFER_PARAMS_V1_FLAGS_BOTTOM_FIRST), instead defaulting to
the gl-renderer which can handle some of the flags.
This check should be superceded by buffer transforms, when they become
available.
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Given that it's used by clients, it's really the very definition of
shared.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Derek Foreman <derekf@osg.samsung.com>
repaint_needed / repaint_scheduled are surprisingly subtle. Explode the
conditional with side-effects into more obvious separate calls, and
document what they do.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Hi Pekka,
On 23 January 2017 at 14:15, Pekka Paalanen <ppaalanen@gmail.com> wrote:
> On Fri, 20 Jan 2017 11:31:08 +0100
> Emilio Pozuelo Monfort <pochu@debian.org> wrote:
>> This version works for me...
>
> Hi guys,
>
> I found another guest to the party. Using net-misc/freerdp-2.0.0_pre20160722
> Weston master fails to build with:
>
>
> In file included from /usr/include/freerdp2/freerdp/codecs.h:25:0,
> from /usr/include/freerdp2/freerdp/freerdp.h:46,
> from /home/pq/git/weston/libweston/compositor-rdp.c:69:
> /home/pq/git/weston/libweston/compositor-rdp.c: In function ‘rdp_peer_context_new’:
> /usr/include/freerdp2/freerdp/codec/color.h:85:72: error: ‘FREERDP_PIXEL_FORMAT_TYPE_BGRA’ undeclared (first use in this function)
> [... snip ...]
>
> However, updating to net-misc/freerdp-2.0.0_pre20161219 allows things
> to build for me again. There is just one warning:
How about this fixup?
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
It got lost during the porting to the config API.
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Use different functions so we cannot load a libweston common module in
weston directly or the other way around.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This prevents loading a backend as a simple module. This will avoid
messing up with backends when we will introduce libweston common
modules.
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
As an option, allow to specify a mode (from the configuration file) by
its refresh rate.
Example of valid syntax:
- "mode=1920x1080" Select a 1920x1080 mode, refresh rate undefined.
- "mode=1920x1080@60" Select the (or one of the) 1920x1080 60 Hz mode.
Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Currently, layers’ order depends on the module loading order and it does
not survive runtime modifications (like shell locking/unlocking).
With this patch, modules can safely add their own layer at the expected
position in the stack, with runtime persistence.
v4 Reviewed-by: Giulio Camuffo <giuliocamuffo@gmail.com>
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
Acked-by: Daniel Stone <daniels@collabora.com>
[Pekka: fix three whitespace issues]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
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>
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
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>
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 parent of a subsurface can be used as a sibling in the place_below
and place_above calls. However this did not work when the parent is
nested, so fix the sibling check and add a test to check this case.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Fixes compilation error introduced by 43cea54c:
libweston/gl-renderer.c:2862:2: error: ‘for’ loop initial declarations
are only allowed in C99 mode
for (unsigned i = 0; i < ARRAY_LENGTH(swap_damage_ext_to_entrypoint);
i++) {
^
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
v2:
- Keep wl_shell code around until xdg_shell is declared stable.
Signed-off-by: Armin Krezović <krezovic.armin@gmail.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
This patch allow gl-renderer to accept WL_SHM_FORMAT_YUYV buffers.
This is the pixel format supported by most of the USB webcams.
v2:
- fix hsub Vs vsub inversion
Signed-off-by: Vincent Abriou <vincent.abriou@st.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
