libcamera says that cameras should default to manual focus mode. This
means that unless pipewire clients specifically change this control,
users with an autofocus-capable camera are left with an out-of-focus
image. This patch sets the autofocus mode to continuous and enables
auto-exposure (as the default for this is unspecified).
Testing with an imx708 on Raspberry Pi OS on a Raspberry Pi 4, before
this patch the image was generally out of focus in Firefox/webrtc, after
this patch autofocus works correctly.
(cherry picked from commit 3a0ffe21e6)
Add an index offset when enumerating controls. We insert 2 properties
before enumerating the controls so the index of the first control needs
to have an offset of 2.
When using Open Broadcaster Software with Pipewire and a libcamera
camera node, changing the ExposureTime doesn't work.
The commit introducing the camera control setting has commented out the
integer case: ef4b9745b2 ("libcamera: handle canceled requests")
But as it doesn't give a reson for the comment, it looks like an
oversight.
Therefore removing the comment to allow setting the ExposureTime integer.
Signed-off-by: Sven Püschel <s.pueschel@pengutronix.de>
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.
Add a MAPPABLE data flag that hints that the fd in the data is mappable
with a simple mmap/munmap. Normally, DmaBuf is not mappable like that
unless explicitly indicated with this flag.
Set the MAPPABLE flag on the DmaBuf from v4l2 and libcamera fd.
When asked, mmap the buffer memory in all cases when the MAPPABLE
flag is set.
This solves the case where v4l2 has exported DmaBuf and is streaming to
node A and then node B links but doesn't get automatically mmaped
memory.
Fixes#3840
A driver node should use the target_duration and target_rate to adjust
the quantum and rate when the graph starts.
The camera nodes don't currently support any of this and simply enforce
a specific rate and duration for the graph clock. Mark this with a
FIXME. Otherwise, pipewire will complain that the node is ignoring the
configured graph rate.
We should really look at the graph target rate/quantum and only produce
a buffer when it is inside the current graph cycle. This would make it
possible to join audio and camera nodes and have them be in sync.
According to https://docs.pipewire.org/page_dma_buf.html, i.e. announce
each format once with, once without `SPA_FORMAT_VIDEO_modifier`
property.
Note: currently libcamera always uses `DRM_FORMAT_MOD_LINEAR` (`== 0`),
so `pix.modifier()` returning `0` does not mean that no modifier is
supported.
This is needed for clients using the new DMABuf negotiation pattern,
such as gstpipewiresrc after 602aa7d5.
`Transform::Rot90` means the client should rotate 90 deg. clockwise,
which matches `SPA_META_TRANSFORMATION_90`, i.e. the buffer was
rotated 90 deg. anti-clockwise. The flipped cases should be correct
though.
Also add the source value to the debug print for easier future
debugging.
Fixes fa799aac86
libcamera can detect camera transforms/rotation, e.g. from the device
tree, and makes that information usable for clients via
`CameraConfiguration::transform`.
Advertise this information via the VideoTransform meta so Pipewire
clients can adjust their output accordingly.
Rotated cameras are common in mobile devices such as the Pinephone Pro,
which was used to test this feature.
Pick the first format in the list of supported as something closest
to 640x480 instead of the lowest possible resolution.
Applications that don't suggest a default size will then get something
more sensible than a poster frame.
Keep track of the negotiated parameters and use those to construct
the Buffers param.
Use the FrameAllocator to allocate buffer memory. Keep a request for
each buffer and queue them.
In requestComplete, put the request metadata info into the buffer and
header and write the finished buffer id to a ringbuffer. Then wake up
the data thread to pop the finished buffer_id and push it in the
graph.
Remove some old files.
