- re-enable console suspend, which seems to be broken with elogind when
suspending (kernel gets hung up indefinitely in vt_waitactive)
- add a suspend hook to work around the musb driver not allowing the
device to suspend
Based on my testing, this option seems to prevent suspending via
elogind (using `loginctl suspend`). When console suspend is disabled,
the kernel gets hung up in the call to vt_waitactive, and elogind times
out trying to suspend.
On some downstream kernels it seems like we need to explicitly keep
/dev/subsys_modem open (without writing anything), otherwise the modem
will be stopped (or never started). Weird.
The -s switch to automatically start/stop the modem remoteproc only
works on mainline, on downstream it fails with "Failed to get rprocfd".
Let's abuse /usr/lib/preload/libqipcrtr4msmipc.so to check if we are
(probably) running on a downstream installation, and omit the -s
argument in this case. The modem remoteproc needs to be started
differently on downstream.
qrtr-ns is not needed (or working) on downstream, also it is no longer
needed for mainline starting with Linux 5.9. Convert the "need" dependency
to a "use" so qrtr-ns is only started if it is really needed.
In most cases, the qrtr-ns is not needed anymore now, but we still
need the libqrtr library. Separate that out into a separate package
so it can be installed independently.
qrtr-ns is now part of the Linux kernel (as of version 5.9), so
there is no need to start it in userspace anymore. It does not seem
to be needed (or working) on downstream either.
linux-postmarketos-qcom-msm8996 is the only mainline kernel which
is still on < 5.9. In preparation to make the qrtr dependency optional
for rmtfs, let's explicitly enable qrtr-ns for MSM8996 devices to avoid
causing regressions.
For some reason, the ModemManager build tends to freeze when built
with QEMU user emulation for arm*. Changing the build to use a single
thread only (-j1) avoids that, although the build is slower of course.
Also limit building to "armhf armv7 aarch64" since the forks are not
needed on any other architectures, to reduce build times a bit. The
other architectures can just use the upstream packages from Alpine.
This allows to connect the modem to the Internet with oFono.
I have verified that this does not break anything if the "rmnet0"
network interface is missing. Plus, all mainline devices currently
covered by the package should also be able to use the new "BAM DMUX"
network driver that is used as network interface to the modem.
(Note: This works differently on newer SoCs, but they also need
something different in oFono...)
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate
with the modem through shared memory. On mainline kernels these
shared memory channels are exposed through the RPMSG subsystem.
This is different from communication through USB or serial interfaces
that are currently supported by ModemManager.
This commit forks the "modemmanager" package from Alpine and adds
a patch that allows ModemManager to talk to modems through the RPMSG
subsystem.
Working functionality: Calls, SMS, Mobile Data
The same patch has also been submitted upstream:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
So far we have only created /dev/modem based on the DATA5_CNTL
channel available from the modem. The DATAX_CNTL channels allow
sending QMI messages to the modem. This is sufficient for oFono
to work.
Unfortunately, ModemManager currently does not support starting
calls through the QMI interface. Instead, it uses serial AT commands
that can be alternatively used on all USB-based Qualcomm modems.
It turns out that we can also send serial AT commands through
the RPMSG interface: the DATAX channels (without _CNTL) all respond
to serial AT commands. We set it up at /dev/modem-at, configure
ModemManager accordingly and then we are able to start calls. Yay!
For some reason, the ModemManager build tends to freeze when built
with QEMU user emulation for arm*. Changing the build to use a single
thread only (-j1) avoids that, although the build is slower of course.
The same thing seems to happen fo oFono as well, so set that to -j1 too.
Also limit building to "armhf armv7 aarch64" since the forks are not
needed on any other architectures, to reduce build times a bit. The
other architectures can just use the upstream packages from Alpine.
Update to kernel 5.9 with the following changes:
* Change tri-state key to macro keys instead of 'A', 'B' and 'C' keys.
[ci:skip-build]: already built successfully in CI
Switch from the 5.8.x kernel with allwinner specific patches to megi's
5.9 based tree. He drives the PinePhone related kernel development
forward like no other, his tree and changes are well documented on
xnux.eu, and he frequently publishes tested "build this one" commits with
the latest improvements. It makes a faster and less time consuming
workflow to simply package these versions (after a smoke test) into
postmarketOS edge, and after some time to catch possible regressions
ship the same version in postmarketOS stable.
This kernel should make HDMI work for most people, and improve call
quality (thanks to smaeul's patches, which are integrated into megi's
tree).
Kernel config changes:
* Enable MODEM_POWER in the kernel config, among other improvements this
allows us to get rid of the 30s delay on power off.
* Enable CONFIG_DRM_PANEL_ILITEK_ILI9881C (new PineTab panel)
* Enable CONFIG_ZRAM
* Enable CONFIG_HID_MULTITOUCH
Related: https://xnux.eu/devices/feature/modem-pp.html#toc-modem-power-driver
Changelog: https://megous.com/git/linux/tag/?h=orange-pi-5.9-20201019-1553
Co-Authored-By: Martijn Braam <martijn@brixit.nl>
Co-Authored-By: Clayton Craft <clayton@craftyguy.net>
Initial support for Sony Xperia XA (codename: sony-tuba). Builds, can be
flashed, ssh connection through usb works, display works, touchscreen works,
no wifi or anything else.
According to the wiki pages, some interfaces can't be built for the
armhf architecture. This device is configured to armhf but it actually
supports armv7 architecture. Tested with a samsung-i9300.
This adds emoji support to the squeekboard emoji picker, and to any apps
that might want to display emojis (chatty, firefox, text editor, etc)
Thanks @vurpo for the tip.
We have tried out lightdm-mobile-greeter for three weeks, but let's remove
it again from the default install.
The greeter behaves completely different from the Phosh (or any other
UI's) lockscreen, therefore it provides a bad user experience. Not only
the design is different, but it also can't display the same information
as the Phosh lockscreen. You can't accept a call coming in while the
greeter is displayed, and whatever other features will be added to the
lockscreen in the future would not be in the greeter (e.g. making a photo
without logging in, emergency calls without login, ...).
It's clear to me now, that postmarketOS in the default installation
should install one UI in single-user mode, and that UI should use its
lockscreen to display all login screens. The case of having multiple UIs
installed at the same time is used rarely, so instead of optimizing for
it, document how to enable a greeter after the installation in the wiki:
https://wiki.postmarketos.org/wiki/Configure_postmarketOS_for_multiple_UIs_or_users
Besides the strong reasons above to ship with no greeter at all, we had
problems with lightdm-mobile-greeter in particular:
* It did not work with Plasma Mobile
* When HDMI was plugged in, the greeter was not usable (especially
annoying, because Phosh tends to crash after plugging in HDMI, so it
would go back to the greeter which then means you need to reboot)
This reverts commit be693339ec.
This new version:
- Upgrades device config from upstream to v25
- Fixes a problem using modesetting driver on Xorg (lightdm
was broken because it now uses Xorg)
- Override GDK to use GLES (change from upstream Purism)
