Commit Graph

30 Commits

Author SHA1 Message Date
Ray Smith 875d4b1626 remoting: Handle non-fatal errors in gst_parse_launch
gst_parse_launch can return non-NULL even though an error is set. This
indicates "a recoverable parsing error and you can try to play the
pipeline", however given that we don't (and likely can't) make any
attempt to correct the situation, we should treat this as fatal and not
try to carry on.

Signed-off-by: Ray Smith <rsmith@brightsign.biz>
2024-04-15 15:24:23 +00:00
Pekka Paalanen 3728d7e99b backend-drm,pipewire,remoting: do not set monitor serial to "unknown"
If serial is unknown, it's best to leave it as NULL. All usage sites
already deal with it possibly being NULL.

This makes DRM-backend consistent with all other backend that leave
serial as NULL, allowing to move the initialization of these fields into
core.

Pipewire and remoting plugins are modified just for consistency.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2023-09-15 06:56:59 +00:00
Marius Vlad ca52c79c51 remoting-plugin: Check virtual outputs/remoting instance
With commit aab722bb, "backend-drm: prepare virtual output API for
heterogeneous outputs", we now call the virtual destroy function,
but when shutting the compositor we no longer have a remoting instance
available.

When searching out for a remoting output verify if the remoting instance is
still available before attempting to search for a remoting output.

Addresses the following crash at shutdown:

0x00007fd430a1d347 in lookup_remoted_output (output=0x557163d5dad0) at ../remoting/remoting-plugin.c:515
0x00007fd430a1d746 in remoting_output_destroy (output=0x557163d5dad0) at ../remoting/remoting-plugin.c:635
0x00007fd439e11ab9 in drm_virtual_output_destroy (base=0x557163d5dad0) at ../libweston/backend-drm/drm-virtual.c:265
0x00007fd43a8635d0 in weston_compositor_shutdown (ec=0x557163239530) at ../libweston/compositor.c:8271
0x00007fd439e029d4 in drm_destroy (backend=0x557163240ae0) at ../libweston/backend-drm/drm.c:2713
0x00007fd43a863e07 in weston_compositor_destroy (compositor=0x557163239530) at ../libweston/compositor.c:8626

Includes a note to point up what should be done about by
checking out https://gitlab.freedesktop.org/wayland/weston/-/issues/591.

Fixes aab722bb "backend-drm: prepare virtual output API for
heterogeneous outputs"

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2023-02-20 12:41:03 +02:00
Marius Vlad c3270e887b remoting-plugin: Release and detach the head
This re-orders the disable/destroy shutdown sequence such that
lookup_remoted_output(), in remoting_output_disable(), would find a
remoting output.

Otherwise, without this, lookup_remoted_output() wouldn't find a
remoting output available when shutting down the compositor, ultimately
leading to a crash.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2023-02-20 12:41:03 +02:00
Philipp Zabel aab722bb17 backend-drm: prepare virtual output API for heterogeneous outputs
Stop plugins from overwriting the struct weston_output::destroy vfunc,
as that will be used by backends to recognize their outputs.
Instead, pass a plugin-specific destroy callback when creating the
virtual output.

See: https://gitlab.freedesktop.org/wayland/weston/-/issues/268

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2022-06-10 09:27:43 +00:00
Marius Vlad d284ab0322 pipewire,remoting,tests: Replace asprintf w/ str_printf
We have a string helper which wraps asprintf(). Uses that one because it
clears out the destination string, but also it won't return the number
of bytes unlinke asprintf().

Fixes warnings like:
warning: ignoring return value of ‘asprintf’ declared with attribute
‘warn_unused_result’.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2022-03-14 15:51:09 +02:00
Daniel Stone b25f8aebf5 remoting: Fix warnings for multi-planar interface
GStreamer can accept up to four planes for a buffer; gcc isn't _quite_
smart enough to figure out that only the first plane of offset/stride
will be accessed and so throws a warning that the params are too small.
Fix that by making them arrays.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2021-11-27 09:57:46 +00:00
Pekka Paalanen 4b301fe7f2 Add weston-drm-fourcc.h
This header is for sharing fallback definitions for drm_fourcc.h. A new
test in tests/yuv-buffer-test.c is going to be needing XYUV8888 format,
and more new formats will be expected with HDR supports.

Share these fallback definitions in one place instead of copying them
all over.

All users of drm_fourcc.h are converted to include weston-drm-fourcc.h
instead for consistency: have the same definitions available everywhere.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2021-02-25 14:35:03 +02:00
Marius Vlad bb7ed37a89 remoting,pipewire: Use the connector and the output name for the head name
Makes the client's life much easier to identify between multiple remote
outputs. xdg_output is advertising (in later versions) the head name,
but in case we have different plug-ins or multiple remote
outputs created, it would only repeat/advertise the same name
for all (remoting) outputs.

This instead uses a string that uses both the connector and name to
derive a more easier identifier a client can choose from.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-11-09 11:36:12 +02:00
Marius Vlad c4076ef88a plug-ins: Migrate pipewire and remoting plug-ins headers to public header
directory

