This client contains driver-specific code to allocate buffers. However clients
shouldn't contain driver-specific code and should rely on e.g. mesa to allocate
buffers via standard interfaces.
Additionally, because the build system always tries to enable all features, some
experimental drivers and drivers that aren't included in amd64 distribution
packages were required. Users would need to manually disable some drivers.
Releasers would need to install libdrm from source (because the release process
forbids adding custom build flags). Dropping simple-dmabuf-drm simplifies both
building and releasing.
The functionality previously tested via simple-dmabuf-drm can now be tested with
simple-dmabuf-egl.
Signed-off-by: Simon Ser <contact@emersion.fr>
When the aspect-ratio-aware mode support was added to Weston, it was
done before the libdrm support was finalised and merged. Between it
being added to Weston and being merged, it changed to no longer provide
the offset for the bitmask.
Instead of using the mask and a compatible enum, if we update our
libdrm dependency, we can use the flag definitions directly from libdrm.
In 94e4068ba1, the libdrm dependency was bumped to 2.4.83, which
enabled us to remove a bunch of error-prone ifdefs by making atomic and
modifier support mandatory.
We determined in the discussion of !311 that it was safe to push the
dependency as high as 2.4.91, as that was what was available in major
distributions.
Bumping to 2.4.86 allows us to safely remove the ifdef and go with
upstream flags, as that was added in mesa/drm@0d889201d106.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Instead of getting previous_damage from the weston_output struct, get it from
the frame_signal data argument. This will make possible to remove
previous_damage from weston_output after we decide what to do with
output->previous_damage usage in DRM backend.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Instead of getting previous_damage from the weston_output struct, get it from
the frame_signal data argument. This will make possible to remove
previous_damage from weston_output after we decide what to do with
output->previous_damage usage in DRM backend.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
This will make possible to users that are listening to frame_signal to get
previous_damage from the data parameter instead of using
output->previous_damage.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Instead of getting weston_output from the frame_signal argument 'void *data',
add weston_output in the private data struct of the users that are listening
to frame_signal. With this change we are able to pass previous_damage as the
data argument.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Instead of getting weston_output from the frame_signal argument 'void *data',
add weston_output in the private data struct of the users that are listening
to frame_signal. With this change we are able to pass previous_damage as the
data argument.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
In order to remove duplication and make the code easier to follow, move
frame_signal emission from renderers to weston_output_repaint(). This should
have no observable effect.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Accept XYUV dmabuf buffers that a client application such as
weston-simple-dmabuf-v4l might submit.
v2 (Daniel):
Add XYUV to yuv_formats array to have the compositor color convert
with a shader if GL_TEXTURE_EXTERNAL_OES does not work.
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
Instead of using the EGL_*_WL macros imported from EGL headers,
start using enums that would be defined locally. This is needed as
there are limited number of macros defined in EGL headers and
adding new ones is not practically feasible when adding a new
texture type. (suggested by Daniel Stone)
Signed-off-by: Vivek Kasireddy <vivek.kasireddy@intel.com>
When we are going to set a solid color for the background, use
a 1x1 buffer and set the viewport to the full size. This avoids
un-necessary allocation of buffer memory.
Signed-off-by: Harish Krupo <harish.krupo.kps@intel.com>
Add support for setting the widget's destination wp viewport.
Setting it in the widget instead of being set directly by the client
ensure that the widget can be identified in widget_find_widget.
v2: Return -1 on error (Pekka)
Scale allocated x and y when viewport is set (Pekka)
Allow user to set -1 for viewport width and height (Pekka)
v3: Use NULL instead of 0 (Daniel)
return 0 if width and height are -1 (Daniel)
Signed-off-by: Harish Krupo <harish.krupo.kps@intel.com>
This would be causing a protocol error in which the buffer size needs to
match the one provided in the configure event.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Mimics the C version that displays the contents of the flight recorder.
With a core-dump in place source the python file then call
'display_flight_rec' to dump the data.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
contents of the flight recorder
The overlap variable is sufficient to determine from where to start
displaying the contents of the ring buffer. Also redundant to verify
if the position in the buffer went over the maximum size.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
created
Having a (single) global variable which others depend on it implies
having a single flight recorder present. Until we have a reason to
support multiple flight recorders limit the amount to a maximum of one.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com>
With it add also a function which can be used in an assert()-like
situation to display the contents of the ring buffer. Within gdb
this call also be called if the program is loaded/still loaded into
memory.
The global variable will be used in a later patch to be accessed from a
python gdb script.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Make sure we export the get_full_path() accessor (declared in the
header, used by Weston itself) and the parser's destroy function.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Libweston is not allowed to depend on Weston. Fortunately this include is
unnecessary and can be simply removed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Remove unnecessary ifdefs for DRM_MODE_CONNECTOR_DSI, DRM_MODE_CONNECTOR_DPI.
They are both provided by libdrm and were introduced long before 2.4.83 (the
lowest version we currently support).
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Since commit 28d26483 ("build: bump libdrm requirement to newer version
(2.4.83)"), all supported libdrm versions provide modifier formats,
atomic API and blob formats. Remove ifdef checks (HAVE_DRM_ADDFB2_MODIFIERS,
HAVE_DRM_ATOMIC, HAVE_DRM_FORMATS_BLOB) to improve the code and make it
simpler.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
There are some features that are available only if the user's libdrm version is
not too old: format modifiers require at least libdrm 2.4.71, atomic API at
least 2.4.78 and blob formats at least 2.4.83.
Bump libdrm to 2.4.83 (the oldest version that support these features) in order
to be able to remove ifdef checks and simplify the code. Major distributions
already support libdrm 2.4.91, so it's safe to apply this commit.
Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
Mode change from mixed-mode to renderer-only means we should no longer
try to place views in HW planes (as we composite everything into the
primary plane) thus we should avoid that whenever that happens.
In the same time we need to be able to place in mixed-mode/renderer-only
mode the cursor view into the cursor plane (if one is available).
This patch adds a further check to skip plane assignment when disabling
overlay support (when we switch to renderer-only mode), when drivers do
not have atomic-modeset or it has been disabled intentionally.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Adds a further assert() to make sure we're not checking against invalid
values. This was seen in the wild when the kernel rejects the commit for
overlay resulting in a check for invalid zpos values.
Fixes: #304
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
when switching to mixed-mode of compositing
This way we avoid an (incorrect) duplicate check of zpos values. Also,
this would be needed because the renderer needs have the lowest zpos value
available as we don't (yet) properly support underlays, the primary
plane serves as our renderer.
Adds also a check to see if we try to assign a view to a plane with
a lower zpos value than the one assigned to the primary when switching
to mixed-mode of compositing.
Fixes: #304
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Nothing is using FAIL_TEST or FAIL_TEST_P and that is good. Remove them to not
encourage using them.
If we need a test that should fail, it always needs to fail in a very specific
way which needs to be checked. For this we have e.g. expect_protocol_error().
We never want a fail-test to pass because it failed in a way we did not expect.
Therefore these macros are useless.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Use a different section name to make sure that if this plugin is loaded into
the same process as where weston-test-runner.h is used, the two different
sections cannot get mixed up. This is just a precaution, but it removes a bit
of reader confusion as well.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This avoids confusing it with the opaque struct weston_test from
protocol/weston-test.xml.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Successful tests should just return, not call exit() which breaks the new test
harness when it uses TAP.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
When we move on to TAP, stdout will be reserved for TAP and stderr is for free
chatter. Set up an example that tests should use testlog() instead of fprintf
or printf to chat in the right place.
Most statements were already printing to stderr, so this just makes then a
little shorter. There are also some statements that printed to stdout and are
now corrected.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using the test name for the reference images will stop working when the new
test harness starts using fixtures. Fixtures allow running the same tests in
varying environments, so the test results file names will include fixture
index. However the reference images will remain the same for all fixtures.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This reverts 50b7b70835.
We didn't make Meson create a logs directory, so writing the images fails
because the directory does not exist. If you run a test without Meson, there is
even less expectation that it would write somewhere else than CWD by default.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Add a sanity check to touch_handle_down() and data_device_enter() as
what we did for pointer and keyboard.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Initially, `_XWAYLAND_ALLOW_COMMITS` was introduced in commit 7ace831ca
to avoid drawing the window content before it's ready to be shown.
But a repaint might also be triggered by the client damages before the
XWM has finished drawing its window decorations and drop shadows, which
previously was not too much of an issue since the XWM could still
finish updating the X11 window after the buffer was submitted.
However, with the addition of multiple window buffers in Xwayland [1]
which are aimed at preventing the X11 clients from updating the buffer
after it's been committed, this is no longer possible.
As a result, the use of multiple window buffers in Xwayland can cause
ugly repainting effects of the decorations if the buffer is submitted
before the XWM has finished painting its decorations.
Use the X11 property `_XWAYLAND_ALLOW_COMMITS` can be used to avoid
this, by controlling when Xwayland should commit changes to the Wayland
surface.
[1] https://gitlab.freedesktop.org/xorg/xserver/merge_requests/316
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
This is necessary for the test harness to be able to execute the compositor
multiple times in the same process. As we never unload opened modules, the
first compositor iteration will leave them all loaded and following compositor
iterations will then have them already loaded.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is necessary for the test harness to be able to execute the compositor
multiple times in the same process. As we never unload opened modules, the
first compositor iteration will leave them all loaded and following compositor
iterations will then have them already loaded.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This introduces a new convention of checking through the compositor destroy
listener if the plugin is already initialized. If the plugin is already
initialized, then the plugin entry function succeeds as a no-op. This makes it
safe to load the same plugin multiple times in a running compositor.
Currently module loading functions return failure if a plugin is already
loaded, but that will change in the future. Therefore we need this other method
of ensuring we do not double-initialize a plugin which would lead to list
corruptions the very least.
All plugins are converted to use the new helper, except:
- those that do not have a destroy listener already, and
- hmi-controller which does the same open-coded as the common code pattern
did not fit there.
Plugins should always have a compositor destroy listener registered since they
very least allocate a struct to hold their data. Hence omissions are
highlighted in code.
Backends do not need this because weston_compositor_load_backend() already
protects against double-init. GL-renderer does not export a standard module
init function so cannot be initialized the usual way and therefore is not
vulnerable to double-init.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener, which would lead
to use-after-free on compositor tear-down especially on cms-colord init failure
paths. Found by inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener if init failed,
which would lead to use-after-free on compositor tear-down. Found by
inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This was forgetting to remove the compositor destroy listener if init failed,
which would lead to use-after-free on compositor tear-down. Found by
inspection.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
While get_presentation() will only ever be called once (making the caching of
the return value moot), it is good to stop using the static variable as it
would cause surprising problems if anyone adds more tests here and runs it
under the new test harness.
It was leaked before and continues to be so.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Using static data will mess things up when the test harness no longer fork()'s
each sub-test. Hence it needs to be converted to "normal" data.
Unfortunately here the cached value was actually used, so keeping that
behaviour is a handful. Yes, it was all leaked also before.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Just one test call this only once, so the cached value will never be useful.
Stop using static data, it sets a bad example. If more tests were added, things
would start failing when forking is removed from the test harness.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I cannot see any reason why this should be static data. But if it is static
data, it will prevent re-entering wet_main() to run tests with this plugin, so
replace it with "normal" data.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This caching is actually never hit. I tested by making the early return abort()
instead and all works just fine.
Remove the caching. The static variable will cause problems when we stop
fork()'ing for each test case.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>