None of the substantive code was written by AI.

I used AI to help with the mechanical parts of porting (e.g. translating autotools to CMake, replacing ioctl calls with tcgetwinsize, translating the C structs into Rust), as well as to write some of the smoke tests (e.g. cairo-test, mesa-test).

Where Claude really shines though is in reviewing your own commits. You give it a hash, and it tells you about the silly memory leak or deadlock that you left in, before you can make a fool of yourself.

Faith Ekstrand's write-up on Kraid, the new shader compiler for the open source Panfrost/PanVK drivers:

https://www.collabora.com/news-and-blog/news-and-events/panfrost-is-now-using-kraid.html

Starting with Mesa 27.0, all Mali GPUs with Valhall (v9) or newer will use it by default. Mesa 26.3 is the last release with the old compiler.

Highlights compared with the old compiler:

- ~18-20% fewer shader instructions across OpenGL and Vulkan shader sets

- Over 80% less register spilling

- Proper 64-bit integer support

- Much faster shader compilation with lower memory use

It went from start to default in under six months!

Saw this post on Bluesky and having had casually followed the trashing of X for about 20 years, the whole Canonical/Mir fiasco, and finally the extremely slow adoption of Wayland, this was cool to see! 😁

👀💃

Hey everyone,

I'm developing Linux Subsystem on Android (LSA), an experimental project that runs a native Linux userspace on rooted Android devices while keeping Android as the host operating system.

The goal isn't just to run a Linux desktop. I'm trying to make Android's hardware and services usable through normal Linux interfaces, without requiring applications to be rewritten for Android.

LSA uses the Android kernel directly. It's not PRoot, emulation, or a VM.

What's currently working in development testing on a Blackview N6000:

Debian ARM64 with a graphical desktop and native Linux applications

Hardware-accelerated OpenGL through Mesa/VirGL and Android's GPU stack

Audio playback and microphone capture

USB storage integration, including automatic NTFS mounting

Applications including Firefox, OpenArena, and SuperTuxKart

This is still pre-alpha. Some applications require workarounds, graphics compatibility is incomplete, and hardware support varies. Some of the results above are from a private development preview and may not be present in the current public release.

I'm looking for people who have spare rooted Android phones and are willing to help test LSA on different hardware.

Useful experience includes Android rooting, ADB, Linux debugging, shell scripting, Mesa/VirGL, graphics drivers, audio, and embedded Linux. You don't need to be an expert.

There are two ways to help:

Independent testing: Try LSA on a spare device, collect logs, report bugs, and share hardware compatibility results. No remote access required.

Direct development collaboration: For volunteers who want more involved help, I'm open to supervised SSH debugging on a dedicated test device. Any access would be optional, explicitly authorized, and governed by a written agreement restricting my activity to the agreed testing and development work.

Please don't run this on your primary phone or anything you can't recover. This is experimental rooted system software, and things can break.

GitHub: https://github.com/Phsphorus/LinuxSubsystemOnAndroid

If you're interested, let me know your phone model, chipset, Android version, and rooting method.

I'm also looking for feedback from people familiar with Linux systems programming or Android internals.

Thanks!

Disclaimer:

This project has been developed with the assistance of AI. I'm not an expert in every field this project covers, and I don't claim to be. LSA is an experimental learning project, and I welcome technical feedback, corrections, and contributions.

A dream can only be achieved if you try.

---

Example of the experimental UI.

I wanted to share a project that's been making some interesting progress in PC-based home theatre.

CroqueMr (u/Croque_Mr) is developing native Dolby Vision support for Kodi through a custom LibreELEC build, including Profile 7 FEL reconstruction. Development has moved quickly, with regular releases bringing performance improvements, new rendering modes and broader hardware support.

What's currently available?

• Native Dolby Vision playback, including Profile 7 FEL reconstruction.
• Intel and AMD support, with NVIDIA support also being developed.
• Dolby Vision rendering modes, including Master Reference and Adaptive HDR Mapping.
• Dolby Vision-to-HDR10 conversion and experimental AI-assisted HDR10-to-Dolby Vision conversion.
• Blu-ray 3D support on compatible AMD hardware.
• Performance optimisations targeting lower-power mini PCs, including Intel N100/N150 systems.

