use termux:X11 with custom chroot environment

[zanfix]

Hi all,

Question: can termux:X11 app be used with a chroot environment (using official debian repos) instead of a termux environment, eventually with some tweaking here and there?
I am already able to use Xwayland with sparkle app
I have a rooted device...

Bye

[twaik]

https://github.com/termux/termux-x11/issues/40#issuecomment-931018747

[zanfix]

What I ment is that at the moment I use an image file (ext4) bootstapped from debian repos.
I mount it and then chroot into it... So not using termux at all... I was wondering I can somehow use termux:X11 in this kind of setup... From what I am understanding a debian repo version of xwayland cannot be used since the one from termux has been patched to work with Lorie (your implementation of compositor?)...

[Heasterian]

I'm not sure about new one, but old versions of Termux-X11 where working fine with Xwayland versions from main sources, backported.

Try to use it first. Even if something will cause issues, you won't know untill you try.

[twaik]

your implementation of compositor?)...

It is not a compositor. It is a backend for Xwayland.

but old versions of Termux-X11 where working fine with Xwayland versions from main sources

Xwayland did not change. Version 1.20.5 still being used (1.20.13 is an actual version). It has a lot of patches but most of them fix pathes and disable using some capabilities that can not be used in Termux like dropping privilegies of process (setgid/setuid), glx (which can not be used directly), fbdev driver (requires root). But there is one that matter: patch fixing screen resize of Wayland compositor and making xserver use ashmem instead of SysV shared memory (link). Xwayland of chrooted environment is not pathced to use ashmem and that can be a problem. Also last versions of Lorie have special launching process so termux-x11 utility should be used to start it.
If you succeed starting Lorie and connecting Xwayland but still have problems there can be another reason: lots of GUI frameworks use shared memory fragments to speed up image displaying. That can be a root of problem. You can try to use android-shmem. You can try to rebuild Xwayland with the patch and android-shmem and then put libandroid-shmem to /etc/ld.so.preload file. That should fix almost all the bugs on Xwayland side.

[zanfix]

your implementation of compositor?)...

It is not a compositor. It is a backend for Xwayland.

but old versions of Termux-X11 where working fine with Xwayland versions from main sources

Xwayland did not change. Version 1.20.5 still being used (1.20.13 is an actual version). It has a lot of patches but most of them fix pathes and disable using some capabilities that can not be used in Termux like dropping privilegies of process (setgid/setuid), glx (which can not be used directly), fbdev driver (requires root). But there is one that matter: patch fixing screen resize of Wayland compositor and making xserver use ashmem instead of SysV shared memory (link). Xwayland of chrooted environment is not pathced to use ashmem and that can be a problem. Also last versions of Lorie have special launching process so termux-x11 utility should be used to start it. If you succeed starting Lorie and connecting Xwayland but still have problems there can be another reason: lots of GUI frameworks use shared memory fragments to speed up image displaying. That can be a root of problem. You can try to use android-shmem. You can try to rebuild Xwayland with the patch and android-shmem and then put libandroid-shmem to /etc/ld.so.preload file. That should fix almost all the bugs on Xwayland side.

My question is: ashmem is needed also between Lori and Xwayland, or only between Xwayland and GUI frameworks (or applications)? Because on my devices i compiled the kernel with SysV shared memory enabled and have root access. If it's the latter then I would say that only the "patch fixing screen resize of Wayland compositor" patch would be needed.

I if see correctly the hardcoded path to Xwayland in the Starter app (Starter java class) must be also changed to match the location in the chroot.

[twaik]

Ashmem is needed to avoid using temporary files and MMC/NAND resource consumption. If you can activate SysV shared memory it is unneded. Termux itself uses it's own mechanism emulating SysV shared memory based on sockets.

Starter app is needed to provide access to termux's directories to app with custom signature. You can put symlink/hardlink XDG_RUNTIME_DIR of the container to folder inside app's private storage and export (hardcode) XDG_RUNTIME_DIR before this line. This way you can avoid using java app to start Lorie.

Starting Lorie from inside chroot is a bit more complicated. Some devices do not allow to use am inside chroot. You should check if you can.

