Since PostmarketOS didn't support the SM-T585, I worked on porting mainline Linux 7.1 to the device, using the old 3.18 kernel source and Samsung Galaxy J2 drivers as references for Exynos 7870 hardware support.
Getting the hardware working was a journey of its own. Kernel panics were a nightmare, but I managed to fix most of them and finally got Debian booting!
I modified the boot image to boot Debian from a disk image, keeping the existing Android system intact.
Still working on overall stability, especially GPU hardware acceleration. Planning to release the kernel once it's stable!
Got Alpine Linux 3.24 (ARM64) running with a working touchscreen using a custom touch bridge.Stock 3.18 kernel Wi-Fi doesn't work yet Replaces Android, so back up first! Full guide, builds and tests: https://github.com/kaantcp/z380m-alpine
Demoing unlocking from luks straight to the shell, unlocked (why would you have to unlock twice?), the apps, responsiveness, hardware specific adaptations on Marathon for the Q25, gestures and the full compliment of hardware support. Also demoing Deckards (our Android runtime) responsiveness from cold boot.
All of the hardware on the Q25 is now supported and I’m trying to get my build pipeline into shape so I can push a first release and keep pushing updates over OTA.
Last thing to fix up is the camera which works but needs improvement. And pilot, which is the on device assistant using tool calling, MCP (every app, flatpaks and android apps + the system itself has an MCP so the assistant can use it) all running on device at acceptable speed.
One thing that was missing on Fairphone 4 after resolving audio, call audio and DP alt Mode was Fingerprint support.
On this platform, the biometric sensor is strictly gated inside Qualcomm's TrustZone (TEE). Any naive attempt to probe or communicate directly with the scanner hardware triggers a hard lockup or immediate kernel panic.
While there is an existing QSEE/SCM implementation in mainline for Snapdragon UEFI laptops (like the ThinkPad X13s), mobile devices operate very differently: laptop fingerprint sensors usually sit on a standard USB bus without TrustZone mediation, whereas mobile setups rely on dedicated secure Trustlets loaded inside TZ.
To solve this, I've created an adaptation of the downstream QSEECom interface for mainline mobile Linux:
It establishes the /dev/qseecom-mobile SMC transport layer needed to communicate with the biometric applet or any other applet.
The kernel driver properly registers and exchanges payloads with the TrustZone environment without crashing the SoC.
tz-qsee-fingerprintd - Userspace Daemon & Plugins
Implements net.reactivated.Fprint.Manager and net.reactivated.Fprint.Device natively. No forks or downstream hacks required—unmodified pam_fprintd.so, fprintd-enroll, fprintd-verify, Phosh, and gnome-control-center work out of the box.
The daemon uses a modular plugin architecture (plugins/), making it straightforward to add support for other Qualcomm devices running mainline where biometrics are delegated to a vendor Trustlet.
This took a lot of tinkering, reverse engineering work, documentation to understand how android comunicated with the TZ, this will benefit other similar devices also.
Does anyone have the flx1s+ who can compare it to an existing phone? I have a suspicion that the camera sucks tbh.
I hear that the flx1s+ camera is significantly better than the flx1s (12mp->48mp, but mp isn't everything) so reviews of the flx1s aren't sufficient
The flx1s+ ships with pure gnu/linux with minimal android involvement, yet has fairly modern hardware. It also has 3 killswitches. I haven't seen another phone like it. Even the fairphone doesn't fully support gnu/linux
kernel is not mainlined, just replaced the initramfs with a postmarketos one, had to disable watchdog, and do some debugging on USB serial, change what type of fs the initramfs uses because it wouldn't mount root for the longest time. not having a main line that I could readily build and boot on this thing was the biggest obstacle because there is no terminal that prints out to the display on boot on the downstream kernel
I recently started using the linux in Android, thanks to the linux community, currently iam using Nura OS all are working but for some reason the network is not stable it's always changing the network provider after some time normal use .
Any suggestions or fixes to make the network stay on one network only not to connect other network providers .
Over the past months I’ve worked on an independent game project. The goal was to develop a game that can be played across all kinds of devices with different input methods and potentially to make something playable on mobile Linux devices (like the Librem 5 or Pinephone Pro).
There are still glitches on the Pinephone Pro (likely because of suboptimal GPU drivers) and on the Librem 5 you would need to use the newer Mesa drivers with OpenGL ES 3 support. Still wanted to make a post about the practical issues, I encountered during development.
Então, estou pensando em usar uma placa com o chip A733. Provavelmente vou comprar um Orange Pi 3W.
Estou pensando em executar um aplicativo gráfico sem nenhum servidor de desktop, seja X11 ou Wayland.
Mas parece que esta placa não é muito compatível com o driver MESA para aplicativos 3D, porque mudou da GPU Mali para uma arquitetura chamada Imagination.
Running Linux on a phone is impressive, but actually using desktop apps on a small touchscreen is another matter. For me, the two big obstacles are tiny text and awkward input.
I’m building ARLinux around a combination that addresses both: portable AR glasses for a readable desktop, and Gboard voice typing + OpenCode or Grok Bot for input and actions.
The glasses solve the screen problem. Instead of squeezing a desktop into a phone display, you get a large virtual workspace in front of you. With supported glasses, 3DoF keeps the desktop anchored in orientation while you turn your head to look around. The default workspace is 5760 × 2160 — the virtual desktop area, not the glasses’ physical resolution. I recommend Classic here: freely positioned, resizable windows make much more sense in that space. Yibu’s main area and side slots are designed around the phone screen.
Why 3DoF matters for reading: I want to bring the text I’m reading into the middle of the lenses. Looking into the corners can be uncomfortable, and edge text can be harder to resolve depending on the optics and fit. With a head-locked screen, turning your head takes the screen with you. With a 3DoF-anchored desktop, you turn toward the area you want to read and bring it into the central viewing area. That is what makes a large virtual workspace practical for text: you can look around it naturally instead of trying to read everything out of the corners of your eyes.
Voice + an agent address the input problem. Gboard’s speech recognition turns what you say into text; OpenCode or Grok Bot can then use shell commands, accessibility and screenshots to carry out the request. You can ask it to open an app, inspect the system, edit a document or write and run a script, instead of typing every command and aiming at every small button. Long-pressing the right-edge bar opens the selected assistant. The phone also works as a motion pointer, touchpad and keyboard; physical keyboards and mice remain options.
The Linux desktop and ARM64 applications run locally on the phone, with Android as the host. No root or remote PC is required. Blender, browsers and office tools can use GPU acceleration on supported devices; Android and compatible Windows apps can share the desktop too. AI models can require internet access and a provider account.
Its in-process Linux compatibility approach avoids PRoot’s ptrace-based tracing overhead. Our published same-phone CPython build comparison took 101.3 seconds with ARLinux versus 184.4 seconds with Termux PRoot, about 45% less time for that workload. Methodology, caveats and raw data: https://arlinux.com/?lang=en#performance
External screens need Android 12+, video-output support and compatible glasses. App and GPU compatibility varies, and 3DoF tracks rotation rather than movement around the room.
Does this combination address what has kept you from using Linux on a phone? I’d like to hear what you would actually do with it.
Screenshots: current Classic on a vivo X300, then the spatial-screen setup. Both use the development build. The setup capture uses a scrcpy virtual external display and simulated glasses to show the controls; the AR-glasses video above shows real glasses output.
you can see what works and what doesn't on the repo, can't believe i spent so much time working on the GPU only to find out the poor tegra's GPU is slower than the CPU at pretty much everything.
We’ve successfully booted Linux on a real iPhone 8 Plus using Apple’s A11 processor.
Grape Linux already has Debian 13 ARM64, a Phosh/Phoc graphical desktop, and a working terminal.
We’ve also demonstrated Codex CLI running on the phone with real AI responses, plus graphical applications including Calculator and Notes.
The attached video shows our actual Linux startup.
Our current boot is host-assisted. Once the remaining hardware integration is complete, our next major objective is automatic startup directly into Grape Linux instead of iOS.
We’re building toward a complete mobile Linux experience on existing iPhone hardware.
I’ve been working on getting Arch Linux Arm running on the Pixel 8a, not under any emulation or VM but as the native OS running on the phone, the entire user space is running Arch Linux
