arlinux-rootfs

Portable AR glasses make mobile Linux useful — voice + AI handle the input 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. A big thank-you to the tawc project and its contributors for tawcroot: wmww/tawc 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: arlinux.com 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. AR glasses demo: youtu.be Grok Bot desktop demo: youtu.be Project and download: arlinux.com Setup and controls: arlinux.com Linux distribution sources: taowen/arlinux-rootfs 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. preview.redd.it preview.redd.it

Linux and Android apps sharing one desktop on an unrooted phone — ARLinux demo, built on tawcroot and libhybris What if you could keep stock Android, but use desktop Linux apps and Android apps in the same multi-window workspace? I'm the developer of ARLinux. Here's a real-phone demo followed by an animated explanation of the runtime and graphics stack: youtube.com The first 1:47 shows the practical side: Android apps in windows, Debian desktop software, touchpad-style controls and voice input. The technical explanation starts after that; tawcroot is covered at 5:25 and the GPU path at 6:14. This is not a ROM, a remote desktop, or an ARM CPU emulator. Android stays running. ARM64 Linux programs execute on the phone's CPU, while tawcroot translates the system calls that need a different filesystem view. For graphics, Mesa Zink translates OpenGL to Vulkan; supported Snapdragon devices use Turnip, and our libhybris integration can use the phone's Android Vulkan driver on other tested devices. GPU presentation uses Android hardware buffers. Credit where it's due: this builds on wmww's tawc/tawcroot, upstream libhybris, Mesa, and the compositor projects—not a runtime or driver stack we invented from scratch. We've published our compatibility work: • tawc/tawcroot fork: taowen/tawc — guest signal and exec lifecycle fixes, plus application compatibility work. • libhybris fork: github.com/taowen/libhybris/tree/arlinux — Android linker namespaces, Vulkan compatibility and presentation fixes. • Distribution build framework: taowen/arlinux-rootfs — build your own Debian, Arch, LXQt or Omarchy-based workspace. The latest APK includes Yibu, a Debian-based layout with one main task and three live side slots; other desktops can be imported separately. The Linux framework, distribution configs and these forks are open source. The ARLinux Android host is closed source. Download and guide: arlinux.com A few important limits: this doesn't replace Android with a mainline Linux OS, not every Android or Linux app works, and GPU support depends on the device/driver. The Linux guest is not a security boundary between its programs; compatibility behavior must not be mistaken for working application sandbox isolation. We've been testing desktop apps such as LibreOffice, Blender, GIMP and Chromium on Redmi and MediaTek hardware. I'd be interested in which real workflow people here would want tested next, and whether the open runtime/graphics changes are useful to other mobile Linux projects.