The latest Beta 5 release includes further improvements to playback stability, FEL handling, scaling and display detection. Results and compatibility can vary depending on the hardware, TV, source material and rendering mode.

What's coming next?

The developer has outlined plans for a GPLv2-or-later licensing rebuild, further AMD improvements, HDR10+ support and Dolby Vision-to-HDR10+ metadata reinterpretation, alongside expanded compatibility with older Intel graphics and additional NVIDIA hardware.

The longer-term goal is to make PC-based Dolby Vision playback more capable and accessible, including on affordable mini PCs.

Project links

• Main development thread: https://forum.libreelec.tv/thread/30362-dolby-vision-w-fel-3d-for-pc-amd-intel-nvidia/
• GitHub — source code and releases: https://github.com/CroqueMr/libreelec-x86-DV/
• Original Reddit thread: https://www.reddit.com/r/libreeLEC/comments/1wq20eu/wip_native_dolby_vision_support_on_x86_intel_cpu/

Full credit to u/Croque_Mr for the development, along with the community members contributing testing, feedback and improvements.

It's been impressive to see how much the project has evolved in such a short time. If you're interested in the technical details, supported hardware or latest builds, the links above have all the information.

Flatpak needs bubblewrap, bubblewrap needs user namespaces, and Android kernels ship without them. So flatpak run can't work on a phone, root or not.

In Tessera (GPL-3.0, an Android app that runs Linux desktop apps as native Android windows), flatpak still downloads, but Tessera builds each app's root itself:

- the runtime at /usr and the app at /app, read-only;

- the runtime's GL extension where the runtime expects it, on a tmpfs over its parent since the folder doesn't exist in the read-only runtime;

- /etc from the runtime, with passwd, group, hosts and resolv.conf written for the session;

- the session's X11 directory shared, carrying its D-Bus and PulseAudio sockets, so the app gets the same bus, sound and theme portal as the Debian side.

Without root that's PRoot's path translation. With root, each launch gets a private mount namespace, an unprivileged uid and no_new_privs, so per-app permissions are kernel-enforced.

The rest is about making Linux apps feel native on a phone: each app (and each of its windows) gets its own Android task and Recents card; GTK, libadwaita and Qt take Material You colors and follow dark mode live through a settings portal Tessera serves; apps rescale live from a slider; and the Android keyboard opens on text fields by listening to AT-SPI focus events. GPU acceleration is a bundled Mesa with Turnip and Zink for Adreno, which also loads inside Flathub runtimes.

Source: https://github.com/daryan044/tessera-linux

Note: AI WAS USED IN THE PROCCESS OF CREATING THIS APP

Happy to go deeper on any part.

Original guide for Arch. Worked for a colleague on a different distro.

You can find two proprietary driver versions on the Lenovo website. One is the "Linux version" which requires OpenSSL 1.1 and the other is the "Ubuntu version" which requires OpenSSL 3. Both are .so libraries that work on any distro if the requirements are satisfied. Use the second one.

Depending on your distro, you also need to choose one way to obtain the libfprint-2-tod.so.1 library. Alternatively, you can build it from this source using meson/ninja.

Necessary udev rules:

SUBSYSTEM=="usb", ATTRS{idVendor}=="04f3", ATTRS{idProduct}=="0c4b", ATTRS{dev}=="*", TEST=="power/control", ATTR{power/control}="auto", MODE="0660", GROUP="plugdev"
SUBSYSTEM=="usb", ATTRS{idVendor}=="04f3", ATTRS{idProduct}=="0c4b", ENV{LIBFPRINT_DRIVER}="Elan Fingerprint Sensor"

this goes to /etc/udev/rules.d/60-libfprint-2-tod1-elan.rules.

After installing and restarting the services (or rebooting), you can use any usual ways to enroll fingerprint.

