Open uetcis opened 2 months ago
(gdb) r --ozone-platform=wayland
...
Thread 1 "trackaudio" received signal SIGSEGV, Segmentation fault.
0x00007fffed2c4396 in SDK::buildServer() [clone .cold] () from /tmp/.org.chromium.Chromium.cwNyDr
I tried to reproduce this issue on my machine and it can not 100% produce. I tried about 10 times and this issue occurred twice.
$ trackaudio --ozone-platform=wayland
libva error: /usr/lib/dri/i965_drv_video.so init failed
hook_thread_proc [101]: Could not set thread priority 49 for thread 0x7623462006C0!
load_input_helper [1827]: XkbGetKeyboard failed to locate a valid keyboard!
OS: EndeavourOS Linux x86_64
Kernel: 6.8.7-arch1-1
DE: Plasma 6.0.4
WM: kwin
GPU: Intel CometLake-U GT2 [UHD Graphics]
GPU: NVIDIA GeForce MX250
I can reproduce this issue at every time after unset DISPLAY
$ unset DISPLAY
$ trackaudio --ozone-platform=wayland
libva error: /usr/lib/dri/i965_drv_video.so init failed
hook_thread_proc [101]: Could not set thread priority 49 for thread 0x799DDFC006C0!
xrecord_start [1024]: XOpenDisplay failure!
[1] 37238 IOT instruction (core dumped) trackaudio --ozone-platform=wayland
$ trackaudio --ozone-platform=wayland
libva error: /usr/lib/dri/i965_drv_video.so init failed
hook_thread_proc [101]: Could not set thread priority 49 for thread 0x708FAE4006C0!
xrecord_start [1024]: XOpenDisplay failure!
[1] 37478 IOT instruction (core dumped) trackaudio --ozone-platform=wayland
$ trackaudio
[37638:0428/195827.481567:ERROR:ozone_platform_x11.cc(244)] Missing X server or $DISPLAY
[37638:0428/195827.481658:ERROR:env.cc(257)] The platform failed to initialize. Exiting.
[1] 37638 segmentation fault (core dumped) trackaudio
FYI: I found this thread on reddit and this on Ubuntu Discourse, they said Wayland use $WAYLAND_DISPLAY
instead of $DISPLAY
, and X11 applications drawing via Xwayland, $DISPLAY
will be set.
There may be some reasons why $DISPLAY
is not set. Try sudo ps -A | grep "wayland"
and check the output?
Not every Wayland user has unrootful xwayland. Also, if an app actually supports native Wayland then it shouldn’t depend on $DISPLAY. Most electron apps would not need the $DISPLAY variable set if it’s run with --ozone-platform=wayland, so it seems to be a trackaudio specific issue.
This is going to heavily depend on Electron's support of wayland. If you google it, you'll find a bunch of people are also struggling with this. Try to run it with --enable-features=UseOzonePlatform --ozone-platform=wayland For now, your best bet is probably XWayland
See section 5.9 here: https://wiki.archlinux.org/title/wayland
This is going to heavily depend on Electron's support of wayland. If you google it, you'll find a bunch of people are also struggling with this. Try to run it with --enable-features=UseOzonePlatform --ozone-platform=wayland For now, your best bet is probably XWayland
That doesn't work. Also note that the crash takes place in the C++ backend
(gdb) r --ozone-platform=wayland
...
Thread 1 "trackaudio" received signal SIGSEGV, Segmentation fault.
0x00007fffed2c4396 in SDK::buildServer() [clone .cold] () from /tmp/.org.chromium.Chromium.cwNyDr
Does this specific Segfault occur reliably every time? There is no Wayland specific reason as to why that bit of code would segfault - it does not use native libraries aside from pthreads
Does this specific Segfault occur reliably every time? There is no Wayland specific reason as to why that bit of code would segfault - it does not use native libraries aside from pthreads
Yes
If you can rebuild locally, comment out the call to that function and see what happens - I will investigate in my VM
After comment this line SDK::SDK() { /*this->buildServer();*/ }
and rebuild the backend, then it was still sigfault.
> trackaudio@1.0.2-beta.2 start
> electron-forge start -- --ozone-platform=wayland
✔ Checking your system
✔ Locating application
✔ Loading configuration
✔ Preparing native dependencies: 1 / 1 [0.4s]
✔ Running generateAssets hook
✔ [plugin-webpack] Compiling main process code [2s]
✔ [plugin-webpack] Launching dev servers for renderer process code [15s]
› Output Available: http://localhost:9000
<i> [ForkTsCheckerWebpackPlugin] Type-checking in progress...
<i> [ForkTsCheckerWebpackPlugin] No errors found.
libva error: /usr/lib/dri/i965_drv_video.so init failed
hook_thread_proc [101]: Could not set thread priority 49 for thread 0x7C242DA006C0!
xrecord_start [1024]: XOpenDisplay failure!
Which GPU are you both running and which drivers are you using?
Which GPU are you both running and which drivers are you using?
https://github.com/pierr3/TrackAudio/issues/11#issuecomment-2081414860
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.76 Driver Version: 550.76 CUDA Version: 12.4 |
|-----------------------------------------+------------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+========================+======================|
| 0 NVIDIA GeForce MX250 Off | 00000000:06:00.0 Off | N/A |
| N/A 45C P8 N/A / ERR! | 5MiB / 2048MiB | 0% Default |
| | | N/A |
+-----------------------------------------+------------------------+----------------------+
I don't have much experience installing drivers for nvidia graphics cards on Arch, so if you need more information please let me know, sorry for that.
Thanks, if you can try, you should install the proprietary nvidea drivers and see what happens. Overall this issue is not likely to be with TrackAudio, but with specific versions of arch and GPU setups, and how the chromium engine in Electron behaves. If you can use XWayland, I'd recommend that.
It could also be because uiohook-napi the library used to detect push to talk, is built using X11 native apis
See here, seems like an update to that library is not likely to occur soon.
It could also be because uiohook-napi the library used to detect push to talk, is built using X11 native apis
See here, seems like an update to that library is not likely to occur soon.
Is there any alternative?
No, it would require making a separate dependency just for wayland, which is not on my roadmap at the moment. I will accept a PR, however.
On Mon, 29 Apr 2024 at 23:16, Sparrow He @.***> wrote:
It could also be because uiohook-napi https://github.com/SnosMe/uiohook-napi the library used to detect push to talk, is built using X11 native apis也可能是因为用于检测一键通的库 uiohook-napi 是使用 X11 原生 API 构建的
See here https://github.com/kwhat/libuiohook/issues/100, seems like an update to that library is not likely to occur soon.看到这里,似乎不太可能很快对该库进行更新。
Is there any alternative?
— Reply to this email directly, view it on GitHub https://github.com/pierr3/TrackAudio/issues/11#issuecomment-2084297115, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN7UK2OBCOFR4QQSAQSUU3Y74EI5AVCNFSM6AAAAABG4Z6WMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBUGI4TOMJRGU . You are receiving this because you commented.Message ID: @.***>
You should now be able to run electron in Wayland natively and perhaps the backend would tolerate no X11 if you use a joystick PTT only, to be tested. The input handler uses SFML 2.6 in the backend/
Currently, running TrackAudio under a pure Wayland environment is impossible:
Wayland is expected to replace X11 in the future, and some of the major Linux distros have already started shipping Wayland desktop environments by default. Thus, Wayland support should be considered.
My environment: OS: Artix Linux x86_64 Kernel: 6.8.7-artix1-2 Resolution: 3840x2160 Wayland window manager/compositor: niri