search

termux / termux-packages

A package build system for Termux.
https://termux.dev
Other
13.08k stars 3k forks source link

[Bug]: xfce4 crashes in vnc. #19091

Open Anonymous2716 opened 8 months ago

Anonymous2716 commented 8 months ago

Problem description

Xfce4-session doesn't start. Results in a blank screen.

Additional info if needed : My device doesn't support vulkan I think.

What steps will reproduce the bug?

vncserver -xstartup xfce4-session

What is the expected behavior?

No response

System information

termux-info:

❯ termux-info
Termux Variables:
TERMUX_API_VERSION=0.50.1
TERMUX_APK_RELEASE=UNKNOWN
TERMUX_APP_PACKAGE_MANAGER=apt
TERMUX_APP_PID=31239
TERMUX_IS_DEBUGGABLE_BUILD=0
TERMUX_MAIN_PACKAGE_FORMAT=debian
TERMUX_VERSION=0.118.0
TERMUX__USER_ID=0
Packages CPU architecture:
aarch64
Subscribed repositories:
# sources.list
deb https://grimler.se/termux/termux-main stable main
# glibc-repo (sources.list.d/glibc.list)
deb https://packages-cf.termux.dev/apt/termux-glibc/ glibc stable
# tur-repo (sources.list.d/tur.list)
deb https://tur.kcubeterm.com tur-packages tur tur-on-device tur-continuous
# x11-repo (sources.list.d/x11.list)
deb https://grimler.se/termux/termux-x11 x11 main
Updatable packages:
All packages up to date
termux-tools version:
1.40.5
Android version:
9
Kernel build information:
Linux localhost 4.4.146  aarch64 Android
LD Variables:
LD_LIBRARY_PATH=
LD_PRELOAD=/data/data/com.termux/files/usr/lib/libtermux-exec.so
Installed termux plugins:
com.termux.api versionCode:51
com.termux.gui versionCode:7
com.termux.x11 versionCode:14
com.termux.styling versionCode:30

logcat in termux:

01-30 06:16:38.507 32597 32597 F DEBUG   : Revision: '0'
01-30 06:16:38.507 32597 32597 F DEBUG   : ABI: 'arm64'
01-30 06:16:38.507 32597 32597 F DEBUG   : pid: 32550, tid: 32550, name: xfce4-session  >>> xfce4-session <<<
01-30 06:16:38.507 32597 32597 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-30 06:16:38.507 32597 32597 F DEBUG   : Abort message: 'invalid stub function called'
01-30 06:16:38.507 32597 32597 F DEBUG   :     x0  0000000000000000  x1  0000000000007f26  x2  0000000000000006  x3  0000000000000008
01-30 06:16:38.507 32597 32597 F DEBUG   :     x4  0000000000000049  x5  0000000000000049  x6  0000000000000049  x7  0000000000000000
01-30 06:16:38.507 32597 32597 F DEBUG   :     x8  0000000000000083  x9  0000007da50bab40  x10 fffffff87fffffdf  x11 0000000000000001
01-30 06:16:38.507 32597 32597 F DEBUG   :     x12 0000007fc1738c60  x13 ffffffffffffffff  x14 ffffffffff000000  x15 ffffffffffffffff
01-30 06:16:38.507 32597 32597 F DEBUG   :     x16 0000007da50f32c8  x17 0000007da50312d8  x18 0000007fc173844a  x19 0000000000007f26
01-30 06:16:38.507 32597 32597 F DEBUG   :     x20 0000000000007f26  x21 0000000000000083  x22 0000000000000000  x23 0000007da31ed900
01-30 06:16:38.507 32597 32597 F DEBUG   :     x24 fffffffffffffffe  x25 0000007da60a35e0  x26 0000007da29cf000  x27 0000007da31eea20
01-30 06:16:38.507 32597 32597 F DEBUG   :     x28 0000007da288eee8  x29 0000007fc1738b80
01-30 06:16:38.507 32597 32597 F DEBUG   :     sp  0000007fc1738b40  lr  0000007da5025a90  pc  0000007da5025abc
01-30 06:16:38.511 32597 32597 F DEBUG   :
01-30 06:16:38.511 32597 32597 F DEBUG   : backtrace:
01-30 06:16:38.511 32597 32597 F DEBUG   :     #00 pc 0000000000021abc  /system/lib64/libc.so (abort+124)
01-30 06:16:38.511 32597 32597 F DEBUG   :     #01 pc 00000000000080f8  /system/lib64/liblog.so (__android_log_assert+296)
01-30 06:16:38.511 32597 32597 F DEBUG   :     #02 pc 000000000001731c  /system/lib64/libvulkan.so (vulkan::stubhal::(anonymous namespace)::NoOp()+28)
01-30 06:16:38.511 32597 32597 F DEBUG   :     #03 pc 00000000005c1c64  /data/data/com.termux/files/usr/lib/dri/kms_swrast_dri.so (offset 0x1061000)
01-30 06:16:38.574 32597 32597 I crash_dump: crash_dump_notify exit
Anonymous2716 commented 8 months ago

