Similarly to how it was done for xiaomi-beyllium with varying
display panels, add kernel variant for clover-plus.
Mi Pad 4 Plus is very very similar to regular Mi Pad 4,
but it has different panel and different touchscreen.
Therefore it uses different device tree in kernel - and it
is the only changed line in deviceinfo file.
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
[ci:skip-build]: Already built successfully in CI.
In order to make it work properly, the fcc unlock script from MM should
also be enabled... This info will be added to the device's wiki page for
now since upstream MM discourages distros from enabling these unlock
scripts by default...
fixes https://gitlab.com/postmarketOS/pmaports/-/issues/2489
[ci:skip-build]: Already built successfully in CI.
The fbdev backend was removed with Weston 10 which has been out for a
good while now. As such, it doesn't matter whether Xwayland works or not
since Weston won't work at all --- the DRM backend, which is what would
get used instead of fbdev with this removed, won't work on downstream
kernels like the one used by this device.
[ci:ignore-count]
[ci:skip-build]: Already built successfully in CI.
The fbdev backend was removed with Weston 10 which has been out for a
good while now. As such, it doesn't matter whether Xwayland works or not
since Weston won't work at all --- the DRM backend, which is what would
get used instead of fbdev with this removed, won't work on downstream
kernels like the one used by this device.
There is no dri-backend.so. I don't know if this ever existed. May have
been a typo where the author meant to type drm-backend.so. The DRM
backend should be the default anyway, so just remove it instead of
fixing what may have been a typo.
The fbdev backend was removed with Weston 10 which has been out for a
good while now. This device should be able to use the DRM backend
anyway given that it uses the A64 SoC which also e.g. the PinePhone
uses.
Additionally, the comment about Xwayland being broken contradicts the
actual configuration file where Xwayland actually is being enabled
(xwayland=true), so this shouldn't be causing any regressions even if it
actually is broken.
The fbdev backend was removed with Weston 10 which has been out for a
good while now. As such, Weston won't work with the downstream port
anyway which is likely where Xwayland supposedly was broken. As such,
remove this unnecessary configuration file.
In the mainline ds2482 onewire kernel driver, active_pullup defaults to
1 which is setting the APU register. This caused the connection to the
ds2784_battery slave to be unstable and flaky. In the AOSP manta project
this flag is set to 0 as well.
This is a device-specific package. No need to keep it in main where it
gets included in stable releases unnecessarily. The only device that
depends on this, device-inet-a33, is in testing, so let's move it there
too.
These cmdline params are not needed because the issues they worked
around were fixed in 6.7 or in this kernel branch we are using.
Additional modules are included in the initramfs since they may not be
builtin in the future, and not having them loaded in the initfs can break booting
kconfig changes:
- Most are due to running 'pmb kconfig migrate'
- Enable USB_F_FS
- Build ath11k as a module + enable debug, to help with debugging
pma#2361
- Enable support for BT BR/EDR stuff (like HFP)
- Enable CRYPTO_MD4 for EAP_MSCHAPv2
This uses oem-specific packages for configuring Intel and AMD systems,
and installs them all by default for new images using pmbootstrap's
pmb_recommends feature.
The intention is to provide pre-built images with support for Intel and
AMD already enabled/configured, and users can remove an unwanted set of
packages (e.g., `apk del device-generic-x86_64-intel` when on an AMD
system) if they want to.
Upgrading existing systems should work, in that I haven't observed any
apk conflicts with it. But you do need to manually install the new
oem-specific package if you need it (e.g. `oem-intel`)
fixes https://gitlab.com/postmarketOS/pmaports/-/issues/2484
In preparation of new sdm660-mainline kernel release all
downstream ports will become irrelevant.
If needed, downstream port can still be chosen as
'xiaomi-lavender-downstream' during pmbootstrap init.
Signed-off-by: Alexey Minnekhanov <alexeymin@postmarketos.org>
[ci:skip-build]: already built successfully in CI
non-free firmware not (yet?) submitted to linux-firmware, this is pulled
directly from the latest versions distributed by lenovo, instead of some
probably outdated repo distributed by random folks.
The bt firmware here fixes an issue where the bt range on the 21bx is
extremely poor (like ~1 meter or less)
linux3.4-ARM-8933-1-replace-Sun-Solaris-style-flag-on-section-xz-supplementation.patch
contains an addition that was not part of
linux3.4-ARM-8933-1-replace-Sun-Solaris-style-flag-on-section.patch
simply because error did not occur with the config I tested with.
[ci:skip-build]: already built successfully in CI
This device package is intended to replace the tablet-x*uefi device
packages. It was made by basically merging config from those two
packages.
One important change (besides the name, covered later) is that it
replaces grub-efi with sd-boot for these devices.
The pkgver is starting at '8' to get ahead of the packages this is meant
to replace.
Because package names, especially for device packages(!), is important,
here's a long explanation of why the name is "device-generic-x86_64":
"uefi" was excluded from the device package name, because it should (in
theory at least...) be able to simultaneously support EFI and non-EFI
boot in 1 device package. The device-qemu-amd64 package kiiiinda does
this already and could be a useful example for how to do that, though in
this situation we'd need to support syslinux for legacy boot instead of
what qemu does (bypass installed bootloader and directly boot the
kernel). In other words, the packages this one is meant to replace only
support EFI boot, they currently don't support legacy boot. So IF we
need to support legacy boot in the future and IF there's no way to
support both in one package, THEN we can consider changing the name of
this one or calling the other "-legacy" or something.
"x86_64" instead of "amd64" (like the device-qemu-amd64 device package),
because "x86_64" is what Alpine uses to refer to this arch, and it
doesn't have a hw vendor name baked into it.
"tablet" was dropped from the name, because there are many other x86_64 devices
out there that people might want to install pmOS. For example, it might be
confusing if you want to install pmOS on an x86_64 toaster but best
pmOS image for it is named "device-tablet-..."
This replaces the outdated blobs extracted from Android vendor partitions with more recent firmware provided in the linux-firmware-brcm package.
[ci:skip-build]: Already built successfully in CI.
