It's far from perfect but better than the default. Most importantly it
gives users of the OP6 - one of the most popular devices - an impression of
where libcamera development is heading - and an incentive to help/play
around with tuning.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8992>
See
https://gitlab.freedesktop.org/camera/libcamera/-/releases/v0.7.2
The release notably includes fixes that allow us to start shipping color
correction matrices in tuning files. This commit includes the current
tuning iterations for the imx363 (used e.g. as Pixel 3a rear camera) and
the s5kjn1 (used on e.g. as FairPhone 5 front camera). The later is also
used for the other correspondig cameras on the mentioned devices, as
they improve the quality over the default. This is of course planed to
change in the future.
The GPU-ISP also received major performance improvements, in particular
if the dmabuf direct import path can be used. If that's not the case
some INFO logs are printed, giving hints what needs to be improved in
the V4L2 or GPU drivers.
Finally we can drop all previously backported patches, only keeping two
PinePhone (OG) specific ones around for now. These should probably be
dropped in future releases, giving the poor performance and limited GPU
capabilities (GLES 2.0 only) on that device.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8991>
Replace the dmabuf import patch with the two series that it grow into
during upstreaming, shipping in the next libcamera release. This will:
1. Improve performance for all devices using the GPU-ISP, including
those not able to use dmabuf import.
2. Simplify debugging.
3. Ensure the patches get enough testing before the upstream release.
While on it backport some additional patches:
1. A follow-up patch adding the last required step to allow dmabuf import
for input buffers to work in almost all cases *if* the V4L2 driver
handles custom bytesperline requests for bayer formats.
2. A small logging fix
3. A fix for bad bottom lines of pixels seen on some devices. This is
the only patch with visual impact - and a quite desirable one.
4. A patch to log the used driver for easier debugging.
This leaves us with only two downstream patches, both specific to the
PinePhone (OG).
Finally, add a "py3-$pkgname-pyc:pyc" subpackage in order to stay in
sync with the upstream package.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8650>
See https://gitlab.freedesktop.org/camera/libcamera/-/releases/v0.6.0
Remove various upstreamed and move downstream tuning files into a
folder instead of wrapping them in patches.
Also sync up a bit to the alpine package by adding dependencies and the
python package.
Note: unfortunately this release does not contain the GPU-ISP. There
are various improvements to the SW-ISP, the simple pipeline handler and
other areas which should improve the experience on various devices with
pmOS, though.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7445>
Analog to a recent change in Fedora:
https://src.fedoraproject.org/rpms/libcamera/pull-request/14
This change allows to easily create virtual cameras, which is helpful
for testing and debugging purposes, both for system components like Mesa
and Pipewire as well as various apps.
The virtual cameras can be enabled by:
```
cd /usr/share/libcamera/pipeline/virtual
cp virtual.yaml.example virtual.yaml
systemctl --user restart pipewire
```
Using the test option allows to keep the arch dependent automatic pipeline
selection in place. It also enables building of the vimc pipeline -
which is very small - and all tests, however those don't get included
into the packages.
The new dependency, libyuv, is very small and already installed by
default for DEs like gnome-mobile.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6567
[ci:skip-build]: already built successfully in CI
Only containing black levels for now.
This should only slightly increase image quality, but apparently also
works around a bug in libcamera making the output all black, with
occasional purple or red flashes.
[ci:skip-build]: already built successfully in CI
Our libcamera fork needs a rebuild, as pointed out by the
upstream-compat monitoring job:
Increase 'libcamera' pkgrel (9 -> 10), missing depend(s): so:libgtest.so.1.15.2
[ci:skip-build]: already built successfully in CI
Which fixes most glitches sometimes visible when using the sw-ISP with
clients that directly import the buffers to the GPU, such as Snapshot
47.
The patch will be part of the next libcamera release, which however
does not have a clear release date yet.
[ci:skip-build]: already built successfully in CI
In upstream discussions regarding dmabuf allocation in was concluded
that using udmabuf, which only uses virtual memory, is the better
option for the time being. Libcamera gained support for that with
version 0.3.1 and it was confirmed that devices currently using the
libcamera softwareISP can sample from them, notably:
- Librem5
- PinePhone
- Pixel 3a
Thus let's follow upstream and allow access to that by default - and
remove access to /dev/dma_heap again.
See also: https://github.com/systemd/systemd/pull/33738
[ci:skip-build]: already built successfully in CI
Rebase our downstream patches and drop the one included in the release.
See https://gitlab.freedesktop.org/camera/libcamera/-/releases/v0.3.1
Notes:
- The abi-compliance checker reports 100% binary and source compatibility,
so this release does not change the SONAME.
- qcam has been ported to QT6.
- This release has some notable improvements to the PPP/rkisp1, however
lower frame rates might be encountered sometimes. This will hopefully
get fixed in the imx258 driver in Linux 6.11.
- The swISP got some fixes but nothing major apart from the patch we
were already carrying.
[ci:skip-build]: already built successfully in CI
Which can have significant performance impact on affected devices,
such as the Librem5 or the PinePhone.
The patch already landed upstream, however a new release is likely
several weeks or months away, making a backport worthwhile.
[ci:skip-build]: already built successfully in CI
which are probably too experimental to ask Alpine to carry them, while being
very helpful for devices that pmOS targets. The explicit goal is to help
Libcamera development and drop the fork again.
For the dma heaps permissions see the ongoing debate in
https://lore.kernel.org/all/bb372250-e8b8-4458-bc99-dd8365b06991@redhat.com/
It's possible that Libcamera will switch to another solution in a future
release or that memory accounting issues around dma heaps will need to
get fixed in the kernel before the permissions can be set by default by
distros.
Regarding `libcamera: simple:` patches:
- 0001-0003 can likely be dropped once the Libcamera SoftISP gains
support for raw (bayer) streams passthrough (on top of converting to
RGB or YUV formats).
- 0004 will likely be needed until Megi downstream patches for the
Pinephone get improved/upstreamed and Libcamera adopted accordingly.
With these patches libcamera and pipewire based applications should work
on the Librem5, Pinephone and - hopefully soon - devices like the OP6.
See https://gitlab.com/postmarketOS/pmaports/-/merge_requests/5162 for
more context.
[ci:skip-build]: already built successfully in CI
