- May 07, 2020
-
-
George Kiagiadakis authored
Useful to destroy links and endpoint-links
-
- Apr 21, 2020
-
-
Julian Bouzas authored
-
Julian Bouzas authored
-
- Mar 31, 2020
-
-
George Kiagiadakis authored
-
- Feb 19, 2020
-
-
George Kiagiadakis authored
-
- Feb 11, 2020
-
-
George Kiagiadakis authored
* core no longer exposes create_remote/local_object * node, device & link have constructor methods to enable the create_remote_object functionality * added WpImplNode to wrap pw_impl_node and allow creating "local" node instances * added WpSpaDevice to wrap spa_device and allow creating "local" device instances * exporting objects in all cases now happens by requesting FEATURE_BOUND from the proxy, eliminating the need for WpExported * replaced WpMonitor by new, simpler code directly in module-monitor * the proxy type lookup table in WpProxy is gone, we now use a field on the class structure of every WpProxy subclass and iterate through all the class structures instead; this is more flexible and extensible
-
- Feb 10, 2020
-
-
George Kiagiadakis authored
+ use the pw_proxy API to find the bound id instead of relying on WpGlobal This has the advantage that it works also for exported objects and for objects that have been created by calling into a remote factory (such as the link-factory), so we can now know the global id of all proxies, not only the ones that have been created by the registry.
-
- Jan 22, 2020
-
-
George Kiagiadakis authored
-
George Kiagiadakis authored
This is not used anymore. It was useful when we were using it as a detail in the global-added signal, but that is gone now.
-
George Kiagiadakis authored
They are equivalent, there is no real benefit in having both
-
- Jan 16, 2020
-
-
George Kiagiadakis authored
-
- Jan 13, 2020
-
-
Julian Bouzas authored
-
- Jan 10, 2020
-
-
Julian Bouzas authored
-
- Nov 13, 2019
-
-
George Kiagiadakis authored
* rework how global objects are stored in the core * rework how users get notified about global objects and proxies of remote global objects The purpose of this change is to have a class that can manage objects that are registered in the core or signalled through the registry. This object can declare interest on certain types of global objects and only keep & signal those objects that it is interested in. Additionally, it can prepare proxy features and asynchronously deliver an 'objects-changed' signal, which is basically telling us that the list of objects has changed. This is useful to simplify port proxies management in WpAudioStream. Now the stream object can declare that it is interested in ports that have "node.id" == X and the object manager will only maintain a list of those. Additionally, it will emit the 'objects-changed' signal when the list of ports is complete, so there is no reason to do complex operations and core syncs in the WpAudioStream class in order to figure out when the list of ports is ready. As a side effect, this also reduces resource management. Now we don't construct a WpProxy for every global that pipewire reports; we only construct proxies when there is interest in them! Another interesting side effect is that we can now register an object manager at any point in time and get immediately notified about remote globals that already exist. i.e. when you register an object manager that is interested in nodes, it will be immediately notified about all the existing nodes in the graph. This is useful to avoid race conditions between connecting the signal and objects beting created in pipewire
-
- Nov 07, 2019
-
-
George Kiagiadakis authored
-
- Sep 07, 2019
-
-
George Kiagiadakis authored
In practice we always create a remote and connect to pipewire. Any other scenario is invalid, therefore, it is not justified to be confused with so many classes for such small functionality. This simplifies a lot the modules code. Also, this commit exposes the pw_core and pw_remote objects out of WpCore. This is in practice useful when dealing with low-level pw and spa factories, which are used in the monitors. Let's not add API wrappers for everything... Bindings will never use this functionality anyway, since it depends on low level pipewire C API.
-
- Aug 29, 2019
-
-
George Kiagiadakis authored
In case the proxy was created with wp_proxy_new_wrap(), the event listener was not attached on the pw_proxy
-
- Aug 27, 2019
-
-
George Kiagiadakis authored
* add proxy sync method * add wrapers for enum/set/subscribe_params * move the info structure handling to the subclasses * expose info->props as WpProperties
-
- Aug 25, 2019
-
-
George Kiagiadakis authored
-
- Jul 25, 2019
-
-
Julian Bouzas authored
-
- Jun 27, 2019
-
-
Julian Bouzas authored
-
- Jun 20, 2019
-
-
Julian Bouzas authored
-
- Jun 19, 2019
-
-
Julian Bouzas authored
-
- Jun 18, 2019
-
-
Julian Bouzas authored
-
Julian Bouzas authored
-
- Jun 17, 2019
-
-
Julian Bouzas authored
-
- May 17, 2019
-
-
George Kiagiadakis authored
After discussing things at the AGL May 2019 F2F meeting and reflecting on the initial design of WirePlumber, it became clear that it needed a fresh start.
-
- Apr 26, 2019
-
-
George Kiagiadakis authored
-
- Apr 22, 2019
-
-
George Kiagiadakis authored
This makes it more intuitive to get other attached interfaces from the core
-
George Kiagiadakis authored
We are going to use this in other object types as well
-
- Apr 17, 2019
-
-
George Kiagiadakis authored
* make the registries available as dynamic interfaces of the core * improve a bit the C API of WpObject & WpInterfaceImpl
-
George Kiagiadakis authored
-
- Apr 15, 2019
-
-
George Kiagiadakis authored
-
- Apr 12, 2019
-
-
George Kiagiadakis authored
-