Open eteq opened 1 month ago
It might be an implementation detail of COSMIC DE in particular. If you have the time, it would be useful to build a debug version of swww
and post the log output here. One thing that comes to mind is maybe COSMIC DE sends some wayland events in a different order and it's screwing up our custom wayland implementation. In any case, if swaybg
works it's likely that the problem is in our side.
EDIT: I just remembered: are you using the latest git version or the latest release?
FWIW for me on niri sometimes after switching output scales, swww scale will be wrong (until I restart it). So maybe there's some general bug in swww logic.
@LGFae
build a debug version of swww and post the log output here
Definitely can do this but just to confirm, do you mean just a build with cargo build --debug
, or is there some magic environment variable I need to set as well?
are you using the latest git version or the latest release?
Latest release, but I will pull git main to do the above!
A cargo build
without any flags will build a debug version.
So I tried on main
, and I got a completely different error on COSMIC:
0ms [DEBUG] Initialization: first callback done
thread 'main' panicked at daemon/src/wayland/globals.rs:184:59:
called `Result::unwrap()` on an `Err` value: Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
0ms [DEBUG] Initialization Over
although the same build seems to work just fine on sway...
So I checkout out the v0.9.5 tag and it built happily in debug mode and gave the following (with the same behavior I screenshotted in the description above):
15:41:22 [DEBUG] (main) swww_daemon: Made socket in "/run/user/1000/swww-wayland-1.socket" (pathname) and initialized logger. Starting daemon...
15:41:22 [INFO] (main) Selected wl_shm format: Xbgr8888
15:41:22 [DEBUG] (main) swww_daemon: New output: wl_output@8
15:41:22 [INFO] (main) Initialization succeeded! Starting main loop...
15:41:22 [DEBUG] (main) swww_daemon: output wl_output@8 position: 0,0
15:41:22 [DEBUG] (main) swww_daemon::wallpaper: Output wl_output@8 name: DP-1
15:41:22 [DEBUG] (main) swww_daemon::wallpaper: Output wl_output@8 description: Unknown - Dell AW3423DW - DP-1
15:41:22 [DEBUG] (main) swww_daemon: Output wl_output@8: Surface Enter
15:41:22 [DEBUG] (transition) swww_daemon::wallpaper: output Some("DP-1") - drawing: image: /usr/share/backgrounds/archlinux/archwave.png
15:41:22 [DEBUG] (transition) swww_daemon::animations::transitions: Starting transitions
15:41:22 [INFO] (transition) BumpPool with: 1 buffers. Size: 1200Kb
15:41:22 [DEBUG] (transition) swww_daemon::animations::transitions: Transitions finished
If the issue on main
is distinct (which seems likely) I can make a separate issue for that if you like @LGFae .
If the issue on main is distinct (which seems likely) I can make a separate issue for that if you like
No no, this is perfect. If the issue had been fixed on the main
branch I would simply ask you to use that and say this is already fixed. But it seems we have an actual problem here somewhere.
I was testing out COSMIC DE alpha 2 (on Arch Linux, if it matters), and saw some odd behavior with
swww
, screenshot below. Basically, the background I select for swww does not scale to the full size of the desktop, but rather appears as a sort of thumbnail in the upper-left.I can provide more debug info if it's helpful, just not sure what are the most useful logs/debug flags/etc to set. I also don't know if this is really some bug in the COSMIC implementation of some wayland protocol, but I figure someone here will know if so and can point me to what component would be the culprit if so.
Note, on the same machine I've gotten SWWW to work properly in KDE Plasma(Wayland) and Niri so I'm quite confident my SWWW install is correct.
swaybg
also works correctly in COSMIC, so it's not a global problem with COSMIC's implementation... Hence why I'm starting here first.