This is a follow-up to my earlier posts:

https://lemmy.sdf.org/post/12809764 https://lemmy.sdf.org/post/19600671

We're Getting Closer.

It's just small stuff left that needs a bit of piecing together, though I've now been daily driving my port for the past two weeks already.

This Works

  • booting
  • display
  • touch
  • modem <- You might have to switch to the other slot if it does not work: mmcli -m 0 --set-primary-sim-slot=1, options are 1 or 2. Note that the modem could also be a different number, maybe try -m 1 if it is not found as the command will reboot the modem and then it changes.
  • plymouth
  • battery/charging
  • mobile data
  • wifi
  • torch
  • suspend
  • call audio
  • vibration
  • Bluetooth™
  • full disk encryption
  • eSIM (I'm working on the packaging for the tool you need to provision it)
  • SMS
  • audio (ALSA config not packaged, but can be added manually)
  • camera (have taken a few photos, but the kernel driver is still work in progress and sometimes it just does not work)

This Has An Unknown Status

  • Fingerprint Sensor
  • NFC (should work, does so on pmOS)

This Does Not Work Yet (Soon™)

  • GPS
  • USB host mode (no Kernel support yet, but apparently this is being worked on)
  • Verified Boot (first need to do research whether this is actually feasible)

This Is Missing And Will Come Later

  • accelerometer
  • magnetometer
  • ambient light sensor
  • barometer

Project Status

To Do List

  • Make installer images work on this device
  • Have droid-juicer run on installer images
  • Get into the repos: tinyalsa and q6voiced (I've already packaged both)
    • ITP for Tinyalsa: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079473
    • ITP for q6voiced: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080483
  • Combine SDM670 kernel patches with those in the Mobian qcom kernel
Done List
  • New release of qcom-phone-utils required so that my patches are available from the repo
    • https://salsa.debian.org/DebianOnMobile-team/qcom-phone-utils/-/commit/4f77281197c6ba1cfc1a82596157d00e8a7e014b (firmware folders)
    • https://salsa.debian.org/DebianOnMobile-team/qcom-phone-utils/-/commit/9aa29a1d0bd2327e9c74317d516a8aeecf820304 (fixes bootimg generation with LUKS)
    • https://salsa.debian.org/DebianOnMobile-team/qcom-phone-utils/-/commit/3ddb192b5c78b444065f23647b373ad66ce3617d (fixes on-screen keyboard for LUKS passphrase)
  • Remove hard-coded value in the droid-juicer systemd unit
    • https://gitlab.com/mobian1/droid-juicer/-/issues/4
  • Make sure my q6voiced package no longer includes a hard-coded config for this device (known solution, need to implement)
  • add udev rule for the vibration motor to the right package
    • https://salsa.debian.org/Mobian-team/devices/kernels/qcom-linux/-/issues/3
    • upstream: https://source.puri.sm/Librem5/feedbackd/-/merge_requests/139

Misc Issues

  • ALSA config for the device has not been upstreamed yet
  • Issues with 5 GHz wifi
    • Can be worked around by forcing the phone to only use the 2.4 GHz band, for example using nmtui, the network settings of GNOME/Phosh are bit too simplistic for that
  • No idea how to get the call audio on Bluetooth, meaning you will have to hold the phone or use a cable, for now

(This is a non-exhaustive list)

Low Priority

  • create/find script/tool that brings up Bluetooth & then package it
    • https://salsa.debian.org/Mobian-team/devices/kernels/qcom-linux/-/issues/5

Other than that... Everything should be there. It's definitely usable already.

Just a few smaller quirks to iron out and two packages to get into the repo.

The Sources (Use The Source, Luke)

  • My efforts of packaging a device-specific kernel: https://salsa.debian.org/erebion/sdm-670-linux (which will be used until all patches are part of upstream Linux and we can finally use a regular mainline kernel)
  • mobian-recipes, which is used to build images: https://salsa.debian.org/Mobian-team/mobian-recipes
  • droid-juicer, which retrieves some important files from some partitions: https://gitlab.com/mobian1/droid-juicer
  • https://wiki.postmarketos.org (lovely folks, thanks for sharing everything you found out the hard way :D)

Thanks For All The Fish

Huge thanks to be sdm670-linux project and flamingradian who runs the project (just one person!) to make sure the Kernel works on those devices! :)

I don’t know how Kernel development works, so I would have never started porting without this project.

Find that here: https://gitlab.com/sdm670-mainline/linux

Questions Accepted / Ask Me Anything About The Project

I will gladly answer all questions, I hope that more people will start porting if it becomes clear that this is not arcane magic. It’s mostly just arcane. And a community of friendly people that try to be helpful.#

  • erebion@lemmy.sdf.org
    hexagon
    ·
    2 months ago

    No idea, but you could of course install Waydroid on Mobian. I hope Android Translation Layer (https://gitlab.com/android_translation_layer) will at some point get to a state where it is usable as the superior Waydroid alternative for many people.

    • Altomes@lemm.ee
      ·
      2 months ago

      Thanks for the tip, good looking out, the main need for X isn't android for me but instead VOLTE

      • erebion@lemmy.sdf.org
        hexagon
        ·
        2 months ago

        It is to Android apps what WINE is to Windows programs, while Waydroid is to Android apps what something between Docker and a VM would be to server software.

        Actually, Waydroid is not too dissimilar from running, for example, an Ubuntu Desktop system in a Docker container on a Debian desktop system, just so you can use snap packages... Instead of installing snapd on Debian. (Not that I want snapd.)

        Waydroid is more like an Android container appliance that runs a full Android system, while ATL, as the name Android Translation Layer suggests, translates functions and API calls, used by Android apps, into the appropriate methods of doing things on a regular GNU/Linux system (in contrast to an Android Runtime/Linux system), thereby being much more efficient, more comfortable to use and having the potential of integrating into the system really well.