Currently, every LCDs inside their (our users) pocket are driving 3.3V,
meanwhile the LCD interface is meant to drive at ~2V.
This turns our LCDs into a timebomb that is ready to trigger at any moment,
killing the display.
Signed-off-by: Danct12 <danct12@disroot.org>
- Update to Linux 5.6-rc2
- Major improvements for Motorola Moto G4 Play (motorola-harpia)
- Display
- Touchscreen
- Accelerometer
- Audio
- Modem
- Vibrator
- Fix headphones/headset detection for wileyfox-crackling
- Add mount-matrix for samsung-a3ulte/a5ulte to fix
orientation detection with iio-sensor-proxy
- A lot of cleanup everywhere
- APKBUILD: Clean up makedepends (a lot of them are unneeded)
wileyfox-crackling was the only user of QCDT. Now that it is also
using appended DTBs, there is no need to generate the QCDT image anymore.
Another advantage of this is that mainline can then be only booted using lk2nd
(as intended), since booting it from the stock bootloader has weird side effects
(e.g. no WiFi/BT MAC address set).
That path works just as well as documented at
https://doc.qt.io/qt-5/qstandardpaths.html (GenericConfigLocation) and
it doesn't depend on the user being created after the package has been
installed.
polkit rely on systemd, so we don't get correctly working setup.
This impact non-working backlight control from userspace and other
stuff.
Signed-off-by: David Heidelberg <david@ixit.cz>
At the moment we store the same initramfs-extra twice on the file system:
- /boot/initramfs-<flavor>-extra
- /var/cache/postmarketos-mkinitfs/initramfs-<flavor>-extra_<hash>
The second copy is exactly the same file, just with the <hash> (for caching)
appended to the filename.
We can avoid this by appending the hash directly to the filename
on the boot partition, i.e.
- /boot/initramfs-<flavor>-extra_<hash>
This is possible because we only reference initramfs-extra from the main
initramfs, and we already replace the path in it dynamically.
It will just let the main initramfs load -extra_<hash> instead of just -extra.
This saves a few megabytes of disk space on the rootfs.
postmarketos-ui-sway already depends on xorg-server-xwayland for
X clients. There is no need to pull in the entire X server including
all necessary drivers.
This saves ~84 MiB of disk space when installing postmarketos-ui-sway
on asus-me176c. X applications are still working fine through Xwayland.
Also remove explicit dependency on dbus - it is already pulled in
by dependencies like lightdm or elogind and nothing in
postmarketos-ui-sway depends on it specifically.
We need to generate the splash screens separately for each device,
because they are specific to the device's display resolution.
At the moment we do this dynamically during the installation process.
This has the advantage that there is no need to re-build all device
packages when one of the splash screen is changed (or a new one is added).
In reality, however, the splash screens do not change very frequently.
On the other hand, generating the splash screens dynamically has signficant
disk usage overhead for a minimal ("none" UI) rootfs:
The Python interpreter together with the necessary libraries requires
about ~60 MB of disk space on aarch64.
The splash screens itself require about ~100 KB for 720x1280.
This is not necessary if we move the splash screen generation into
devicepkg-dev, which is used to build the device package for all devices.
Another advantage is that we no longer need the (rather complicated)
caching mechanism for splash screens - so we actually end up with less
lines than before.
rootfs size for samsung-a5ulte ("none" UI):
Before: 450M
After: 388M (-62M)
After this change, every(!) device package needs to be rebuilt once.
No changes are necessary in device packages.
Kernel subpackages may contain a "-" (e.g. -kernel-mainline-modem);
replace it with an underscore to make sure that we find the
kernel-specific variables in deviceinfo.