I tried to use other GUI apps through qterminal only in vnc , I get the same Abort message: 'invalid stub function called'

licy183 commented 8 months ago

Try to install vulkan-loader-generic and see if this issue is fixed.

Anonymous2716 commented 8 months ago

@licy183 its working after installing the generic loader. Should I close this issue?

licy183 commented 8 months ago

Emmm... not need to close this. Maybe some devices will be affected by this, although my device isn't affected.

Maybe as what discussed before in https://github.com/termux/termux-packages/pull/17297#discussion_r1249896105, introducing vulkan-loader is a mistake. Actually mesa over zink without vulkan-loader-generic will not work correctly, but making mesa depend on vulkan-loader-generic will also break installation of some packages, for example, python-torch and mesa cannot be installed at the same time.

CC: @truboxl

truboxl commented 8 months ago

  1. Can make vulkan-loader-generic the default for vulkan-loader

  2. Then resolve the issues for each packages that arise

  3. Deprecate the use of vulkan-loader-android and remove it

twaik commented 6 months ago

I think we have a better option.

19460

We can make it a default option. Probably we should patch Xfvb/Xwayland/TigerVnc to handle DRI3 like termux-x11 but it will add X11 WSI to regular Android Vulkan library so it can be used as a default.

twaik commented 6 months ago

Or we can wait for @tareksander's termux-gfx-wrapper.

tareksander commented 6 months ago

That'll still take a while. It'll support selecting the system EGL, GLES or Vulkan via env variables or in the API for EGL though. Packages like pytorch could be patched to configure the wrapper to use system libraries if needed if needed. That would also replace the vulkan-loader-android.

twaik commented 6 months ago

@truboxl @licy183 So what do you think about making vulkan-wsi-wrapper a default for vulkan-loader? BTW I do not see source code link for vulkan-loader-android, only that it is extracted from NDK release zip.

twaik commented 6 months ago

Also, about sysvk. We can make a post-inst script that may check if xMeM's sysvk works on given device and it will decide if it can be enabled or not.

licy183 commented 6 months ago

Emmm... Is vulkan-wsi-wrapper part of termux-gfx-wrapper? Or the method mentioned in #19460. If you are referring to the latter one , it still needs vulkan-loader-generic as the default vulkan loader, since vulkan-wsi-layer (as vulkan implicit layer) and sysvk (as ICD) need to depend on vulkan-loader-generic.

tareksander commented 6 months ago

My termux-gfx-wrapper Vulkan version would also need vulkan-loader-generic, and would essentially accomplish the same as xMeM's variant, but with only public APIs. Since Vulkan already works headless, X11 and Wayland WSI is the only think that needs to be added. Why exactly do some packages need the system Vulkan version anyways?

twaik commented 6 months ago

Sorry, my fault. I was typing faster than I was thinking. I think it will be better to make ONLY ONE thing, some combination of sysvk, vulkan-loader-android and vulkan-wsi-layer and make it available as ICD.

