Currently, hexagonfs relevant firmware files are
installed into
/usr/share/qcom/qcm6490/SHIFT/otter/hexagonfs while the
correct location should have been
/usr/share/qcom/qcm6490/SHIFT/otter.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8861>
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>
As a consequence of the hermetic-usr work, /etc/udev/rules.d is slowly
disappearing. This can results in errors like:
18:05:30.180191 hookfiles: unable to process hook file "/usr/share/mkinitfs/files/05-ci.files": unable to add "/etc/udev/rules.d": getFile: failed to stat file "/etc/udev/rules.d": stat /etc/udev/rules.d: no such file or directory (also tried "/etc/udev/rules.d.zst": stat /etc/udev/rules.d.zst: no such file or directory)
from
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8863#note_563184
due to the directory not being present.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8866>
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>
initramfs starts USB NCM gadget and unudhcpd for SSH login.
This requires special handling since unudhpcd is unmanaged by the
service manager until the userspace is started. Once entered in userspace,
the usb-moded-developer-mode needs to be activated which configures
NetworkManager and starts unudhcpd under the service manager.
This way, a full handover is possible and the gadgets can be properly
switched without any leftovers from the initramfs due to the unmanaged
situation.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8553>
