6e581deb91 added an `spa_autoptr(DbusMessage) m`
for the new message sent out when a signal is received from modemmanager.
However this ended up shadowing the original `m` function arg,
so the code that wanted to interrogate the original arg with
`dbus_get_message_path` etc ended up interrogating this `NULL` value instead.
This triggered a NULL-check in `dbus_get_message_path` and caused
the process to abort.
Original downstream report: https://gitlab.com/postmarketOS/pmaports/-/issues/2886
Currently, the user sets the Broadcast Code via an array of integers
in the config file. However, the Bluetooth Core Specification indicates
that it should be set via a 16 byte string. This commit replaces the old
implementation with the one required by the spec.
Tested the commit with the example provided in the Core Spec:
Broadcast Code: Børne House
Result from btsnoop log:
< HCI Command: LE Create Broadcast Isochronous Group (0x08|0x0068) plen 31
...
Broadcast Code[16]: 000000006573756f4820656e72b8c342
The result matches the example given in the spec.
The mapoffset should be using in the mmap call as the offset.
Mapping the whole memory before the offset and then ignoring the part
before it seems like it can work but it actually has some problems:
1. some drivers (v4l2) use the mapoffset to calculate the buffer to map
2. we waste resources for mapped but unused pages.
The problem with the mapoffset is that it needs to be page aligned and
that used to be a problem in the past. Nowadays PipeWire no longer set
the mapoffset for any of the memory that it allocates.
Add "encryption" parameter to bluez5.bcast_source.config entry in
the configuration file. This allows the user to control the use of
Broadcast encryption.
Advertise support for the videotransform metadata.
Make a new meta.videotransform.transform property to configure the
desired video transformation in the metadata.
This makes it possible for a session manager or other rules to set
a custom transformation on the source.
See #4034
When bound_ctl info cannot be read this array elem info
is set to NULL in 'fetch_bind_ctl'. So when we iterate
the bound_ctl array we always have to check this.
In ACP mode, we might be accessing front:0 as the PCM, and using that
string to generate the ctl device name does not make sense. In
PulseAudio, we used the card index to generate a hw:X string, and we
replicate that here.
Fixes: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/4028
Add macro SPA_CMP to do 3-way comparisons safely, and use it to avoid
signed integer overflows.
Fix also float/double comparisons (previously 0.1 == 0.8 since cast to
return type int).
Fix Id/Bool comparisons so they can return negative value.
Kernel-provided MTU does not work for USB controllers and the correct
packet size to send can be known currently only from RX. So we are
waiting for RX to get it.
The known problem is USB-specific, we shouldn't need the workaround for
other transport types.
Don't wait for POLLIN for non-USB controllers on connect, but ready
things on POLLOUT as usual.
For non-USB controllers, pick some sensible packet sizes to use
initially, before we switch to same size as for RX.
The default kernel pool size on the input is 200 cells. A cell is
about 28 bytes long so the maximum message that can be received in one
go is about 5600 bytes. This causes problems when using amidi to upload
larger sysex messages because they simply can't be received by the
sequencer.
It if however possible to increase this limit with the set_client_pool()
function. Increase the pool size to at least the quantum_limit * 2.
This ensures we can receive and send at least 2 quantums of raw data,
which should be a fairly long sysex message.
Make a min and max value for the pool size. There is an upper limit of
2000 in the kernel but make this configurable and clamp the final
pool size to the min/max.
Make the MAX_EVENT_SIZE 256, because this is how the sequencer seems to
splits the input data as well and it results in less wasted space in the
output buffer.
See #4005
snd_midi_event_encode() will reset the encoder when it returns an
encoded event. It is possible that the function returns with an encoded
event when the internal buffer is full, in that case we need to push the
event and continue encoding without reseting the encoder.
0 is not a snd_midi_event_encode() error, so don't handle it like
one.
The messages, mostly sysex, can be split over multiple control message.
This happens when we read large messages from the sequencer, the
snd_seq_event_input function returns split messages that we transfer to
control messages directly.
When we send those messages out, however, the encoder wants the complete
message before it will return a valid event that we can send out. Keep
on calling the encoder with the control events until we get a complete
message that we can send out.
Fixes#4005
Add a count to each invoke item that is updated with an increasing
loop atomic counter. Flush items from the queues based on their count
so that items are flushed in the order they were added even if they
were added to different queues.
Instead of doing (cycle+1) & 1 for output ports, simply swap the io
areas depending on the port direction (0 = input, 1 = output) and
just to cycle&1 for all ports.
Libcamera formats are generally little-endian, matching DMA DRM
fourccs, while PW ones are big-endian. Thus we have to invert the
order.
Only RGB and BGR where tested, as these are the formats currently
supported by the software ISP. This fixes inverted red and blue in
Snapshot on the Librem5 and Pinephone (OG).
See also gstlibcamera-utils.cpp in libcamera.