I mean:

  1. Sysvk. I think we can simply make it builtin to vulkan-wsi-layer, because it is only 30 lines of code and vulkan-wsi-wrapper will not work with other vulkan implementations except vulkan-loader-android. BUT this method can cause segmentation fault (because it is non-public API and vendors do not have to keep ABI compatibility) so we should make install-time or runtime checks (for example invoking some test in different process with execve and wait for result) and decide if we use sysvk or vulkan-loader-android (see 2).
  2. I am not sure where exactly we can obtain the code of libvulkan that is built for NDK and distributed in tarball, but I think it is this. As far as I can see it contains some code that should be shared between all possible Android vulkan implementations and the loader, similar to vulkan-loader-generic, but only for Android vulkan implementations. I think we can make vulkan-wsi-loader dlopen /system/lib[64]/libvulkan.so, dlsym there vkGetInstanceProcAddr and invoke it in vk_icdGetInstanceProcAddr. That part will serve as a vulkan-loader-android, but in the context of vulkan-loader-generic, so we will not need two separate vulkan loaders.
  3. I am not sure but I think we do not need separate sysvk, vulkan-loader-android and vulkan-wsi-layer since sysvk and vulkan-loader-android serve for the same purpose and vulkan-wsi-layer is useless without them (and works only in the case of X11 windows, its code will be noop in the headless mode).

python-torch and mesa cannot be installed at the same time.

Why?

truboxl commented 6 months ago

This is what I get for sysvk

~/downloads $ vulkaninfo
ERROR: [Loader Message] Code 0 : loader_scanned_icd_add: Could not get 'vkCreateInstance' via 'vk_icdGetInstanceProcAddr' for ICD libsysvk.so
ERROR: [Loader Message] Code 0 : vkCreateInstance: Found no drivers!
Cannot create Vulkan instance.
This problem is often caused by a faulty installation of the Vulkan driver or attempting to use a GPU that does not support Vulkan.
ERROR at /home/builder/.termux-build/vulkan-tools/src/vulkaninfo/./vulkaninfo.h:458:vkCreateInstance failed with ERROR_INCOMPATIBLE_DRIVER
tareksander commented 6 months ago

I'd be willing to contribute a public API version sysvk (and vulkan-wsi-wrapper for that matter) that can be switched to when the install time checks fail. You'd keep both in the same package, and copy the ICD json file of the one that is chosen to the ICD file directory. The package would then build and include sysvk, vulkan-wsi-wrapper and the Vulkan part of termux-gfx-wrapper.

licy183 commented 6 months ago

vulkan-loader-android has a long history. Initially, vulkan was not available on Termux. Since PR #7165, truboxl packaged vulkan-loader-android to provide headless vulkan operations. After that, many packages in the main repository began to use vulkan-loader-android to provide vulkan operations, such as fastfetch, libncnn, clvk, python-torch, etc. Most of them use headless operations or just query GPU models. Later, vulkan-loader-generic is packaged to provide vulkan operations about X11/Wayland, and later some ICDs are added. This is why we now have two vulkan-loaders.

python-torch and mesa cannot be installed at the same time.

Why?

I just checked and the problem seems to no longer exist. If I remember correctly, when vulkan support for python-torch was just added, python-torch directly depended on vulkan-loader-android. And fastfetch also has the same problem. Later, truboxl corrected these dependencies. Now, they all depend on vulkan-loader instead of vulkan-loader-android, so the problem I mentioned above has gone.

twaik commented 6 months ago

This is what I get for sysvk

Yeah, in that case we can fallback to vkGetInstanceProcAddr from /system/lib[64]/libvulkan.so if libhardware-based code fails.

I'd be willing to contribute a public API version sysvk

See code of sysvk. https://github.com/xMeM/sysvk/blob/main/sysvk.c That is the reason I am suggesting to fallback to vkGetInstanceProcAddr from /system/lib[64]/libvulkan.so. Should be pretty much same thing.

This is why we now have two vulkan-loaders.

And that is why I am proposing to make vulkan-loader-android be available as an ICD for vulkan-loader-generic.

But probably we need to do something to make some packages force Android's vulkan implementation in that case. I am not sure how to do this.

tareksander commented 6 months ago

But probably we need to do something to make some packages force Android's vulkan implementation in that case. I am not sure how to do this.

What is the alternative implementation? Probably lavapipe in Mesa, right? In that case sane applications should work correctly, as they'd choose the dedicated GPU device over a CPU emulation: https://docs.vulkan.org/spec/latest/chapters/devsandqueues.html#VkPhysicalDeviceType