summaryrefslogtreecommitdiff
path: root/pipewire
Commit message (Collapse)AuthorAgeFilesLines
* pipewire-[backend|plugin]: Add timestamps to buffersRobert Mader2023-04-201-1/+4
| | | | | | | | | | | | | In Pipewire and Gstreamer terminology Weston is a "live" source (as we do not explicitly set PW_KEY_STREAM_IS_LIVE to false). Such sources, be it compositors, cameras or microphones, usually set the current system time as timestamps on buffers in order to make life easier for consumers. Thus let's do so as well. This notably helps when recording using `gstpipewiresrc` with the `keepalive-time` property set. Signed-off-by: Robert Mader <robert.mader@collabora.com>
* pipewire-plugin: Check virtual outputs/remoting instanceMarius Vlad2023-02-201-0/+13
| | | | | | | | | | | Similarly to remoting plug-in in commit "Check virtual outputs/remoting instance" this avoids touching the pipewire instance, and with it, the pipewire output. Includes a note to point up what should be done about by checking out https://gitlab.freedesktop.org/wayland/weston/-/issues/591. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* pipewire: Destroy the pipewire outputs at shutdownMarius Vlad2023-02-201-0/+4
| | | | | | | Seems like we are missing destroying the pipewire outputs on the shutdown path; this follow-ups with remoting plug-in as well. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* pipewire: Fix memleak upon compositor shutdownMarius Vlad2023-02-201-0/+2
| | | | | | | This happens when shutting the compositor, and follows-up with the remoting plug-in. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* pipewire: Follow-up with remoting pluging when releasing the headMarius Vlad2023-02-201-1/+2
| | | | | | | | | | Similarily to what the remoting plug-in does, explicitly call weston_release_head() before removing the output list entry. We do that to avoid lookup_pipewire_output() returning NULL and still find out the pipewire_output. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* backend-drm: prepare virtual output API for heterogeneous outputsPhilipp Zabel2022-06-101-6/+1
| | | | | | | | | | | 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>
* pipewire,remoting,tests: Replace asprintf w/ str_printfMarius Vlad2022-03-141-1/+2
| | | | | | | | | | | | 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>
* pipewire: Drop support for 0.2 APIEmmanuel Gil Peyrot2021-10-272-208/+0
| | | | | | | | According to repology.org, all relevant distributions now ship pipewire 0.3, so we can drop the pretty ugly #if/#else code that was added to support both at compile-time. Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
* pipewire: fix null deref in 0.3 APIAmbareesh Balaji2021-01-121-0/+1
| | | | Signed-off-by: Ambareesh Balaji <ambareeshbalaji@gmail.com>
* pipewire/meson: fix option in user_hintVeeresh Kadasani2020-11-171-1/+1
| | | | Signed-off-by: Veeresh Kadasani <veereshkadasani88@gmail.com>
* remoting,pipewire: Use the connector and the output name for the head nameMarius Vlad2020-11-091-1/+6
| | | | | | | | | | | | | 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>
* pipewire: add support for 0.3 APIJames Hilliard2020-09-042-11/+135
| | | | | | Fixes: #369 Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
* plug-ins: Migrate pipewire and remoting plug-ins headers to public headerMarius Vlad2020-09-043-64/+1
| | | | | | | | | | | 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>
* remoting, pipewire: Install pipewire and remoting plug-ins headersMarius Vlad2020-08-271-0/+1
| | | | | | Required for other users of libweston. Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
* pipewire: implement DPMSMichael Olbrich2020-08-191-1/+20
| | | | | | | | | | Pipewire doesn't need to wait for any hardware. The finish_frame() callback is just artifically delayed to generate the desired framerate. So when the DPMS level changes, we can just call finish_frame() immediately if necessary and cancel the timer. Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>
* pipewire: stop direct accessing core struct memberLeandro Ribeiro2020-01-291-4/+3
| | | | | | | | | | | | | Commit "weston-log: add function to avoid direct access to compositor members in non-core code" added the function weston_compositor_add_log_scope mainly to allow libweston users to avoid direct accessing core structs, as weston_compositor. Replace weston_log_context_add_log_scope usage by weston_compositor_add_log_scope. Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
* weston-log: rename the confusing function name ↵Leandro Ribeiro2020-01-271-1/+1
| | | | | | | | | | | | weston_compositor_log_scope_destroy() There's a function named weston_compositor_log_scope_destroy() but it doesn't take a struct weston_compositor argument. Rename it to weston_log_scope_destroy(), as the argument is a struct weston_log_scope. Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
* weston-log: rename the confusing function name weston_compositor_add_log_scope()Leandro Ribeiro2020-01-271-5/+5
| | | | | | | | | | | | There's a function named weston_compositor_add_log_scope() but it doesn't take a struct weston_compositor argument. Rename it to weston_log_ctx_add_log_scope(), as the log_scope is being added to a log_context. Also, bump libweston_major to 9. Signed-off-by: Leandro Ribeiro <leandrohr@riseup.net>
* Use weston_compositor_add_destroy_listener_once() in pluginsPekka Paalanen2019-11-211-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* build: separate deps for int and ext libweston usersPekka Paalanen2019-10-241-1/+1
| | | | | | | | | | | | | | | | | | 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>
* weston-log: Add 'destroy_subscription' callback for the subscriptionMarius Vlad2019-10-171-1/+1
| | | | | | | | | | | As 'new_subscription' can create additional objects, 'destroy_subscription' will be needed when cleaning up. As this requires a libweston_major bump (noticed by @pq), bump it up to 8. Signed-off-by: Marius Vlad <marius.vlad@collabora.com> Suggested-by: Daniel Stone <daniel.stone@collabora.com>
* build: simplify include_directoriesPekka Paalanen2019-10-041-1/+1
| | | | | | | | | | | | | | | | 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>
* Add pipewire pluginMichael Olbrich2019-07-193-0/+923
It is quite similar to the remoting plugin. It just exports the frames via pipewire instead of the builtin GStreamer pipeline. It implements the same virtual output API. Virtual outputs can be created by adding 'pipewire-output' sections to weston.ini. The generated frames can be accessed with any pipewire client. e.g. with GStreamer: gst-launch-1.0 pipewiresrc ! video/x-raw,format=BGRx ! ... Signed-off-by: Michael Olbrich <m.olbrich@pengutronix.de>