I tried installing sway in dom0 using ‘sudo qubes-dom0-update sway’ and launched sway from lightdm. Checked that it was running Wayland, and funnily enough, it can run applications/programs from within dom0, but if I try to make it run then using qvm run or by launching the app menu from the command line, I get nothing. However, I know that on my previous computer on which I hade KDE installed, a kde Wayland session worked. Any idea how I could make this work?
Thanks
Wayland is not yet supported in Qubes OS:
Has this not changed in light of support for KDE Wayland sessions? I (in 4.3rc1) have adjusted the xdg autostart units to ensure that qubes-guid is passed the --kde flag, and that Xwayland-satellite is monkey-patched via LD_PRELOAD, but am still not seeing any DomU windows in Niri (looks like OP). I don’t see anything suspicious in the qubes-guid logs, though I haven’t checked the gui-agent logs inside a Qube yet.
I understand that KWin, like Mutter, can have some bespoke quirks, and that it might not be as simple as crawling the sources and trying to do what KWin does (to route through Xwayland) at runtime – but I’d like to know where the differences are, and unless someone with a background in the KDE Wayland Session effort chimes in, that’s the only place to start~
It should work, as long as you LD_PRELOAD the .so file on Xwayland.
Though Xwayland support for that was added not too long ago, so probably you need to be running 4.3.
(I am not certain about that and haven’t tried it with Xwayland-sattelite based compositors, only mutter)
I have had it working with mutter on Wayland.
If you don’t LD_PRELOAD, you get no qubes guid windows, but they work just fine if you do.
You need to LD_PRELOAD “”/usr/lib64/qubes-gui-daemon/shmoverride.so" when the compositor is launching Xwayland. (Seemed simply setting the variable when launching the compositor didn’t quite work last time I tried).
But how to do this probably differs for each compositor, as in the packaging for KDE they are using a KDE-specific approach.
I think it worked generally when I replaced /usr/bin/Xwayland with a script that launuches the real Xwayland binary put elsewhere, while setting the LD_PRELOAD.
Or you can simply add a small patch to the compositor when it launches Xwayland that sets the LD_PRELOAD. For example, in meta_xwayland_start_xserver function add “g_subprocess_launcher_setenv (launcher, “LD_PRELOAD”, “/usr/lib64/qubes-gui-daemon/shmoverride.so”, TRUE);” after creating the launcher for mutter.
Another issue is with the QUI tray widgets.
By default, they try to launch with GDK wayland backend on Wayland, which prevents them from even trying to Xembed themselves.
So you need to set GDK_BACKEND=x11 for those, I had set it in systemd service environment configuration for them, but I think they have very recently changed this upstream to always try x11 backend for them.
Also, I would guess the traditional style qubes notifications which are simply windows running in the apps would be very broken with Xwayland-sattelite using compositors, so you would need to use the recently added qubes notification proxy.
edit: see follow-up, hopefully none of this is relevent when i actually do as suggested >u<
Thank you! Filled with determination, I had another crack at it. Should probably link GUI virtualization | Qubes OS, for lurkers.
I stripped back my modifications to the XDG autostart units, ignoring qvm-start-daemon’s --kde flag for now and disabling Xwayland-related units so I can start them manualy (in both XDG-Autostart and the global-user service /usr/lib/systemd/user/xwayland-satellite.service), making sure to keep a Polkit daemon. I think narrowed my issue down to XAUTHORITY, which was not being set by SDDM. I switched back to LightDM, but that doesn’t setup Xauthority unless you’re starting an X11 session? Not my area of expertise, but I think we can fake something permissive…
$ export XAUTHORITY="$HOME/.Xauthority"
$ xauth add :0 . $(xxd -l 16 -p /dev/urandom)
$ systemctl stop --user app-qvm\\x2dstart\\x2ddaemon@autostart
# Nothing changes with `--kde` or if ran as root, which I did try bc of `root:qubes` perms on prior log files
$ /usr/bin/qvm-start-daemon --all --watch &
$ LD_PRELOAD=/usr/lib64/quibes-gui-daemon/shmoverride.so xwayland-satellite &
$ qvm-shutdown untrusted || true
$ qvm-run untrusted glxgears # ret 1
$ tail /var/log/qubes/guid.untrusted.log
Invalid MIT-MAGIC-COOKIE-1 key
# uhhh...
$ xhost +
access control disabled, clients can connect from any host
$ qvm-run untrusted glxgears
We get a window!! It’s blank white, but, goals! VSync’s correctly, too.
$ tail /var/log/qubes/guid.untrusted.log
Cannot obtain current desktop
Icon size: 128x128
Falling back to setting _NET_WM_USER_TIME on the root window
WARNING: Running setxkbmap against an Xwayland server
Created 0x1c00187(0x200003) ovr=0 x/y 0/0 w/h 100/100
XDestroyWindow 0x1c00187
cannot lookup 0x1c00187 in wid2windowdata
# [...]
set WM_NORMAL_HINTS for window 0x1c0018a to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x0)
set title for window 0x1c0018a
set class hint for window 0x1c0018a to (untrusted:Xfsettingsd, untrusted:xfsettingsd)
Created 0x1c0018b(0x200002) ovr=0 x/y -1/-1 w/h 1/1
Created 0x1c0018c(0x200003) ovr=0 x/y 0/0 w/h 10/10
Created 0x1c0018d(0xa00002) ovr=0 x/y 0/0 w/h 300/300
set WM_NORMAL_HINTS for window 0x1c0018d to min=0/0, max=0/0, base=0/0, inc=0/0 (flags 0x1)
set title for window 0x1c0018d
set title for window 0x1c0018d
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=0, w=300, h=300
MSG_WINDOW_DUMP for 0x1c0018d(0xa00002): 300x300, type = 0
xcb_shm_attach_fd failed for window 0x1c0018d(remote 0xa00002)
ErrorHandler: BadMatch (invalid parameter attributes)
Major opcode: 130 ()
Minor opcode: 6
ResourceID: 0x11c
Failed serial number: 986
Current serial number: 984
shmimage for 0x1c0018d(remote 0xa00002), x: 0, y: 0, w: 300, h: 300
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=0, w=300, h=300
shmimage for 0x1c0018d(remote 0xa00002), x: 0, y: 0, w: 300, h: 300
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=0, w=300, h=300
process_xevent_configure(synth 0) local 0x1c0018d remote 0xa00002, 1256/1348, was 300/300, xy 0/0 was 0/0
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=0, w=1256, h=1348
handle_configure_from_vm, local 0x1c0018d remote 0xa00002, 1256/1348, was 1256/1348, ovr=0 (ignored), xy 0/0, was 0/0
MSG_WINDOW_DUMP for 0x1c0018d(0xa00002): 1256x1348, type = 0
xcb_shm_attach_fd failed for window 0x1c0018d(remote 0xa00002)
ErrorHandler: BadMatch (invalid parameter attributes)
Major opcode: 130 ()
Minor opcode: 6
ResourceID: 0x11c
Failed serial number: 988
Current serial number: 987
shmimage for 0x1c0018d(remote 0xa00002), x: 300, y: 0, w: 956, h: 300
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=300, y=0, w=956, h=300
shmimage for 0x1c0018d(remote 0xa00002), x: 0, y: 300, w: 1256, h: 1048
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=300, w=1256, h=1048
shmimage for 0x1c0018d(remote 0xa00002), x: 0, y: 0, w: 1256, h: 1348
do_shm_update for 0x1c0018d(remote 0xa00002), after border calc: x=0, y=0, w=1256, h=1348
# [...]
xcb_shm_attach_fd failed for window 0x1c0018d(remote 0xa00002)
I’ve triple-checked that the running Xwayland-satellite has the LD_PRELOAD (via /proc/[...]/environ/output), but FWIW I didn’t see any log activity in Xwayland-satellite when I ran a foreground instance – qubesd logs look positive: I wouldn’t necessarily know if anything was missing but looks like it’s actively going down the happy-path, and the SHM errors probably indicate the remaining issue.
I do not have enough of an X11 background to make heads or tails of the xauth situation, but think I’ve learned enough that another long look at a running Plasma instance might be fruit-full, if only to get to this point at startup. Thank you for your insights!
(Seemed simply setting the variable when launching the compositor didn’t quite work last time I tried).
But how to do this probably differs for each compositor, as in the packaging for KDE they are using a KDE-specific approach.
I think it worked generally when I replaced /usr/bin/Xwayland with a script that launuches the real Xwayland binary put elsewhere, while setting the LD_PRELOAD.
On-the-go now, but think you’re spot on: I should be prefixing Xwayland-satellite’s PATH with /usr/libexec/qubes/wrappers (per qubes-gui-daemon#b42f1ab) rather than setting LD_PRELOAD on it directly. Something I definitely learned during background-reading and promptly hopefully! glossed over. Between that and today’s XAUTH investigation (perhaps obsolete, post-patch, to fit your widow-less, rather than blank-window-ed, failure-case in mutter?), I should be set! Thx again!
Posting from Niri in Dom0! Yay! (4.3rc1)
For a minute I was worried I wasn’t out of the weeds, because it took a few tries – had to do a full restart after a Qubes daemon died, and I managed to segfault Xwayland (but thankfully don’t need to post logs >u<). I did need to set XAUTHORITY and run xhost + after starting Xwayland-satellite, which I understand isn’t best practice, or I saw Authorization required, but no authorization protocol specified (the initial hurdle). I’m still going to take a closer look at what Plasma is doing before staging this session to start-up without fiddling, will see what I can do~
I’m still going to take a closer look at what Plasma is doing before staging this session to start-up without fiddling, will see what I can do~
I tried my best to put eg. Autostarts and profile configs back to stock, but Plasma wouldn’t start and I don’t have time to roll dom0 back to an ol’ snapshot rn >u<
I think I’ve done my part in demonstrating the latest updates on this
Shared more info and some short clips in another relevant thread, sorry to bump them both but I think a lot of traffic comes here from search and that the cross-links will be helpful to the broader crowd c: