Qt apps do not show interface inside bottle

[roachsinai]

Windows version (build number):
Kernel: 10.0.22000.0 282

Linux distribution:
ArchWSL

Genie version:
1.44

Describe the bug

Before run genie -i can run python script like opencv to show images.

After belows step:

genie -i
ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

Failed to show image, only get a black window:

But applications like xeyes can run and show successfully.

Confirm that you are running inside the bottle:
outside

To Reproduce
Steps to reproduce the behavior:
step1: genie -i
step2: ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

if no step2 even xeyes can not show.

step3: write a script like:

import cv2
cap = cv2.VideoCapture("example.mp4")
while True:
    key = cv2.waitKey(10)
    ret, frame = cap.read()
    cv2.imshow("", frame)
    if key == 27:
        break

cap.release()
cv2.destroyAllWindows()

step4: run the python script

Expected behavior
Play example.mp4 successfully.

Additional context
Can't use C++ to call opencv play vedio, either.
Python script can't play mp4 but can draw a image, like below code works well:

https://matplotlib.org/stable/gallery/lines_bars_and_markers/simple_plot.html

I confirm that I have read the ENTIRE supplied readme file and checked for relevant information on the repository wiki before raising this issue, and that if the solution to this issue is found in either location, it will be closed without further comment:

• Yes.

[cerebrate]

It looks like you're trying to run the script outside the bottle, which is not a supported configuration.

Can you reproduce the issue inside the bottle?

[roachsinai]

@cerebrate Thanks for your reply!

owin ~/c/p/YOLOBlaze  master » genie -i
Waiting for systemd....!!!!!!!!!!!!!!
owin ~/c/p/YOLOBlaze  master » ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix
owin ~/c/p/YOLOBlaze  master » genie -s
owin-wsl 🧞 ~/c/p/YOLOBlaze  master » genie -b
inside
owin-wsl 🧞 ~/c/p/YOLOBlaze  master » ./build/Debug/YOLOBlaze
1:blob time: 6.052ms
2:detect model run time: 658.938ms
3: big for: 0.162ms
4:NMS time: 0.06ms
total time: 665.212ms
-------yolo model taken : 686 ms------------
-------yolo face model taken : 0 ms------------
Onnx run time is: 0.873635s
-------landmark model taken : 1243 ms------------
-------all taken : 1930 ms------------
qt.qpa.xcb: could not connect to display :0
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, xcb.

zsh: abort      ./build/Debug/YOLOBlaze
owin-wsl 🧞 ~/c/p/YOLOBlaze  master » xeyes
Error: Can't open display: :0

Seems can reproduce it inside bottle.

And after this even I shutdown genie and relink X11-unix wslg not work again as I have to reboot it.

[cerebrate]

Curious. You shouldn't need this step when running inside the bottle:

ln -s /mnt/wslg/.X11-unix /tmp/.X11-unix

Since genie installs the wslg-xwayland.service (triggered automatically by wslg-xwayland.socket) to automatically proxy the X socket for you, and overrides user-runtime-dir@1000.service to do the same thing for the Wayland access points.

Can you try it again without that step and see if it's still reproducible inside the bottle? If it is, could you then let me have the output of systemctl status for the three systemd units mentioned above?

[roachsinai]

Yeah, can reproduce it in bottle with out create link of X11-unit,

Output of systemctl status:

owin-wsl 🧞 ~/c/p/YOLOBlaze  master » systemctl status
● owin-wsl
    State: running
     Jobs: 0 queued
   Failed: 0 units
    Since: Thu 2021-11-11 17:16:36 CST; 1min 49s ago
   CGroup: /
           ├─user.slice
           │ └─user-1000.slice
           │   ├─user@1000.service
           │   │ └─init.scope
           │   │   ├─626 /usr/lib/systemd/systemd --user
           │   │   └─627 (sd-pam)
           │   └─session-c1.scope
           │     ├─ 621 /bin/zsh -l
           │     ├─ 639 (sd-pam)
           │     ├─1082 systemctl status
           │     └─1083 less
           ├─init.scope
           │ └─1 systemd
           └─system.slice
             ├─wslg-xwayland.service
             │ └─1004 /lib/systemd/systemd-socket-proxyd /mnt/wslg/.X11-unix/X0
             ├─systemd-udevd.service
             │ └─40 /usr/lib/systemd/systemd-udevd
             ├─cronie.service
             │ └─101 /usr/bin/crond -n
             ├─systemd-journald.service
             │ └─29 /usr/lib/systemd/systemd-journald
             ├─systemd-machined.service
             │ └─620 /usr/lib/systemd/systemd-machined
             ├─console-getty.service
             │ └─107 /sbin/agetty -o -p -- \u --noclear --keep-baud console 115200,38400,9600 xterm-256color
             ├─dbus.service
             │ └─102 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
             ├─system-getty.slice
             │ └─getty@tty1.service
             │   └─109 /sbin/agetty -o -p -- \u --noclear tty1 linux
             └─systemd-logind.service
               └─103 /usr/lib/systemd/systemd-logind

[github-actions]

There has been no activity on this issue for over 60 days. If there is no further activity within 7 days from this message, it will be automatically closed.

[rschoon]

This looks a lot like behavior seen with #175

[cerebrate]

This seems to be a problem with Qt apps in general. Unfortunately, despite many and various attempts, I've not been able to determine why it happens or develop a fix. Still being worked on, though.

[cerebrate]

Apparently today I am two for two on declaring bugs intractable and then immediately tracting them.

Turns out Qt has an incompatibility with the elegant way of providing access to the WSLg X11 socket. Kluging it instead makes it work. Fix will be in 2.4.