[ci:ignore-count]
[ci:skip-vercheck] needed for the postmarketos-ui-* packages in this
series
[ci:skip-build] already built ui-* packages in CI, and device pacakges
are just trivial deviceinfo change (manually built some just to verify)
Workaround for https://source.puri.sm/Librem5/linux-next/-/issues/303.
It seems worth sacrificing some power savings for a modem that won't
disappear, at least until the above issue is fixed.
[ci:skip-build]: already built successfully in CI
Headset jack events emit 2 events: 'Headset Microphone Jack'
and 'Headphone Jack'. These were properly detected before,
but not headphone jack events only: 'Headphone Jack'.
This change allows to detect headphone jack events as well
and act on these events by setting the headphones as
default audio output while keeping the internal
microphone as audio input. For headsets,
the microphone is switched to the headset microphone as well.
The PMIC AXP803 sends an interrupt to the A64 CPU when the
battery is critical low. This wakes up the phone at ~10%
battery level, but UPower wasn't configured to add upon
this interrupt as the action level was way lower.
Therefore, the PMIC performed a hard shutdown when the
battery level dropped further, which may cause data loss.
We used to have it at 40% and just bumped it to 100%. With 100%, I can
hear static noise in the headphones when using the PinePhone (pmOS CE)
in a silent room, even if I turn the volume down in Pulseaudio (e.g.
18%-30% in Phosh). This was not the case when we had it at 40%.
70% seems to be the sweet spot, where no static noise can be heard when
using headphones in a silent room, but where volume can still be turned
up to a very high level if necessary.
Upstream changelog:
ca736e844a
Patches rebased, and includes some new fixes:
arm64-dts-imx8mq-librem5.dtsi-adjust-the-usdhc-bus-s.patch
- Being tested by Purism as well, has shown some promise improving GPS
reliability
arm64-dts-imx8mq-disable-SuperSpeed-instances-in-par.patch
- Fixes issue with modem disappearing
Upstream changelog:
4e76143d2e
Note, previous wifi driver behavior is not changed. The redpine module
still expects the fw to be in /lib/firmware on boot, and won't use the
fw on the card.. Theoretically this kernel version now supports both
loading fw from rootfs into ram AND using fw burned on the chip, but
since I haven't tested that well yet I'm leaving this as-is.
[ci:skip-build]: already built successfully in CI
uboot-tools is provided by u-boot-tools but sometimes apk still gets
confused. This change prevents errors such as
pine64-pinephone:~$ sudo apk upgrade --verbose
WARNING: Failed to perform initial self-upgrade, continuing with full upgrade.
ERROR: unable to select packages:
uboot-tools (virtual):
provided by: u-boot-tools
required by: device-pine64-pinephone-0.25-r1[uboot-tools]
[ci:ignore-count]
[ci:skip-build]: already built in CI successfully
mce is used by both Glacier and Asteroid to do all kind of power
management related stuff, including blanking the display. However,
obviously we don't ever want to blank the display on Qemu
Upstream changelog:
6dcba4b588
The redpine interrupt handler patch has been dropped since it's now
merged in Purism's tree.
[ci:skip-build]: already built successfully in CI
A hack shamelessly stolen from Manjaro. Plasma Mobile runs in the user
session and needs direct access to the sys entries of the flashlight to
be able to toggle it in the GUI
[skip ci] Broken, thinks there is an unreferenced file while there is
not
Move the shelli-specific alsa config from MR 1741 into a subpackage that
only gets installed together with shelli.
With the config installed, programs using alsa instead of pulseaudio,
can't be controlled through the volume setting in Phosh anymore (and
probably other UIs too). Shelli doesn't use pulseaudio.
Change the path of the config file like in MR 1877, so it's easier to
override it if necessary.
While at it, improve the APKBUILD slightly by fixing the install_if of
the phosh subpkg (should depend on =$pkgver-r$pkgrel, see APKBUILD
reference), and fix long lines.
This adds eg25-manager for managing modem power in userspace instead of
relying on the modem-power stuff in the kernel. The userspace
eg25-manager has proven to be more reliable than using modem-power.
An older setup-modem script is installed for ofono, since eg25-manager
cannot interface with ofono (yet).
The eg25 init script was removed since it only dealt with configuring
the modem-power driver in the kernel
[ci:skip-build]: already built successfully in CI
Alpine's abuild is soon going to complain if an APKBUILD has more than
one "Maintainer:" listed. Work around it by renaming the additional
maintainers to "Co-Maintainer:". While at it, move the devicepkg reference
link to the top in device-xiaomi-santoni for consistency.
In postmarketOS, we require at least two maintainers for devices in
main, therefore it does not make sense to drop additional maintainers
from the file.
In Alpine, this change was made because pkgs.alpinelinux.org apparently
can't handle more than one maintainer. I looked into it, and it would
require a database change to add it there, so it does not seem worth the
effort. I also thought about extending abuild to add an environment
variable to skip the check, but then the package would not build with
plain abuild without using the env var.
Related: dd4cd9d606
[ci:skip-build] [ci:skip-vercheck]
At the moment we have Contributor: lines on some packages (but not all of them),
but often they don't represent the actual contributors to the package very well.
E.g. when we added them retroactively to the device packages we only added
the initial contributor (which isn't necessarily the person
who made most of the work for a device...)
The Git history is the most representative source for figuring out
who contributed to a package, so there is no reason to duplicate that
into the APKBUILD.
[skip ci]: way too many packages
For testing changes for device categorization, it is useful to have
a device in each of the categories. The PinePhone is close to being
moved to main/, but it doesn't fulfill all requirements yet.
The QEMU "device ports" are very simple since QEMU currently only
emulates a rather limited set of hardware features. All available features
are working correctly (especially after the recent rework of the QEMU
packages). I suppose it is also usable as a "daily driver", at least for
its intended purpose (a virtual machine for testing postmarketOS changes). :)
Given that everyone can run QEMU, everyone could potentially maintain
it. For now I have added myself as maintainer since I did most of the
recent cleanup. Add drebrez as second maintainer.
Overall it seems useful to have qemu-* in main/, especially because
it is now the device that is selected by default in pmbootstrap.