Just wanted to post this so that people with similar issues see.

Hi all, AdobeWine 0.3.1 is out. It's a patched Wine (11.18 plus 90 patches) that runs Adobe's Creative Cloud apps on Linux. You install the apps yourself with Adobe's own Creative Cloud installer and your own subscription; nothing from Adobe is bundled or downloaded by the project.

This time there's a video: a short showreel made entirely in the Adobe apps on Linux, from a pen-pressure painting in Photoshop to the cut in Premiere and the export in Media Encoder:

https://youtu.be/3Vbzt4cGSQQ

(To be upfront: the pen strokes come from a simulated tablet and most steps were scripted. The point is that the apps themselves run, draw and render correctly.)

What works right now (tested on an RTX 4070 laptop, with community reports on RTX 4060, RTX 4090 and Intel UHD 620):

• Creative Cloud desktop: sign in, install/update/open apps, Fonts, Files; its own self-update completes
• Photoshop: layers, masks, type, filters, Remove Background, Generative Fill, export. All 75 filters and adjustments I tested give the same output as on Windows. Pen pressure works
• Illustrator: shapes, pen, type, effects, Pathfinder, Image Trace, save/export, Blob Brush with pen pressure. 107 of 139 reference outputs match Windows (the rest not compared yet)
• Premiere Pro: import, timeline editing, Lumetri, titles, playback, NVENC export, Dynamic Link with After Effects
• Media Encoder: queue, presets, CUDA renderer, NVENC/NVDEC
• Audition: recording, multitrack, effects, noise reduction, mixdown
• After Effects: scripting, keyframes, 3D text with the Cinema 4D renderer, the composition viewer with CUDA; a real 300-layer project renders like on Windows
• InDesign: styles, tables, placing PSD and AI files, PDF export
• Pen tablets with pressure under XWayland, no extra software

Not there yet: AMD isn't confirmed (a Premiere fix is waiting for someone to test it), AMD and Intel GPUs don't get the CUDA features, After Effects can eat a lot of RAM while previewing heavy 3D comps, and Bridge is barely tested.

It's free, open source and non-profit.

A word on AI, since it always comes up: AI slop is bad, the same way anything pre-produced and left unfinished looks bad. People who produce slop are, in fact, sloppy: they don't care to finish and finalize their ideas. This project is a construction, ongoing, and it needs the community. Even though it was done almost entirely with AI, it's driven by a human, and it's meant to help other people in their lives.

So if you use Adobe and Linux (or would like to), please try it and tell me what breaks, especially on AMD and Intel GPUs, other distros and your real workflows. Issues and PRs are welcome, and so are plain "it worked for me" reports.

GitHub: https://github.com/le-birnes/AdobeWine (install guide in docs/INSTALL.md)

I understand the need for controlling the onslaught of low effort projects, but surely declaring that you are English only goes against the site's rules?

just because it's a lingua franca doesn't mean it's superior. Users should be allowed to share their opensource contributions with the Reddit community in the language of their choice.

In June I put Arch on my old Portégé Z30-A (it ran Mint before) and none of the Fn keys or the lid switch worked. After some testing (with a lot of help from Claude) I narrowed it to the kernel, and switching to LTS fixed it. I meant to report it back then but never did.

Today, after an update, the exact same problem came back, this time on LTS, while mainline works again.

Details:

• Hardware: Toshiba Portégé Z30-A
• Distro: Arch
• Broken: LTS 6.18.57; Working: mainline 7.2.9
• Suspected commit (ACPI-related): 30e08c92118c identified with Claude’s help, not yet confirmed by me with a revert/bisect

My guess is that the problem was fixed in mainline but the fix hasn’t been backported to LTS, it looks to be a004b8f0d3bc. I’m only a 2nd-year CE student and also using Linux for only one year, so this is totally out of my league. Does that sound plausible, and is it worth sending to the stable/ACPI maintainers? I’ll put Claude’s full analysis in the comments for anyone who wants to check it.