Wayland support: SFML input backend

[uetcis]

Currently, running TrackAudio under a pure Wayland environment is impossible:

$ trackaudio
[8333:0428/014713.723699:ERROR:ozone_platform_x11.cc(244)] Missing X server or $DISPLAY
[8333:0428/014713.723728:ERROR:env.cc(257)] The platform failed to initialize.  Exiting.
fish: Job 1, 'trackaudio' terminated by signal SIGSEGV (Address boundary error)

$ trackaudio  --ozone-platform=wayland
hook_thread_proc [101]: Could not set thread priority 49 for thread 0x725A3EE006C0!
xrecord_start [1024]: XOpenDisplay failure!
fish: Job 1, 'trackaudio  --ozone-platform=wa…' terminated by signal SIGABRT (Abort)

$ trackaudio  --ozone-platform=wayland
fish: Job 1, 'trackaudio  --ozone-platform=wa…' terminated by signal SIGSEGV (Address boundary error)

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

[uetcis]

(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

[sparrowhe]

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

[sparrowhe]

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?

[uetcis]

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.

[pierr3]

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

[pierr3]

See section 5.9 here: https://wiki.archlinux.org/title/wayland

[uetcis]

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

[pierr3]

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

[uetcis]

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

[pierr3]

If you can rebuild locally, comment out the call to that function and see what happens - I will investigate in my VM

[sparrowhe]

After comment this line SDK::SDK() { /*this->buildServer();*/ } and rebuild the backend, then it was still sigfault.

> [email protected] 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!

[pierr3]

Which GPU are you both running and which drivers are you using?

[sparrowhe]

Which GPU are you both running and which drivers are you using?

#11 (comment)

+-----------------------------------------------------------------------------------------+
| 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.

[pierr3]

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.

[pierr3]

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.

[sparrowhe]

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?

[pierr3]

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 <kwhat/libuiohook#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 <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN7UK2OBCOFR4QQSAQSUU3Y74EI5AVCNFSM6AAAAABG4Z6WMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBUGI4TOMJRGU> . You are receiving this because you commented.Message ID: ***@***.***>

[pierr3]

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/

[pierr3]

Tracking in #211