u/Time-Ad-2504

Image 1 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
Image 2 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
Image 3 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
Image 4 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
Image 5 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
Image 6 — I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol
▲ 23 r/termux

I built and modded Termux:X11 entirely on my phone using Termux… and somehow added a working FPS limiter lol

I still can’t believe I actually got this working.

I built and modded Termux:X11 entirely on my Android phone using Termux. No PC. Just Termux, Android build tools, a lot of trial and error, and help from ChatGPT when I got stuck.

The mod I added is a custom FPS limit option under the Output settings.

0 = auto / default refresh rate

1–600 = custom FPS value

The crazy part is that it actually works.

If I set it to something super low like 3 FPS, the whole X11 desktop becomes painfully choppy. If I set it to 30, it feels capped. If I set it to 60, it feels normal. If I set it to 90, XFCE/terminal reports 90Hz inside the session and it feels smoother, even though my phone display is still physically 60Hz.

Just to be clear: this is not overclocking the phone screen. My panel is still 60Hz. This is more like changing the internal framerate/pacing value that Termux:X11 reports and uses inside the X11 session.

The technical part:

Termux:X11 already had a Java path where it detects the Android display refresh rate and sends it to native code through:

sendWindowChange(width, height, framerate, name)

Originally, that framerate value came from Android’s detected display refresh rate.

I added an FPS limit preference in the Output settings, saved the value in SharedPreferences, parsed it safely, clamped it between 0 and 600, then used it to override the framerate before calling sendWindowChange.

So the logic is basically:

- 0 = use Android’s detected refresh rate

- 1–600 = force that value as the X11 framerate

- pass it into the existing native framerate path

The native side already uses that value for root_framerate / blank_interval, so it is not just a fake UI option. That’s why setting it to 3 FPS actually makes the desktop lag hard.

The build process was honestly painful. I had to deal with Java 17, Termux-native aapt2, AIDL problems, CMake/NDK issues on Android, APK signing, native lib mismatch, libXlorie.so replacement, and Android complaining about compressed native libraries.

Eventually I got it working by building the patched Java/resource side in Termux, making sure the correct official libXlorie.so was inside the APK as a stored native library, then signing the final APK.

This is definitely experimental and not upstream-ready, but I’m honestly proud of it. I don’t have a formal IT/programming background, so seeing this actually work inside XFCE on Termux:X11 feels insane.

u/Time-Ad-2504 — 3 days ago
▲ 42 r/termux

Proot

Damn, I actually managed to compile a custom Mesa/Freedreno KGSL driver from source with help of ChatGPT for my Arch proot + Termux-X11 setup 😂😂

After checking the renderer, it shows FD610 / freedreno instead of Zink. EGL also reports the driver as kgsl, and XFCE detects the GPU as FD610

This means OpenGL is running through the native Freedreno path instead of going through Zink as an OpenGL-on-Vulkan translation layer.

Still testing stability, but seeing FD610 show up directly after building and wiring the driver manually feels insane. 🔥

u/Time-Ad-2504 — 13 days ago