Notably:
1. Add the in-review quad-debayer patch required for the imx371 - the OP6
front camera.
2. Fix GLES 2.0 devices like the Librem5 and PinePhone
3. Small tuning file adjustments, including CCMS for the imx371 and
imx800 (FP5 main rear camera).
4. A small patch allowing to set maximum resolutions via config file.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9449>
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>
The new driver for hardware video en- and decoding, reported to be more
stable. SC7280 support got enabled in 6.19 with commit
"media: iris: enable support for SC7280 platform"
Also include some changes required by kconfig check.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7889>
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
So that the file managers and choosers - Nautilus by default - show thumbnails
not only for images but also videos. Apart from being a nice-to-have, it
can help prevent privacy issues like uploading/sending wrong videos - an
increasingly realistic scenario as camera recording becomes more usable.
Note that Gnome usually uses totem-video-thumbnailer for that job,
but ffmpegthumbnailer has fewer dependencies, seems to be more stable,
is slightly faster - and pmOS already comes with ffmpeg, so there are
no additional licensing issues.
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6300
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
The udmabuf allocator enjoys increasing popularity, not only being
used by libcameras swISP and some virtualisation apps, but since Mesa
commit d74ea2c1 even in llvmpipe - and more projects plan adoption,
such as Gstreamer.
Thus let's ensure it's universally available for UI users if the
kernel supports it.
As there are DEs that don't support the "uaccess" tag, such as SXMO,
and "legacy" groups are still used in pmOS anyway, use the later.
By sharing the config file and making the systemd unit files match the
openRC ones as close as possible.
Also fix the q6voiced.conf path while on it.
Co-authored-by: Clayton Craft <clayton@craftyguy.net>
By sharing the config file and making the systemd unit files match the
openRC ones as close as possible.
Co-authored-by: Clayton Craft <clayton@craftyguy.net>
Matching the openRC ones. Also make use of the hexagonrpcd_fw_dir env var
and reuse the correcponding conf files, making it easier to support
both init systems.
Gstreamer enables hw de- and encoding by default for the most common APIs,
including V4L2-stateful. Unfortunately the venus driver is still quite
unstable, reliably crashing in very common scenarios, triggering apps
like Snapshot, Showtime or Tuba to show error messages or not working
properly - partly because of non-optimal error-handling.
Until the kernel driver situation improves, set environment variables
that demote the decoders to fallbacks in case nothing else is available,
and disable the hw-encoders completely as they tend to destabalise the
whole system if something goes wrong.
Useful command for env variables:
systemctl --user show-environment
The current OOTB Gstreamer experience on Gnome DEs can be disappointing as
a lot of default codecs and elements are missing. This is often not obvious
for users as Gst in various cases has less optimal fallbacks, easily leaving
the impression that either an app, drivers or hardware are at fault.
Add the most important packages to pmb_recommends so users have a better time.
Notes:
- Many images already ship ffmpeg-libavcodec, so this shouldn't worsen the
legal situation.
- '-bad' is usually already pulled in indirectly while '-good' at least for
GS variants is already required. Both are strongly recommended for apps
like Showtime, Snapshot and many more mobile-friendly apps from the
ecosystem.
- '-bad' really isn't bad any more these days and various elements in it
are used by default if available. That is, many elements there should have
long moved to '-good'.
So Gnome-based DEs have a video-player by default. The main arguments
in favor showtime I see are:
1. It's the main candidate to become the new Gnome default video player.
2. It's has a mobile-friendly UI.
3. It uses HW-decoding and even zero-copy playback by default on many pmOS
devices (by using Gstreamer and unlike e.g. ffmpeg-based players like mpv).
4. Its main dependencies are shared with other apps like snapshot.
The other candidate that would tick the same boxes but 1. is livi.
[ci:skip-build]: already built successfully in CI
This partly reverts the commit mentioned below. When disabling CMA
I thought that libcamera was the only user of it, which is only true
for userspace, though.
In fact CMA is used and often even required by the kernel for HW video
decoders, display engines and other hardware that might not have a
MMU.
Thus restore the previously established value.
Fixes: 196ece029 (linux-postmarketos-allwinner: enable CONFIG_UDMABUF (MR 5585))
[ci:skip-build]
This partly reverts the commit mentioned below. When disabling CMA
I thought that libcamera was the only user of it, which is only true
for userspace, though.
In fact CMA is used and often even required by the kernel for HW video
decoders, display engines and other hardware that might not have a
MMU.
Thus restore the previously established value.
Fixes: 196ece029 (linux-postmarketos-allwinner: enable CONFIG_UDMABUF (MR 5585))
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
Robert Mader