LGFae / swww

A Solution to your Wayland Wallpaper Woes
GNU General Public License v3.0
2.38k stars 70 forks source link

SWWW backgrounds dont scale properly in COSMIC DE (alpha) #368

Open eteq opened 1 month ago

eteq commented 1 month ago

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.

cut_screenshot_cosmic_swww

LGFae commented 2 weeks 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?

YaLTeR commented 2 weeks ago

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.

eteq commented 2 weeks ago

@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!

LGFae commented 2 weeks ago

A cargo build without any flags will build a debug version.

eteq commented 2 weeks ago

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 .

LGFae commented 2 weeks ago

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.