Depending on system loading, weston-launcher could drop the drm
master access before the compositor and all the clients receive
the notification. In this case, some commit could be sent to the
drm driver too late and get refused with error EACCES.
This error condition is not properly managed and causes weston to
hang.
Change the return type of start_repaint_loop() and repaint_flush()
from void to int, and return 0 on success or -1 if the repaint has
to be cancelled.
In the callers of start_repaint_loop() and repaint_flush() handle
the return value and cancel the repaint when needed.
In backend-drm detect the error EACCES and return -1.
Note: to keep the code cleaner, this change inverts the execution
order between weston_output_schedule_repaint_reset() and
repaint_cancel().
No need to wait for suspend or for any notification; in case the
weston reschedules a repaint, it will get EACCES again.
At resume, damage-all guarantees a complete repaint.
This fix is for atomic modeset only.
Legacy modeset suffers from similar problems, but it is not fixed
by this change. Since drm_pending_state_apply() never returns
error for legacy modeset, this change has no impact on legacy
modeset.
Signed-off-by: Antonio Borneo <antonio.borneo@st.com>
Fixes: https://gitlab.freedesktop.org/wayland/weston/issues/117
Allow a gstreamer pipeline to be configurable via an weston.ini. It is
necessary that source is appsrc, its name is "src", and sink name is
"sink" in pipeline. Also, remoting plugin ignore port and host
configuration if the gst-pipeline is specified.
If a dependency is missing, the error message should tell the build option to disable it.
Show the correct build option in the error message of the remoting plugin.
Signed-off-by: Silva Alejandro Ismael <silva.alejandro.ismael@gmail.com>
The backend headers are renamed from compositor-foo.h to backend-foo.h to
better describe their purpose. These headers are public libweston API for each
specific backend.
The headers will also be used like
#include <libweston/backend-drm.h>
instead of
#include <compositor-drm.h>
to give them a more explicit namespace.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The main idea is to make libweston users use the form
#include <libweston/libweston.h>
instead of the plain
#include <compositor.h>
which is prone to name conflicts. This is reflected both in the installed
files, and the internal header search paths so that Weston would use the exact
same form as an external project using libweston would.
The public headers are moved under a new top-level directory include/ to make
them clearly stand out as special (public API).
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
remoting-plugin.c calls things like g_error_free() and g_object_set(), so it
needs to link glib-2.0 and gobject-2.0 explicitly, instead of relying on
GStreamer pkg-config bringing them in.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Meson is a build system, currently implemented in Python, with multiple
output backends, including Ninja and Make. The build file syntax is
clean and easy to read unlike autotools. In practise, configuring and
building with Meson and Ninja has been observed to be much faster than
with autotools. Also cross-building support is excellent.
More information at http://mesonbuild.com
Since moving to Meson requires some changes from users in any case, we
took this opportunity to revamp build options. Most of the build options
still exist, some have changed names or more, and a few have been
dropped. The option to choose the Cairo flavour is not implemented since
for the longest time the Cairo image backend has been the only
recommended one.
This Meson build should be fully functional and it installs everything
an all-enabled autotools build does. Installed pkg-config files have
some minor differences that should be insignificant. Building of some
developer documentation that was never installed with autotools is
missing.
It is expected that the autotools build system will be removed soon
after the next Weston release.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Co-authored-by: Pekka Paalanen <pq@iki.fi>
Signed-off-by: Pekka Paalanen <pq@iki.fi>
Remoting plugin support streaming image of virtual output on drm-backend
to remote output. By appending remote-output section in weston.ini,
weston loads remoting plugin module and creates virtual outputs via
remoting plugin. The mode, host, and port properties are configurable in
remote-output section.
This plugin send motion jpeg images to client via RTP using gstreamer.
Client can receive by using following pipeline of gst-launch.
gst-launch-1.0 rtpbin name=rtpbin \
udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,
encoding-name=JPEG,payload=26" port=[PORTNUMBER] !
rtpbin.recv_rtp_sink_0 \
rtpbin. ! rtpjpegdepay ! jpegdec ! autovideosink \
udpsrc port=[PORTNUMBER+1] ! rtpbin.recv_rtcp_sink_0 \
rtpbin.send_rtcp_src_0 !
udpsink port=[PORTNUMBER+2] sync=false async=false
where, PORTNUMBER is specified in weston.ini.
Signed-off-by: Tomohito Esaki <etom@igel.co.jp>
Antonio Borneo
Tomohito Esaki
Marius Vlad
Silva Alejandro Ismael
Pekka Paalanen
Emmanuel Gil Peyrot
Daniel Stone