Weston is also a user of the plug-ins, so make use of it. With this
change we unconditionally install the plug-in headers even though
libweston might not be built with support for them.

Suggested-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-09-04 10:36:48 +00:00
Marius Vlad 380ceee6a1 remoting, pipewire: Install pipewire and remoting plug-ins headers
Required for other users of libweston.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-08-27 14:32:26 +03:00
Marius Vlad e0b937af28 remoting: Add DPMS support in remoting pluging
Just like pipewire, add DPMS support in remoting plug-in. Mechanical
change mimicking a24a326bb1.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2020-08-27 14:14:27 +03:00
Pekka Paalanen 6ffbba3ac1 Use weston_compositor_add_destroy_listener_once() in plugins
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>
2019-11-21 16:32:55 +00:00
Daniel Stone 4b8b60ebfd remoting: Use DRM FourCC formats instead of GBM formats
The remoting plugin currently has a set_gbm_format() hook, which accepts
GBM_FORMAT_* tokens from the host to set as a supported format.
GBM_FORMAT_* values are strictly aliased with DRM_FORMAT_*.

In order to avoid an extra unnecessary dependency from the remoting
plugin on GBM, switch to using the formats from libdrm instead.

This fixes a compile error seen when the remoting plugin is enabled:

    ../remoting/remoting-plugin.c:39:10: fatal error: gbm.h: No such file or directory
       39 | #include <gbm.h>
          |          ^~~~~~~
    compilation terminated.

The error was caused by not having any dependency at all on GBM from
the remoting backend, which is fixed here by adding a new dependency on
the libdrm headers for drm_fourcc.h.

Signed-off-by: Daniel Stone <daniels@collabora.com>
2019-11-11 10:54:17 +00:00
Stefan Agner 8d63e25963 remoting: make sure GL renderer is enabled
The remoting plug-in requires DRM virtual support which depends on
the GL renderer. Make sure the option is enabled.

Signed-off-by: Stefan Agner <stefan@agner.ch>
2019-10-25 14:30:40 +02:00
Pekka Paalanen 71ff95a544 build: separate deps for int and ext libweston users
We have two kinds of libweston users: internal and external. Weston, the
frontend, counts as an external user, and should not have access to libweston
private headers. The shell plugins are external users as well, because we
intend people to be able to write them. Renderers, backends, and some plugins
are internal users who will need access to private headers.

Create two different Meson dependency objects, one for each kind.

This makes it less likely to accidentally use a private header.

Screen-share is a Weston plugin and therefore counts as an external user, but
it needs the backend API to deliver input. Until we are comfortable exposing
public API for that purpose, let it use internal headers.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-10-24 13:29:33 +03:00
Pekka Paalanen 4f5e360180 build: simplify include_directories
Define common_inc which includes both public_inc and the project root directory.
The project root directory will allow access to config.h and all the shared/
headers.

Replacing all custom '.', '..', '../..', '../shared' etc. include paths with
common_inc reduces clutter in the target definitions and enforces the common
 #include directive style, as e.g. including shared/ headers without the
subdirectory name no longer works.

Unfortunately this does not prevent one from using private libweston headers
with the usual include pattern for public headers.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-10-04 17:14:22 +03:00
Marius Vlad e41c1bff11 libweston: Introduce backend.h
Introduce a new private header file that only internal backends are
allowed to use. Starts by migrating functions that operate on the
'struct weston_head'.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-07-18 06:43:38 +00:00
Marius Vlad 56f3a68a01 libweston: Migrate functions that operate on 'weston_compositor'
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-07-18 06:43:38 +00:00
Antonio Borneo c90fccc256 backend-drm: fix race during system suspend
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
2019-07-12 17:16:52 +00:00
Tomohito Esaki 3ea03bb85e remoting: make a gstreamer pipeline configurable
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.
2019-07-09 14:22:25 +00:00
Marius Vlad 71309894f3 doc: Move helper scripts to doc/scripts
No functional change, just re-arrange bits in doc/.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
2019-06-25 14:05:54 +00:00
Silva Alejandro Ismael 9eb974aaaf build: Fix hint to disable remoting
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>
2019-06-17 11:35:54 -03:00
Pekka Paalanen 27b377f51f Rename plugin-registry.h to libweston/plugin-registry.h
See "Rename compositor.h to libweston/libweston.h" for rationale.

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
2019-04-18 12:31:46 +03:00
Pekka Paalanen 7571027f17 Rename public backend headers
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>
2019-04-18 12:31:46 +03:00
Pekka Paalanen 3d5d9476e3 Rename compositor.h to libweston/libweston.h
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>
2019-04-18 12:31:46 +03:00
Pekka Paalanen 292aaf9308 meson: link remoting with glib and gobject
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>
2019-03-28 09:43:23 +00:00
Emmanuel Gil Peyrot 426c24673f Fix typos all around (thanks codespell!) 2019-02-20 16:47:35 +01:00
Daniel Stone 8011b0fa03 Add Meson build system
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>
2018-12-09 14:50:54 +02:00
Tomohito Esaki f709d22038 Add remoting plugin for output streaming
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>
2018-10-30 17:09:01 +09:00