C++20 introduced designated initializers similar to the ones found
in C99, however, in C++ designated initializers cannot be mixed
with non-designated initializers. GCC rejects mixed initializers
with an error.
Similarly as in spa_dbus, don't exit if bus goes down. Neither the
audio or midi Bluetooth backend reconnects to DBus, but they shouldn't
exit the process.
When the follower doesn't produce enough data for this many attempts,
bail and cause an xrun to avoid an infinite loop.
The limit of 8 cause real-life problems and should be larger. It should
probably depend on the expected size per cycle (node.latency) and the
current quantum but we don't always have this information.
See #4334
There is a race between logind applying ACLs to allow the active session
of a locally present user access to devices with a udev uaccess tag
(like /dev/video# nodes) getting applied vs wireplumber/pipewire starting.
Wireplumber/pipewire are part of the (user) default.target, which gets
started as soon as a user logs in and systemd --user is started for that
user, where as logind only starts applying the ACLs after the gnome-shell
associated logind session has been created.
This race may cause pipewire to not see v4l2 video sources at login,
this can be reproduced with these steps:
1. sudo setfacl --remove-all /dev/video*
2. systemctl --user restart pipewire
3. Now wp-ctl status will not show any video devices
(like if pipewire was started before the udev uaccess ACLs got applied)
4. Do a switch to another (test) user without logging out, e.g. in GNOME
go to the top right system menu press the power on/off icon and select
"Switch User..."
5. Switch back to your normal user. Run getfacl /dev/video0 this will show
your user has access now.
6. wp-ctl status should show the camera now, but it does not.
Fix pipewire not seeing v4l2 sources in this case by making v4l2-udev
monitor systemd-logind session changes and redoing the access() checks
on /dev/video# nodes when the session changes.
Closes: #3539Closes: #3960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 2a6ba61264)
The spa_loop_add_source() call for udev event monitoring which uses
impl_on_fd_events() is done from start_monitor() which also unconditionally
calls start_inotify().
Since start_monitor() already always calls start_inotify() there is no
scenario where start_inotify() has not been called yet when
impl_on_fd_events() gets called. So the start_inotify() call in
impl_on_fd_events() is redundant, remove it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit ab245947e5)
Now that start_monitor() (which calls start_inotify()) is called before
enum_devices() it no longer is necessary to call start_watching_device()
for devices which have been enumerated before start_inotify() gets
called (since there will not be any such devices anymore).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 46f89d8009)
This fixes 2 races wrt probing v4l2 devices:
1. Before this change there was a window where a new udev device can get
added between the udev_enumerate_scan_devices() call in enum_devices() and
the udev_monitor_enable_receiving(this->umonitor); call. If this window was
hit then enum_devices() would not see the device and no udev-event for it
would be received either causing the device to not be seen.
Enabling udev event monitoring before calling udev_enumerate_scan_devices()
fixes this. Note that the code is already prepared to deal with getting
multiple add/change events for the same udev device, so hitting the new
race window where PipeWire may receive both an add- or change-event and
also sees + probes the device from enum_devices() is not a problem.
2. Before this change devices added by enum_devices() would not have
inotify monitoring activated right away because notify.fd = -1 at this
time turning start_watching_device() into a no-op.
These devices without inotify monitoring would then have their access
checked by process_device() calling check_access().
Then after all devices have been enumerated start_monitor() would call
start_inotify() which calls start_watching_device() for all devices added
by enum_devices(). This leaves a window where the ACL can change without
there being an inotify watch for it.
Calling start_monitor() before enum_devices() puts start_inotify()
notify before enum_devices() so that the add_device() calls done
by enum_devices() will now successfully call start_watching_device()
closing this window.
PipeWire is somewhat likely to not notify ACL changes because of this
because PipeWire is part of the systemd user default.target, where as
logind only starts applying the ACLs after GNOME has created the seat
for the GNOME session. So on first login we have PipeWire starting
and logind applying the ACLs at the same time, which allows for the ACL
change to hit the small race window where PipeWire is not monitoring
for ACL changes. Fixing this second race should hopefully resolve
issue #3960.
Closes: #3960
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 584168caab)
Previously both `impl_on_notify_events()` and `process_{device,card}()`
called `check_access()`. Avoid that by merging `ACTION_ADD` and
`ACTION_DISABLE` into a single `ACTION_CHANGE` and let `process_{device,card}()`
call `check_access()` and decide what to do.
(cherry picked from commit ad975c93ee)
Split up `process_{device,card}()` to have a separate function that does
the lookup based on the udev device, and only use that when there is
no available reference to the actual device/card object.
(cherry picked from commit 69f9e75458)
`IN_IGNORED` event is sent whenever the watch is removed,
which includes when the entity is deleted among other things,
so watch that instead of the more specific `IN_DELETE_SELF`.
(cherry picked from commit 04b8a0c215)
When we drop the first buffer to avoid timestamp problems, queue it
again in the driver or else we will not be able to dequeue is again
later and we will be running with a buffer less.
Claim that call waiting notifications are supported.
Required for some devices (e.g. Soundcore Motion 300),
as they stop sending commands if the reply to CCWA is not OK.
Make a property to pass a custom function pointer to create threads
instead of pthread_create.
Use this in jack instead of bypassing the thread utils create function,
which gives the wrong thread rt priority with rtkit.
Fixes#4099
Use dynamic pod builder so that we can also build complex formats.
Make sure we zero the format before we parse it or else we end up with
potentially uninitialized values.
When ENUM_FRAMESIZES or VIDIOC_ENUM_FRAMEINTERVALS return EINVAL for the
first index, make a dummy result and continue with that. This will
trigger an intersect withe filter so that we end up with something valid
instead of nothing.
Handle 0 framerates without crashing.
See #4063
Some complex camera pipelines, like the IPU6 can involve many /dev/video#
nodes (32 in the IPU6 case) and the current size of 128 chars is not enough
to hold all /dev/video# nodes in this cases causing SPA_KEY_DEVICE_DEVIDS
to get truncated, which in turn breaks the filtering of V4L2 devices which
are used by a libcamera driven camera in wireplumber.
Fix this by increasing the size of devices_str[] to 256.
This fixes wireplumber adding a bunch of non-function V4L2 video sources,
e.g. before this "wpctl status" outputs the following video sources:
Video
├─ Devices:
...
├─ Sources:
│ 90. ov2740
│ * 115. ipu6 (V4L2)
...
│ 135. ipu6 (V4L2)
│
├─ Filters:
After this fix the output is:
Video
├─ Devices:
...
├─ Sources:
│ * 92. ov2740
│
├─ Filters:
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Change the GenericFd data type to SyncObj. It's probably better to
explicitly state the data type than to make something generic. Otherwise
we would need to transfer the specific fd type somewhere else and there
is no room for that in the buffer and the the metadata is not a good idea
either because it can be modified and corrupted at runtime.
Add the SyncTimeline metadata. This contains 2 points on two timelines
(SyncObj datas in the buffer). The buffer can be accessed when the
acquire_point is signaled on the timeline and when the buffer
can be released, the release_point on the timeline should be signaled.
Add a SPA_PARAM_BUFFERS_metaType in the Buffers object. This contains a
bitmask of the mandatory metadata items that should be included on a
buffer when using this Buffers param.
Make the buffer allocation logic skip over the Buffers params that
require unavailable metadata.
This can be used to, for example, enforce specific metadata to describe
extra buffer memory (such as the meaning of generic file descriptors).
One such use is the explicit sync, where an extra buffer data is needed
for the sync fd along with metadata that contains the sync_point.
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.
We delay the audio a bit to keep packet intervals equal, which keeps
some data in buffers.
In theory the calculation keeps one buffer free, but it doesn't
explicitly keep "extra" buffer space so in theory might flush too late
and next process() might not have free buffers. However, as we encode
next packet right away this shouldn't really occur...
Try to keep one extra spare buffer free so that the flush time is
certainly early enough.
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.
This fixes an issue introduced in 771f71f622
where the quantum is forced and may break applications the specify their
own quantum.
Signed-off-by: Lukas Rusak <lorusak@gmail.com>
Debug and trace log messages are often written based on the stderr
logging, where code location is always visible.
journalctl does not show the code location without extra tricks,
which makes user-submitted debug logs from journal more cryptic.
Make journal log more similar to stderr logs by prepending the code
location and log level in the log message when the log topic
level is >= DEBUG.