1. Configure and execute this script. msg can be changed to echo, $COMPONENT is optional, $CHROOT_DIR is path to your chroot. It is needed to create unchroot script with cached values of environment variables so it should be executed inside Android environment as root.
2. Run unchroot as root inside your chroot container. It should show you Android's root environment. (Something like chroot escaping, yeah.)
3. Try to start something

adb shell am start -n com.package.name/.ActivityName

In the case it works you can modify this source. It is created to start Lorie using termux's am (and return error in case of problems) but you can make it do all the stuff unchroot does and use Android's am instead termux's one.

Sorry for my bad English...

[twaik]

@zanfix did it work?

[zanfix]

@twaik, it works!!!

This is what I had to do:

• Compile the android app adding putenv("XDG_RUNTIME_DIR=/data/data/com.termux.x11/files/tmp"); as you said in compositor.cpp (i put it after line 44)
• set "mount namespace mode" option in Magisk to "global namespace mode"
• start the chroot
• start the android app (i am starting it manually at the moment)
• symlink the XDG_RUNTIME_DIR of the chroot environment in the android app folder in my case: ln -s /data/local/mnt/tmp /data/data/com.termux.x11/files/
• start Xwayland and i3

Initially it would not work. I checked if termux:x11 was creating the socket, it did, but the socket permissions were too restricted:

$ ls -l  /data/data/com.termux.x11/files/tmp/
total 4
srwx------ 1 u0_a282 u0_a282    0 2022-01-24 20:50 wayland-0
-rw------- 1 u0_a282 u0_a282    0 2022-01-24 20:50 wayland-0.lock

so i chmod 777 /data/data/com.termux.x11/files/tmp/wayland-0 and then it worked!

$ ls -l  /data/data/com.termux.x11/files/tmp/
total 4
srwxrwxrwx 1 u0_a282 u0_a282    0 2022-01-24 20:50 wayland-0
-rw------- 1 u0_a282 u0_a282    0 2022-01-24 20:50 wayland-0.lock

I did not touch Xwayland, it the debian repos one unmodified

• Window resizing (of the android app) is working (so it looks like it does...)
• Xwayland glx extention is working (as in sparkle) and I can get "some" acceleration using the library from https://github.com/Grima04/mesa-turnip-kgsl

Seems good this far!
Thank you for your help!!!

[twaik]

Initially it would not work. I checked if termux:x11 was creating the socket, it did, but the socket permissions were too restricted

you can chmod it right after creating socket in wl_display_add_socket_auto.

chmod("/data/data/com.termux.x11/files/tmp/wayland-0.lock", 0777);

I did not touch Xwayland, it the debian repos one unmodified

Looks like it has outdated version, I'll check what I can do.

[zanfix]

you can chmod it right after creating socket in wl_display_add_socket_auto.

works, i put the call to chmod right after the call to wl_display_add_socket_auto in compositor.cpp, in void LorieCompositor::start() method

Looks like it has outdated version, I'll check what I can do.

Not sure what you mean... anyway xdpyinfo in reporting server version 1.20.11 (debian bullseye repo)

[zanfix]

Starting Lorie from inside chroot is a bit more complicated. Some devices do not allow to use am inside chroot

I am using another approach to automate the startup.
from android (shell scripts), after mounting all the required filesystems and before entering the chroot i do (simplified):

• start the android app
  monkey -p com.termux.x11 -c android.intent.category.LAUNCHER 1
• check that the wayland-0 socket is present, then bind mount the socket into chroot /tmp
  touch $CHROOT_MNTDIR/tmp/wayland-0
busybox mount -o bind ${TERMUX_X11_FILES_FOLDER}/tmp/wayland-0 $CHROOT_MNTDIR/tmp/wayland-0
• enter chroot, initialize stuff...
• start Xwayland
• ...

when shutting down, once out of the chroot, before unmounting the fileystems

• force close the android app (maybe there is another cleaner way to do it... i do not know)
  am force-stop com.termux.x11
