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>
Some partitions are sparse (DATAFS, FACTORYFS), but the largest
partition, UMS, needs to be non-sparse. DATAFS partition also expects
some special images with a magic header (or something), simply trying
to flash a sparse or non-sparse image to it gives an error from device
bootloader:
```
[ ... ]
erase completed(from 73728 to 90111).
.
mmc_pwrite: partition[6] written successfully.
...set_nps_update_start: set nps start flag successfully.
process_packet: id=102, data=0
process_packet: id=102, data=2
process_packet: id=102, data=3
pda completed: id=11, size=31457280, final=0
Invalid Magic Code! 0x 0
[ ... ]
```
Therefore set UMS as default rootfs partition and create non-sparse
images.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8877>
I no longer wish to maintain this, and IIUC devices that use this would
be better off using mainline kernels at this point[1].
1. camera support isn't upstream yet but I have *never* been able to
rely on my x13s's camera even with this kernel so I think it's fine to
wait for proper mainline support
Signed-off-by: Clayton Craft <craftyguy@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8846>
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>
The lack of rationales for device categorization has lead to a lot of
discussions, misunderstandings, and frustrations, as of why the
requirements are the way they are. Even though it's always good to
keep improving and exploring ways to change our processes, having
rationales can help to explain the "why"s that do not really get
addressed by the "how"s of the actual requirements. Hopefully, this
will lead to less discussions and misunderstandings around the
specific requirements.
Closes https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/work_items/146
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8595>
This fixes two issues:
1. I was investigating why currently, pmbootstrap build --force
libcamera would fail. It turns out that the problem was possible to
reduce down to apk add eudev-dev resulting in installing eudev-dev
instead of systemd-dev, even with the systemd repository enabled.
This is because apk actually thinks it has a higher version:
name <eudev-dev> selected from selectable list
select_package: eudev-dev (requirers=1, autosel=1, iif=0, order_id=0x40005807)
consider systemd-dev-261_rc4-r0 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=100, installed=0
prefer existing package
choose as new provider
consider eudev-dev-3.2.14-r6 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=100, installed=0
select latest by requested name (greater)
choose as new provider
consider libudev-zero-dev-1.0.4-r0 iif_triggered=0, tag_ok=1, selectable=1, available=1, flags=0x0, provider_priority=20, installed=0
select latest by requested name (less)
selecting: eudev-dev-3.2.14-r6, available: 1
assign eudev-dev to eudev-dev-3.2.14-r6
disqualify_package: systemd-dev-261_rc4-r0 (conflicting provides)
disqualify_package: libudev-zero-dev-1.0.4-r0 (conflicting provides)
And why is that? It's because we have two providers here: One is
eudev-dev with a provider version of 3.2.14-r6, and the other is
systemd-dev with a provider version that is empty. This then results
in apk thinking the version number is greater, as seen above in the
verbose output. An unversioned provides= for an exact package name
match will never, ever, ever have any effect, even if the priority is
set super high, because the version number comparison is before apk
even starts looking at provider priorities.
Therefore, we should not have unversioned provides for eudev,
eudev-dev, eudev-libs and udev. Since those have fairly low version
numbers, we can just provide them with systemd's version number and
we'll be fine. This will now result in apk actually installing
systemd-dev when eudev-dev is prompted for installation.
2. After fixing the aforementioned issue, I noticed that I couldn't
build anything anymore. This is because my dependency tree would pull
in systemd and systemd-udev - completely normal. However, both
systemd and systemd-udev were providing eudev, and apk will refuse to
install two packages that provide the same thing at the same time.
The fix for this is to just not provide eudev in the top-level
systemd package and rather let systemd-udev do that.
With this, I can now finally build libcamera again!
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8857>
Aelin