Starting desktop separately is not really convenient since you must write script which will ping X server. Using -xstartup option or startx solution will be much more convenient in this case.

With a service script like this I can just do sv up termux-x11 and then DISPLAY=:1 my-gui-app, if I am not interested in the full desktop environment then this is pretty useful.

We can add a service script that runs termux-x11 :1 -xstartup "dbus-launch --exit-with-session xfce4-session" as well, but then xfce4 should be added as TERMUX_PKG_RECOMMENDS or TERMUX_PKG_SUGGESTS as well I think

The termux-x11 command should be stopped with pkill -f com.termux.x11 since the process name is different from termux-x11.

Also termux-x11 supports specifying TERMUX_X11_XSTARTUP before starting termux-x11 command, so user can specify xfce4-session or other script in ~/.bashrc. But sv should somehow source or . the bashrc before starting termux-x11.

The termux-x11 command should be stopped with pkill -f com.termux.x11 since the process name is different from termux-x11.

It seems to work as is, runit keeps termux-x11 in foreground and then kills the process when sv down termux-x11 is run.
The process is called something like:
/system/bin/app_process -Xnoimage-dex2oat / com.termux.x11.Loader :1
and that one is removed both with sv down termux-x11 and pkill -f com.termux.x11, there are no rogue processes as far as I can tell with sv down termux-x11.

Also termux-x11 supports specifying TERMUX_X11_XSTARTUP before starting termux-x11 command, so user can specify xfce4-session or other script in ~/.bashrc. But sv should somehow source or . the bashrc before starting termux-x11.

Hmm, it would be better to have the setting in some config file like ~/.termux_x11.conf and make termux-x11 load the setting from there. The bashrc might have all kinds of weird settings, so I think best practise would be to not touch it. Parsing it and only it also leaves zsh and fish and other shell users to fend for themselves. We can make an exception for now though, I see how it can be useful for termux-x11 since setting TERMUX_X11_XSTARTUP in bashrc is mentioned in README

termux-x11-xfce4 is a bit long.. Maybe we can use just x11 and x11-xfce4 in the service scripts, i.e. sv up x11, sv up x11-xfce4? What do you think?

I am not sure. x11 seems to be too much general. Probably tx11 will be better.

Updated, thanks!

I have doubts about using :1. Termux:X11 can use some random display number in the case if it is not specified for the situation if user started VNC server or xvfb-run or anything else on :1.

But in the case if user starts plain X server without session random display number is not acceptable.

Yes, good point, seems like termux-x11 defaults to :0 if it is not specified? There is no good way to communicate from the service script what display number is used (user has to manually cat $PREFIX/var/log/sv/tx11/current to see any log output), so I think we have to hardcode something. :1 is used in your README, so I guess most users will assume that is used by default.

We could go for something more random like :7 or :1337, and document it in README and/or other suitable places, if you think that is better?

It defaults to the first available port. You can use -displayfd argument to make termux-x11 write display number to file. I mean you open fd in bash pointing to some empty file (or fifo) and when the X server will be available it will write display number to that file.

It defaults to the first available port. You can use -displayfd argument to make termux-x11 write display number to file. I mean you open fd in bash pointing to some empty file (or fifo) and when the X server will be available it will write display number to that file.

I didn't know such a parameter existed. But I don't know how to use it to replace the DISPLAY variable. Seems very useful !

It does not "replace" DISPLAY variable. Only tells which DISPLAY variable should be used after service is started.

Updated, the service scripts use -displayfd and print to $PREFIX/var/run/tx11{,-xfce4}.display, but it does not work for me, it always prints 0 to the file. Even if I run vncserver on :0 termux-x11 tries to use :0 as well. Is that expected @twaik?

Even if I run vncserver on :0 termux-x11 tries to use :0 as well. Is that expected @twaik?

Emmm, seems like I found it.
I disabled binding abstract sockets in termux/termux-x11@73f2f99 because rebinding it after failure was a mess, kernel does not let rebind socket a few seconds after X server process dies. Probably we should patch our xtrans for this as well and rebuild all reverse dependencies (or at least X servers, libxcb and libx11).

A little explanation why you can start both vncserver and termux-x11 on :0.
When you start X11 program libX11 (or libxcb) probes all possible sockets (according to what is defined in DISPLAY, let's say :0) for connection: abstract, Unix and TCP sockets. In this case vncserver binds abstract socket while termux-x11 binds unix domain socket on same path, so vncserver is more preferable target for connection.

I opened #24216 to fix this behaviour.

Ok, I fixed the abstract socket thingy. For some reason socket file descriptor is not being marked as CLOEXEC so it was leaked to X session and kernel did not close it as it was expected by X server. I have no idea why the same thing did not happen to Unix socket as well, probably because X server explicitly unlinks it on failures while there is no such option available for abstract sockets.

I installed latest apk and deb from here, but it still seem to always use :0, unless I manually edit service script to use something else (like :1337).

Maybe it is fine to merge as is, sv up/down tx11 or sv up/down tx11-xfce4 is quite handy in any case..

Ok, now it is weird. I need to do some deep research to find out what exactly happens here.

Locally built apk is completely fine while CI artifact has the bug. I do not like it.

Probably some random bug, now it should be fine.

Awesome, now it works! I will merge during the weekend unless there are objections!

@Grimler91 does this update activate tx11-xfce4 by default? One of my users says it appeared after apt upgrade without being activated manually.