• delete the bind mount, socket and lock files (for some reason termux:x11 does not delete the socket and lock file, event if shutdown cleaninly (using the exit button)
  rm $CHROOT_MNTDIR/tmp/wayland-0 && \
rm ${TERMUX_X11_FILES_FOLDER}/tmp/wayland-0 && \
rm ${TERMUX_X11_FILES_FOLDER}/tmp/wayland-0.lock

This approch allows:

• Starting the android app before and outside the chroot
• Using the "inherit namespace" variant of the Magisk configuration option "mount namespace mode"
• Shutdown the chroot without first closing the android app

The only problem I see is that to get Xwayland to work with termux:x11 once the chroot is already started, the socket file must be bind mounted (manually?) from outside the chroot (android side)

[Heasterian]

@zanfix If you would want to try upstream Mesa to have better Zink speed, you can compile it from my repo with same config used for Grima's https://github.com/Heasterian/mesa In practice it's same modification, but It's changing only two lines of code.

[zanfix]

@zanfix If you would want to try upstream Mesa to have better Zink speed, you can compile it from my repo with same config used for Grima's https://github.com/Heasterian/mesa In practice it's same modification, but It's changing only two lines of code.

Does it work for you? I had to setup a debian testing chroot to be able to compile it (libdrm-dev is outdated on bullseye) but then i get some msm drm related error messages...

[Heasterian]

Does it work for you? I had to setup a debian testing chroot to be able to compile it (libdrm-dev is outdated on bullseye) but then i get some msm drm related error messages...

I'm now running pure Mobian on my Poco F1 so I didn't tried it since some time as I don't need KGSL with mainline Linux kernel, but month ago one guy used it in Gentoo Prefix running next to Android and it was running fine.

[zanfix]

Does it work for you? I had to setup a debian testing chroot to be able to compile it (libdrm-dev is outdated on bullseye) but then i get some msm drm related error messages...

I'm now running pure Mobian on my Poco F1 so I didn't tried it since some time as I don't need KGSL with mainline Linux kernel, but month ago one guy used it in Gentoo Prefix running next to Android and it was running fine.

Is there some kind of doc on how to compile it correctly? i am using the following meson options (the same that work with Grimas's repo

meson build -D platforms=x11 -D gallium-drivers=swrast,virgl,zink -D vulkan-drivers=freedreno -D dri3=enabled  -D egl=enabled  -D gles2=enabled -D glvnd=true -D glx=dri  -D libunwind=disabled -D osmesa=true  -D shared-glapi=enabled -D microsoft-clc=disabled  -D valgrind=disabled --prefix /usr/local -D gles1=disabled -D freedreno-kgsl=true

[zanfix]

@zanfix If you would want to try upstream Mesa to have better Zink speed, you can compile it from my repo with same config used for Grima's https://github.com/Heasterian/mesa In practice it's same modification, but It's changing only two lines of code.

Are sure that you pointed me to the correct repo? It's maybe this one instead? https://github.com/Heasterian/mesa-turnip-kgsl

EDIT: ok wait... it's your repo... so i suppose you know that you are talking about ;-)

[Heasterian]

@zanfix Repo is correct, but I have same issues with Debian testing now in chroot (for now with Sparkle). Use MESA_LOADER_DRIVER_OVERRIDE=zink environment variable. Looks like Bookworm is trying to load incorect DRI library and it's creating issue.

[Heasterian]

Is there some kind of doc on how to compile it correctly? i am using the following meson options (the same that work with Grimas's repo

This command should work fine. If you would want to set up multiarch, I can help you also cross-compile armhf version.

[zanfix]

@zanfix Repo is correct, but I have same issues with Debian testing now in chroot (for now with Sparkle). Use MESA_LOADER_DRIVER_OVERRIDE=zink environment variable. Looks like Bookworm is trying to load incorect DRI library and it's creating issue.

Yes this works! Tunip gets loaded

The problem now is that Xwayland fails with error "missing XDG-WM-Base protocol"
According to #40 Lorie will not work with recent versions of Xwayland... so at this point I think that mesa must be compiled on bullseye, but then i would have the initial problem of libdrm-dev being outdated...
Any ideas?

EDIT: tried with sparkle and I get the same error

[Heasterian]

Compile old Wayland from Xorg source. This git works fine with Sparkle.

git clone -b xorg-server-1.20.13 --depth 1 git://github.com/freedesktop/xorg-xserver.git xorg-server-1.20.13

And configure it using this flags.

./autogen.sh --enable-mitshm --enable-xcsecurity --enable-xf86bigfont --enable-xwayland --enable-xorg --enable-xnest --enable-xvfb --disable-xwin --enable-xephyr --enable-kdrive --disable-devel-docs --disable-config-hal --disable-config-udev --disable-unit-tests --disable-selective-werror --disable-static --without-dtrace --disable-glamor --enable-dri --enable-dri2 --enable-dri3 --enable-glx --with-sha1=libsha1 --with-pic

[zanfix]

Compile old Wayland from Xorg source. This git works fine with Sparkle.

git clone -b xorg-server-1.20.13 --depth 1 git://github.com/freedesktop/xorg-xserver.git xorg-server-1.20.13

And configure it using this flags.

./autogen.sh --enable-mitshm --enable-xcsecurity --enable-xf86bigfont --enable-xwayland --enable-xorg --enable-xnest --enable-xvfb --disable-xwin --enable-xephyr --enable-kdrive --disable-devel-docs --disable-config-hal --disable-config-udev --disable-unit-tests --disable-selective-werror --disable-static --without-dtrace --disable-glamor --enable-dri --enable-dri2 --enable-dri3 --enable-glx --with-sha1=libsha1 --with-pic

I was having the same idea but did not know the flags to use... so i compiled with the flags you mentioned, all except --with-sha1=libsha1 --with-pic

It works! but the video performance (in general) is quite terrible! Strange because glxgears reports 300+ fps

Will do more tests soon...

Thank you!

EDIT: sparkle is having the same issue!

[Heasterian]

One guy that tried it recently reported that he have better result while DE is running on llvmpipe and other apps with Zink. Also, run start Xwayland on big cores (I'm using taskset -c 4.7 Xwayland with Sparkle). It boost performance a lot.

[zanfix]

One guy that tried it recently reported that he have better result while DE is running on llvmpipe and other apps with Zink. Also, run start Xwayland on big cores (I'm using taskset -c 4.7 Xwayland with Sparkle). It boost performance a lot.

I'm actually running the entire chroot hierarchy in a separate cgroups for cpuset (cores 4-7) and schedtune (boost to 50) subsystems already, so I already noticed it makes a difference!

So far I can say that termux:11 is better in video performance than xserver xsdl or sparkle!

[Heasterian]

Yea, it's faster. Also, when you are using it, keep the eye on FPS when touching the screen. Performance boosts a lot while you do this and drops right after.

[zanfix]

oook so,

I forced xfce4 to start with llvmpipe and the problem about video performance is gone

Now I am getting

• supertux2: fullscreen 1920x1200 ˜60 fps
• supertuxkart: fullscreen 1920x1200 ˜20/22 fps, windowed 1280x800 ˜35/40 fps

this is a BIG improvement!!!

[twaik]

Congratulations.

[Heasterian]

It works well and I managed to run first Portal using box86 and first Witcher game using Proton 7-0 rc6 GE1, but looks like touchpad input mode and external mouse don't work well with games using first person camera.

[twaik]

but looks like touchpad input mode and external mouse don't work well with games using first person camera.

Yeap, that is because of my terrible code (touchpad emulation) and Android's restrictions (capturing real mouse movements). I am planning to port libinput and use it instead of my touchpad emulator. But I stucked.

[iamSlightlyWind]

Okay, I will try to follow everything there is to try. I will use a fresh debian stable install from linux deploy.

First, mount chroot at /data/local/mnt. Mounted successfully:

#shell: android
:/ # ls /data/local/mnt/
bin   data  etc   lib         media  opt   root  sbin  sys  usr
boot  dev   home  lost+found  mnt    proc  run   srv   tmp  var
:/ # ls /data/local/mnt/home/
slightlywind

Delete the created /data/data/com.termux.x11/files/tmp folder and symlink:

#shell: android
ln -s /data/local/mnt/tmp /data/data/com.termux.x11/files/

Start termux-x11 and check if the socket is created:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwx------.  1 10434 10434    0 Feb 18 02:03 wayland-0
-rw-------.  1 10434 10434    0 Feb 18 02:03 wayland-0.lock

chmod 777 the socket:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwxrwxrwx. 1 10434 10434 0 Feb 18 02:03 wayland-0
-rw-------. 1 10434 10434 0 Feb 18 02:03 wayland-0.lock

Chroot install xorg, xwayland and i3: sudo apt-get install xorg xwayland i3 -y

Try to start i3:

slightlywind@localhost:~$ export DISPLAY=:0
slightlywind@localhost:~$ export XDG_RUNTIME_DIR=/tmp/
slightlywind@localhost:~$ Xwayland :0 -noreset & sleep 1 && i3

And now I am pissed that it actually works. Thank you everyone in this issues comment section. The symlink must have solved it. I will replicate this in my daily driver chroot.

---

Edit: For anyone wanting to try Heasterian's mesa on debian testing, compiling xwayland is not needed. Just download a known working version of xwayland on pkgs.org. For me the 1.20.13 of ubuntu focal fossa works.

[iamSlightlyWind]

It seems that (for me) the graphical performance, sparkle is giving me more than when using termux-x11. The performance is compared on debian testing, running on kde(llvmpipe) and gl benchmarks (both on llvmpipe and Heasterian's zink) on my (gpu) overclocked and undervolted tab s7. kde and apps take quite some time and resources to load on termux-x11, graphical benchmarks show significantly lower performance (~10% or more). Overall, it seems that the only occasion when I need to use termux-x11 is when I need to use it in as a window, not full screen like sparkle (which when I think about it, actually sounds very helpful in some situations). Kde with compositor off is very smooth (native-like smooth, which is crazy to think about when last week I was just using xfce on xsdl server and it wasn't a good experience either).

[Xunflash]

Okay, I will try to follow everything there is to try. I will use a fresh debian stable install from linux deploy.

First, mount chroot at /data/local/mnt. Mounted successfully:

#shell: android
:/ # ls /data/local/mnt/
bin   data  etc   lib         media  opt   root  sbin  sys  usr
boot  dev   home  lost+found  mnt    proc  run   srv   tmp  var
:/ # ls /data/local/mnt/home/
slightlywind

Delete the created /data/data/com.termux.x11/files/tmp folder and symlink:

#shell: android
ln -s /data/local/mnt/tmp /data/data/com.termux.x11/files/

Start termux-x11 and check if the socket is created:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwx------.  1 10434 10434    0 Feb 18 02:03 wayland-0
-rw-------.  1 10434 10434    0 Feb 18 02:03 wayland-0.lock

chmod 777 the socket:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwxrwxrwx. 1 10434 10434 0 Feb 18 02:03 wayland-0
-rw-------. 1 10434 10434 0 Feb 18 02:03 wayland-0.lock

Chroot install xorg, xwayland and i3: sudo apt-get install xorg xwayland i3 -y

Try to start i3:

slightlywind@localhost:~$ export DISPLAY=:0
slightlywind@localhost:~$ export XDG_RUNTIME_DIR=/tmp/
slightlywind@localhost:~$ Xwayland :0 -noreset & sleep 1 && i3

And now I am pissed that it actually works. Thank you everyone in this issues comment section. The symlink must have solved it. I will replicate this in my daily driver chroot.

Edit: For anyone wanting to try Heasterian's mesa on debian testing, compiling xwayland is not needed. Just download a known working version of xwayland on pkgs.org. For me the 1.20.13 of ubuntu focal fossa works.

Hello, after I followed your steps, I got these errors

Xwayland :2 -noreset & sleep 1 && i3 ─╯
[2] 18511
libEGL warning: MESA-LOADER: failed to open msm_drm: /usr/lib/dri/msm_drm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open msm_drm: /usr/lib/dri/msm_drm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

i3: Cannot open display

I tried looking it up online but it didn't work
My chroot container is archlinuxarm

[iamSlightlyWind]

I'm not familiar with arch, but can you make sure that termux-x11 is opening a socket at that port? if you symlink the socket folder to /tmp/, whats the output of ls /tmp/ of the chroot?

[zanfix]

Okay, I will try to follow everything there is to try. I will use a fresh debian stable install from linux deploy.
First, mount chroot at /data/local/mnt. Mounted successfully:

#shell: android
:/ # ls /data/local/mnt/
bin   data  etc   lib         media  opt   root  sbin  sys  usr
boot  dev   home  lost+found  mnt    proc  run   srv   tmp  var
:/ # ls /data/local/mnt/home/
slightlywind

Delete the created /data/data/com.termux.x11/files/tmp folder and symlink:

#shell: android
ln -s /data/local/mnt/tmp /data/data/com.termux.x11/files/

Start termux-x11 and check if the socket is created:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwx------.  1 10434 10434    0 Feb 18 02:03 wayland-0
-rw-------.  1 10434 10434    0 Feb 18 02:03 wayland-0.lock

chmod 777 the socket:

#shell: chroot bash
slightlywind@localhost:~$ ls -l /tmp/
total 0
srwxrwxrwx. 1 10434 10434 0 Feb 18 02:03 wayland-0
-rw-------. 1 10434 10434 0 Feb 18 02:03 wayland-0.lock

Chroot install xorg, xwayland and i3: sudo apt-get install xorg xwayland i3 -y
Try to start i3:

slightlywind@localhost:~$ export DISPLAY=:0
slightlywind@localhost:~$ export XDG_RUNTIME_DIR=/tmp/
slightlywind@localhost:~$ Xwayland :0 -noreset & sleep 1 && i3

And now I am pissed that it actually works. Thank you everyone in this issues comment section. The symlink must have solved it. I will replicate this in my daily driver chroot.
Edit: For anyone wanting to try Heasterian's mesa on debian testing, compiling xwayland is not needed. Just download a known working version of xwayland on pkgs.org. For me the 1.20.13 of ubuntu focal fossa works.

Hello, after I followed your steps, I got these errors

Xwayland :2 -noreset & sleep 1 && i3 ─╯
[2] 18511
libEGL warning: MESA-LOADER: failed to open msm_drm: /usr/lib/dri/msm_drm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open msm_drm: /usr/lib/dri/msm_drm_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

i3: Cannot open display

I tried looking it up online but it didn't work My chroot container is archlinuxarm

I was having these same error messages after compiling mesa on debian. Try to use the MESA_LOADER_DRIVER_OVERRIDE env variable to force llvmpipe. BUT i actually think that it's not working for you because you did not set the DISPLAY variable for i3:

MESA_LOADER_DRIVER_OVERRIDE=llvmpipe Xwayland :2 -noreset &
sleep 1
MESA_LOADER_DRIVER_OVERRIDE=llvmpipe DISPLAY=:2 i3

[Heasterian]

msm_drm_dri.so is dri lib of prorpieraty driver so it's indicating that phone is trying to load it. Setting MESA_LOADER_DRIVER_OVERRIDE to zink also should help.

[Xunflash]

msm_drm_dri.so is dri lib of prorpieraty driver so it's indicating that phone is trying to load it. Setting MESA_LOADER_DRIVER_OVERRIDE to zink also should help.

MESA_LOADER_DRIVER_OVERRIDE=llvmpipe Xwayland :3 -noreset &
When I enter this command, these errors still appear

libEGL warning: MESA-LOADER: failed to open llvmpipe: /usr/lib/dri/llvmpipe_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

libEGL warning: MESA-LOADER: failed to open llvmpipe: /usr/lib/dri/llvmpipe_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)

could not connect to wayland server
(EE)
Fatal server error:
(EE) Couldn't add screen
(EE)
[1] + exit 1 MESA_LOADER_DRIVER_OVERRIDE=llvmpipe Xwayland :3 -noreset

I try to run this
ls /usr/lib/dri
turn out

armada-drm_dri.so ili9341_dri.so kms_swrast_dri.so mi0283qt_dri.so pl111_dri.so repaper_dri.so swrast_dri.so
d3d12_dri.so imx-dcss_dri.so lima_dri.so msm_dri.so r200_dri.so rockchip_dri.so v3d_dri.so
etnaviv_dri.so imx-drm_dri.so mali-dp_dri.so mxsfb-drm_dri.so r300_dri.so st7586_dri.so vc4_dri.so
exynos_dri.so ingenic-drm_dri.so mcde_dri.so nouveau_dri.so r600_dri.so st7735r_dri.so virtio_gpu_dri.so
hx8357d_dri.so kgsl_dri.so mediatek_dri.so nouveau_vieux_dri.so radeon_dri.so stm_dri.so zink_dri.so
ili9225_dri.so kirin_dri.so meson_dri.so panfrost_dri.so radeonsi_dri.so sun4i-drm_dri.so

There is no llvmpipe_dri.so in it

I also tried
MESA_LOADER_DRIVER_OVERRIDE=zink Xwayland :3 -noreset &
but when I run
MESA_LOADER_DRIVER_OVERRIDE=zink DISPLAY=:3 i3
the terminal gets stuck

Sorry I'm not a professional and my English is not good (Google translate used), as a student I'm still learning these commands

[twaik]

Can I close this issue?

[zanfix]

I think so yes

[N1Shambhu-KR]

Such thing is so simple

Download and install tetmux x11 apk from the tag and install it and open it

Open termux x11 and execute termux-x11 :0 &.it will redirect and create a Wayland socket in th $PREFIX/tmp folder of termux.

Start the custom chroot

Switch to termux and type su.and mount the termux wayland($PREFIX/tmp) Directory to chroot's wayland directory (create if not available) by executing mount -o bind /data/data/com.termux/usr/tmp /data/local/tmp(in case linux deploy).

Type exit

connect to chroot via ssh

type in ` sudo chmod 777 /wayland

sudo chmod 777 /wayland/wayland-0

XDG_RUNTIME_DIR=/wayland Xwayland &
sleep 1

export DISPLAY=:0

xfce4-session & ` (if xfce)

Switch to termux x11 and hola

[zanfix]

@zanfix If you would want to try upstream Mesa to have better Zink speed, you can compile it from my repo with same config used for Grima's https://github.com/Heasterian/mesa In practice it's same modification, but It's changing only two lines of code.

Hi Heasterian, don't know how to ask you the question elsewhere...
do you know if there are any new improvements with zink and kgsl? is compiling mesa from upstream enough to test it'? (make it work?)

[Heasterian]

I'm not sure if after Kopper merge to Zink it will work fine, but mainline Mesa version from projects's Gitlab should now compile without mine changes (well, it's probably missing one line preventing crash in one of glmark2 tests but except this, it should work). If it will work tho, many improvements should be implemented meanwhile to both Turnip with KGSL support and Zink.

[Heasterian]

In worst case scenario it should be possible to build mainline Turnip and older Zink version, from before Kopper merge.

[Heasterian]

Also, I'm not sure if it applies to KGSL, but using Turnip with Zink on mainline Linux kernel you get bindless images and way more total descriptors using Zink than Freedreno and GL 4.6 instead of 4.3 so compatibility should be much better now.

[zanfix]

I'm not sure if after Kopper merge to Zink it will work fine, but mainline Mesa version from projects's Gitlab should now compile without mine changes (well, it's probably missing one line preventing crash in one of glmark2 tests but except this, it should work). If it will work tho, many improvements should be implemented meanwhile to both Turnip with KGSL support and Zink.

I will try it...

[zanfix]

i tried with 22.2.0-rc3 but it does not work...
there is what i get:

zanfix@localhost:~$ MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink glxinfo
name of display: unix:0.0
MESA: error: zink: KHR_timeline_semaphore is required
libGL error: glx: failed to create drisw screen
libGL error: failed to load driver: zink
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  60
  Current serial number in output stream:  61

[twaik]

Zink tries to create GLX context, but unfortunately it is not supported. You can try to use llvmpipe.

[zanfix]

Zink tries to create GLX context, but unfortunately it is not supported. You can try to use llvmpipe.

i compiled mainline mesa for zink/kgsl but it appears broken in 22.2.0-rc3...
maybe @Heasterian has a clue...

[DLC01]

i tried with 22.2.0-rc3 but it does not work... there is what i get:

zanfix@localhost:~$ MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink glxinfo
name of display: unix:0.0
MESA: error: zink: KHR_timeline_semaphore is required
libGL error: glx: failed to create drisw screen
libGL error: failed to load driver: zink
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  151 (GLX)
  Minor opcode of failed request:  24 (X_GLXCreateNewContext)
  Value in failed request:  0x0
  Serial number of failed request:  60
  Current serial number in output stream:  61

Zink has now increased the vulkan requirements and will fail to work on drivers which doesn't have the basic required extensions

[zanfix]

i see...

[Heasterian]

Looks like zink have issues with software displays since kopper merge. I need to open issue about it, but I'm not sure if it's not missing functionality in xorg and not Mesa itself.

[AlexBreedveld]

I wrote a reply on another issue that might be worth checking out for those who are still having problems with rendering a desktop environment in chroot on Termux-x11.

Link to my reply on issue #175