pipewire/src/modules/module-protocol-native/connection.c

599 lines
14 KiB
C
Raw Normal View History

2017-05-23 19:15:33 +02:00
/* PipeWire
*
* Copyright © 2018 Wim Taymans
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*/
#include <stdint.h>
#include <stddef.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <unistd.h>
#include <sys/socket.h>
2018-08-14 12:33:53 +02:00
#include <spa/debug/pod.h>
2017-07-11 15:57:20 +02:00
#include <pipewire/pipewire.h>
#include "pipewire/private.h"
2017-07-11 15:57:20 +02:00
#include "connection.h"
2017-07-04 11:08:40 +02:00
#define MAX_BUFFER_SIZE (1024 * 32)
#define MAX_FDS 1024
#define MAX_FDS_MSG 28
#define HDR_SIZE 16
static bool debug_messages = 0;
2017-05-23 19:15:33 +02:00
struct buffer {
2017-05-26 08:05:01 +02:00
uint8_t *buffer_data;
size_t buffer_size;
size_t buffer_maxsize;
int fds[MAX_FDS];
uint32_t n_fds;
uint32_t seq;
size_t offset;
size_t fds_offset;
struct pw_protocol_native_message msg;
2017-05-26 08:05:01 +02:00
bool update;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
bool first;
2017-05-23 19:15:33 +02:00
};
struct impl {
struct pw_protocol_native_connection this;
struct pw_core *core;
2017-05-26 08:05:01 +02:00
struct buffer in, out;
struct spa_pod_builder builder;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
uint32_t version;
size_t hdr_size;
2017-05-23 19:15:33 +02:00
};
2017-05-30 19:46:51 +02:00
/** \endcond */
/** Get an fd from a connection
*
* \param conn the connection
* \param index the index of the fd to get
* \return the fd at \a index or -ENOENT when no such fd exists
2017-05-30 19:46:51 +02:00
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
int pw_protocol_native_connection_get_fd(struct pw_protocol_native_connection *conn, uint32_t index)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
struct buffer *buf = &impl->in;
if (index == SPA_ID_INVALID)
return -1;
if (index >= buf->msg.n_fds)
return -ENOENT;
return buf->msg.fds[index];
}
2017-05-30 19:46:51 +02:00
/** Add an fd to a connection
*
* \param conn the connection
* \param fd the fd to add
* \return the index of the fd or SPA_IDX_INVALID when an error occured
2017-05-30 19:46:51 +02:00
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
uint32_t pw_protocol_native_connection_add_fd(struct pw_protocol_native_connection *conn, int fd)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
struct buffer *buf = &impl->out;
2017-05-26 08:05:01 +02:00
uint32_t index, i;
if (fd < 0)
return SPA_IDX_INVALID;
for (i = 0; i < buf->msg.n_fds; i++) {
if (buf->msg.fds[i] == fd)
2017-05-26 08:05:01 +02:00
return i;
}
index = buf->msg.n_fds;
if (index + buf->n_fds >= MAX_FDS) {
2017-05-26 08:05:01 +02:00
pw_log_error("connection %p: too many fds", conn);
return SPA_IDX_INVALID;
2017-05-26 08:05:01 +02:00
}
2017-03-09 19:42:35 +01:00
buf->msg.fds[index] = fd;
buf->msg.n_fds++;
pw_log_debug("connection %p: add fd %d at index %d", conn, fd, index);
2017-05-26 08:05:01 +02:00
return index;
}
static void *connection_ensure_size(struct pw_protocol_native_connection *conn, struct buffer *buf, size_t size)
{
2019-06-19 16:22:22 +02:00
int res;
2017-05-26 08:05:01 +02:00
if (buf->buffer_size + size > buf->buffer_maxsize) {
buf->buffer_maxsize = SPA_ROUND_UP_N(buf->buffer_size + size, MAX_BUFFER_SIZE);
buf->buffer_data = realloc(buf->buffer_data, buf->buffer_maxsize);
2017-11-13 11:32:06 +01:00
if (buf->buffer_data == NULL) {
2019-06-19 16:22:22 +02:00
res = -errno;
2017-11-13 11:32:06 +01:00
buf->buffer_maxsize = 0;
spa_hook_list_call(&conn->listener_list,
struct pw_protocol_native_connection_events,
2019-06-19 16:22:22 +02:00
error, 0, -res);
errno = -res;
2017-11-13 11:32:06 +01:00
return NULL;
}
2017-05-26 08:05:01 +02:00
pw_log_warn("connection %p: resize buffer to %zd %zd %zd",
conn, buf->buffer_size, size, buf->buffer_maxsize);
}
return (uint8_t *) buf->buffer_data + buf->buffer_size;
}
static int refill_buffer(struct pw_protocol_native_connection *conn, struct buffer *buf)
{
2017-05-26 08:05:01 +02:00
ssize_t len;
struct cmsghdr *cmsg;
struct msghdr msg = { 0 };
struct iovec iov[1];
char cmsgbuf[CMSG_SPACE(MAX_FDS_MSG * sizeof(int))];
int n_fds = 0;
size_t avail;
avail = buf->buffer_maxsize - buf->buffer_size;
2017-05-26 08:05:01 +02:00
iov[0].iov_base = buf->buffer_data + buf->buffer_size;
iov[0].iov_len = avail;
2017-05-26 08:05:01 +02:00
msg.msg_iov = iov;
msg.msg_iovlen = 1;
msg.msg_control = cmsgbuf;
msg.msg_controllen = sizeof(cmsgbuf);
2017-10-17 10:14:56 +02:00
msg.msg_flags = MSG_CMSG_CLOEXEC | MSG_DONTWAIT;
2017-05-26 08:05:01 +02:00
while (true) {
len = recvmsg(conn->fd, &msg, msg.msg_flags);
if (len == 0 && avail != 0)
return -EPIPE;
else if (len < 0) {
2017-05-26 08:05:01 +02:00
if (errno == EINTR)
continue;
if (errno != EAGAIN || errno != EWOULDBLOCK)
2017-05-26 08:05:01 +02:00
goto recv_error;
return -EAGAIN;
2017-05-26 08:05:01 +02:00
}
break;
}
buf->buffer_size += len;
/* handle control messages */
for (cmsg = CMSG_FIRSTHDR(&msg); cmsg != NULL; cmsg = CMSG_NXTHDR(&msg, cmsg)) {
if (cmsg->cmsg_level != SOL_SOCKET || cmsg->cmsg_type != SCM_RIGHTS)
continue;
n_fds =
2017-05-26 08:05:01 +02:00
(cmsg->cmsg_len - ((char *) CMSG_DATA(cmsg) - (char *) cmsg)) / sizeof(int);
memcpy(&buf->fds[buf->n_fds], CMSG_DATA(cmsg), n_fds * sizeof(int));
buf->n_fds += n_fds;
2017-05-26 08:05:01 +02:00
}
pw_log_trace("connection %p: %d read %zd bytes and %d fds", conn, conn->fd, len,
n_fds);
2017-05-26 08:05:01 +02:00
return 0;
2017-05-26 08:05:01 +02:00
/* ERRORS */
2019-06-20 11:04:34 +02:00
recv_error:
pw_log_error("could not recvmsg on fd:%d: %s", conn->fd, strerror(errno));
return -errno;
}
2017-05-26 08:05:01 +02:00
static void clear_buffer(struct buffer *buf)
2016-10-18 11:11:38 +02:00
{
2017-05-26 08:05:01 +02:00
buf->n_fds = 0;
buf->buffer_size = 0;
buf->offset = 0;
buf->fds_offset = 0;
2016-10-18 11:11:38 +02:00
}
2017-05-30 19:46:51 +02:00
/** Make a new connection object for the given socket
*
* \param fd the socket
* \returns a newly allocated connection object
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
2018-08-14 12:33:53 +02:00
struct pw_protocol_native_connection *pw_protocol_native_connection_new(struct pw_core *core, int fd)
{
struct impl *impl;
struct pw_protocol_native_connection *this;
impl = calloc(1, sizeof(struct impl));
2017-05-26 08:05:01 +02:00
if (impl == NULL)
return NULL;
debug_messages = pw_debug_is_category_enabled("connection");
impl->core = core;
2017-05-26 08:05:01 +02:00
this = &impl->this;
2017-05-26 08:05:01 +02:00
pw_log_debug("connection %p: new", this);
2017-05-26 08:05:01 +02:00
this->fd = fd;
spa_hook_list_init(&this->listener_list);
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
impl->hdr_size = HDR_SIZE;
impl->version = 3;
2019-03-13 16:02:50 +01:00
impl->out.buffer_data = calloc(1, MAX_BUFFER_SIZE);
2017-05-26 08:05:01 +02:00
impl->out.buffer_maxsize = MAX_BUFFER_SIZE;
2019-03-13 16:02:50 +01:00
impl->in.buffer_data = calloc(1, MAX_BUFFER_SIZE);
2017-05-26 08:05:01 +02:00
impl->in.buffer_maxsize = MAX_BUFFER_SIZE;
impl->in.update = true;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
impl->in.first = true;
2017-05-26 08:05:01 +02:00
if (impl->out.buffer_data == NULL || impl->in.buffer_data == NULL)
goto no_mem;
2017-05-26 08:05:01 +02:00
return this;
2019-06-20 11:04:34 +02:00
no_mem:
2017-05-26 08:05:01 +02:00
free(impl->out.buffer_data);
free(impl->in.buffer_data);
free(impl);
return NULL;
}
int pw_protocol_native_connection_set_fd(struct pw_protocol_native_connection *conn, int fd)
{
conn->fd = fd;
return 0;
}
2017-05-30 19:46:51 +02:00
/** Destroy a connection
*
* \param conn the connection to destroy
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
void pw_protocol_native_connection_destroy(struct pw_protocol_native_connection *conn)
2016-10-18 11:11:38 +02:00
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
2017-05-26 08:05:01 +02:00
pw_log_debug("connection %p: destroy", conn);
spa_hook_list_call(&conn->listener_list, struct pw_protocol_native_connection_events, destroy, 0);
2017-05-26 08:05:01 +02:00
free(impl->out.buffer_data);
free(impl->in.buffer_data);
free(impl);
2016-10-18 11:11:38 +02:00
}
static int prepare_packet(struct pw_protocol_native_connection *conn, struct buffer *buf)
{
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
uint8_t *data;
size_t size, len;
uint32_t *p;
data = buf->buffer_data + buf->offset;
size = buf->buffer_size - buf->offset;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if (size < impl->hdr_size)
return impl->hdr_size;
p = (uint32_t *) data;
buf->msg.id = p[0];
buf->msg.opcode = p[1] >> 24;
len = p[1] & 0xffffff;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if (buf->first) {
buf->first = false;
if (p[2] != 0) {
pw_log_warn("old version detected");
impl->version = 0;
impl->hdr_size = 8;
} else {
impl->version = 3;
impl->hdr_size = 16;
}
spa_hook_list_call(&conn->listener_list,
struct pw_protocol_native_connection_events,
start, 0, impl->version);
}
if (impl->version >= 3) {
buf->msg.seq = p[2];
buf->msg.n_fds = p[3];
} else {
buf->msg.seq = 0;
buf->msg.n_fds = 0;
}
data += impl->hdr_size;
size -= impl->hdr_size;
buf->msg.fds = &buf->fds[buf->fds_offset];
if (size < len)
return len;
buf->msg.size = len;
buf->msg.data = data;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
buf->offset += impl->hdr_size + len;
buf->fds_offset += buf->msg.n_fds;
if (buf->offset >= buf->buffer_size)
clear_buffer(buf);
return 0;
}
2017-05-30 19:46:51 +02:00
/** Move to the next packet in the connection
*
2017-05-30 19:46:51 +02:00
* \param conn the connection
* \param opcode addres of result opcode
* \param dest_id addres of result destination id
* \param dt pointer to packet data
* \param sz size of packet data
* \return true on success
*
2017-05-30 19:46:51 +02:00
* Get the next packet in \a conn and store the opcode and destination
* id as well as the packet data and size.
*
* \memberof pw_protocol_native_connection
*/
int
pw_protocol_native_connection_get_next(struct pw_protocol_native_connection *conn,
const struct pw_protocol_native_message **msg)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
int len, res;
2017-05-26 08:05:01 +02:00
struct buffer *buf;
buf = &impl->in;
while (1) {
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
len = prepare_packet(conn, buf);
if (len < 0)
return len;
if (len == 0)
break;
2017-05-26 08:05:01 +02:00
2017-11-13 11:32:06 +01:00
if (connection_ensure_size(conn, buf, len) == NULL)
2019-06-19 16:22:22 +02:00
return -errno;
if ((res = refill_buffer(conn, buf)) < 0)
return res;
2017-05-26 08:05:01 +02:00
}
*msg = &buf->msg;
return 1;
}
static inline void *begin_write(struct pw_protocol_native_connection *conn, uint32_t size)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
2017-05-26 08:05:01 +02:00
uint32_t *p;
struct buffer *buf = &impl->out;
/* header and size for payload */
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if ((p = connection_ensure_size(conn, buf, impl->hdr_size + size)) == NULL)
2017-11-13 11:32:06 +01:00
return NULL;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
return SPA_MEMBER(p, impl->hdr_size, void);
}
static int builder_overflow(void *data, uint32_t size)
{
struct impl *impl = data;
struct spa_pod_builder *b = &impl->builder;
b->size = SPA_ROUND_UP_N(size, 4096);
if ((b->data = begin_write(&impl->this, b->size)) == NULL)
2019-06-19 16:22:22 +02:00
return -errno;
return 0;
}
static const struct spa_pod_builder_callbacks builder_callbacks = {
SPA_VERSION_POD_BUILDER_CALLBACKS,
.overflow = builder_overflow
};
struct spa_pod_builder *
pw_protocol_native_connection_begin(struct pw_protocol_native_connection *conn,
uint32_t id, uint8_t opcode,
struct pw_protocol_native_message **msg)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
struct buffer *buf = &impl->out;
buf->msg.id = id;
buf->msg.opcode = opcode;
impl->builder = SPA_POD_BUILDER_INIT(NULL, 0);
spa_pod_builder_set_callbacks(&impl->builder, &builder_callbacks, impl);
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if (impl->version >= 3) {
buf->msg.n_fds = 0;
buf->msg.fds = &buf->fds[buf->n_fds];
} else {
buf->msg.n_fds = buf->n_fds;
buf->msg.fds = &buf->fds[0];
}
buf->msg.seq = buf->seq;
if (msg)
*msg = &buf->msg;
return &impl->builder;
}
int
pw_protocol_native_connection_end(struct pw_protocol_native_connection *conn,
struct spa_pod_builder *builder)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
uint32_t *p, size = builder->state.offset;
2017-05-26 08:05:01 +02:00
struct buffer *buf = &impl->out;
int res;
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if ((p = connection_ensure_size(conn, buf, impl->hdr_size + size)) == NULL)
2019-06-19 16:22:22 +02:00
return -errno;
p[0] = buf->msg.id;
p[1] = (buf->msg.opcode << 24) | (size & 0xffffff);
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
if (impl->version >= 3) {
p[2] = buf->msg.seq;
p[3] = buf->msg.n_fds;
}
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
buf->buffer_size += impl->hdr_size + size;
if (impl->version >= 3)
buf->n_fds += buf->msg.n_fds;
else
buf->n_fds = buf->msg.n_fds;
if (debug_messages) {
2019-07-17 15:29:18 +02:00
fprintf(stderr, ">>>>>>>>> out: id:%d op:%d size:%d seq:%d\n",
buf->msg.id, buf->msg.opcode, size, buf->msg.seq);
protocol: add v0 compatibility For flatpaks we need to be able to support older v0 protocol clients. To handle this we have: - the connection detects an old client when it receives the first message. It can do this by checking the sequence number, on old versions it contains the message size and is never 0, on new clients the sequence number is 0. - We add a new signal at the start of the connection with the detected version number. This installs the right version of the core proxy. We also move the binding of the client until the hello message is received. This way we can have a new client connect (portal), hand over the connection to an old client, which then removes the client binding again in the hello request with a v0 version. There are some changes to the passing of fds in v0 vs v3 which need to investigated some more. - bump version of our interfaces to 3. This makes it possible to have v0 and v3 protocol marshal functions. - Add version number in the proxy. This is mostly automatically done internally based on the version numbers the library is compiled with. Where the version number was in the API before, it is now actually used to look up the right protocol marshal functions. For Proxies there is usually just 1 version, the current one. It is the server that will support different versions. - Add v0 compat marshal functions to convert from and to v0 format. This has some complications. v0 has a type map it keeps in sync with the server. For this we have a static type map with mappings to our own v3 types. Pods are mostly the same except for objects that used to have arbitrary pods in v0 vs spa_pod_prop in v3. Also convert between v0 spa_pod_prop and v3 spa_pod_choice. Formats and commands are also slightly different so handle those mappings as well. We only have marshal functions for the server side (resource) v0 functions. - Add v0 compatible client-node again. It's a bit tricky to map, v0 client-node basically lets the server to the mixing and teeing and just does the processing of the internal node.
2019-10-08 22:52:25 +02:00
spa_debug_pod(0, NULL, SPA_MEMBER(p, impl->hdr_size, struct spa_pod));
}
buf->seq = (buf->seq + 1) & SPA_ASYNC_SEQ_MASK;
res = SPA_RESULT_RETURN_ASYNC(buf->msg.seq);
2018-05-17 17:26:09 +02:00
spa_hook_list_call(&conn->listener_list,
struct pw_protocol_native_connection_events, need_flush, 0);
return res;
}
2017-05-30 19:46:51 +02:00
/** Flush the connection object
*
* \param conn the connection object
2018-04-19 20:03:52 +02:00
* \return 0 on success < 0 error code on error
2017-05-30 19:46:51 +02:00
*
* Write the queued messages on the connection to the socket
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
2018-04-19 20:03:52 +02:00
int pw_protocol_native_connection_flush(struct pw_protocol_native_connection *conn)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
ssize_t sent, outsize;
2017-05-26 08:05:01 +02:00
struct msghdr msg = { 0 };
struct iovec iov[1];
struct cmsghdr *cmsg;
char cmsgbuf[CMSG_SPACE(MAX_FDS_MSG * sizeof(int))];
int res = 0, *fds;
uint32_t fds_len, n_fds, outfds;
2017-05-26 08:05:01 +02:00
struct buffer *buf;
void *data;
size_t size;
2017-05-26 08:05:01 +02:00
buf = &impl->out;
data = buf->buffer_data;
size = buf->buffer_size;
fds = buf->fds;
n_fds = buf->n_fds;
while (size > 0) {
if (n_fds > MAX_FDS_MSG) {
outfds = MAX_FDS_MSG;
outsize = SPA_MIN(sizeof(uint32_t), size);
} else {
outfds = n_fds;
outsize = size;
}
2017-05-26 08:05:01 +02:00
fds_len = outfds * sizeof(int);
iov[0].iov_base = data;
iov[0].iov_len = outsize;
msg.msg_iov = iov;
msg.msg_iovlen = 1;
if (outfds > 0) {
msg.msg_control = cmsgbuf;
msg.msg_controllen = CMSG_SPACE(fds_len);
cmsg = CMSG_FIRSTHDR(&msg);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
cmsg->cmsg_len = CMSG_LEN(fds_len);
2019-08-16 22:57:24 +02:00
memcpy(CMSG_DATA(cmsg), fds, fds_len);
msg.msg_controllen = cmsg->cmsg_len;
} else {
msg.msg_control = NULL;
msg.msg_controllen = 0;
}
2017-05-26 08:05:01 +02:00
while (true) {
sent = sendmsg(conn->fd, &msg, MSG_NOSIGNAL | MSG_DONTWAIT);
if (sent < 0) {
if (errno == EINTR)
continue;
else {
res = -errno;
goto exit;
}
}
break;
2017-05-26 08:05:01 +02:00
}
pw_log_trace("connection %p: %d written %zd bytes and %u fds", conn, conn->fd, sent,
outfds);
2017-05-26 08:05:01 +02:00
size -= sent;
data = SPA_MEMBER(data, sent, void);
n_fds -= outfds;
fds += outfds;
}
2017-05-26 08:05:01 +02:00
res = 0;
2017-05-26 08:05:01 +02:00
exit:
if (size > 0)
memmove(buf->buffer_data, data, size);
buf->buffer_size = size;
if (n_fds > 0)
memmove(buf->fds, fds, n_fds * sizeof(int));
buf->n_fds = n_fds;
2018-04-19 20:03:52 +02:00
return res;
}
2017-05-30 19:46:51 +02:00
/** Clear the connection object
*
* \param conn the connection object
2018-04-19 20:03:52 +02:00
* \return 0 on success
2017-05-30 19:46:51 +02:00
*
* Remove all queued messages from \a conn
*
* \memberof pw_protocol_native_connection
2017-05-30 19:46:51 +02:00
*/
2018-04-19 20:03:52 +02:00
int pw_protocol_native_connection_clear(struct pw_protocol_native_connection *conn)
{
struct impl *impl = SPA_CONTAINER_OF(conn, struct impl, this);
2017-05-26 08:05:01 +02:00
clear_buffer(&impl->out);
clear_buffer(&impl->in);
impl->in.update = true;
2018-04-19 20:03:52 +02:00
return 0;
}