SWWW backgrounds dont scale properly in COSMIC DE (alpha)

[eteq]

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.

[LGFae]

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]

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]

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

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

[eteq]

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]

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.

[LGFae]

Possibly fixed with PR #439. If you guys were willing to test it, I'd appreciate it.

[YaLTeR]

Btw not sure if it's the same as this issue, but I noticed before that swww used the first advertised wl_output mode rather than the current mode, which made it break after changing monitor resolution/scale in niri.

[LGFae]

@YaLTeR Are you sure that's really the issue? swww always uses the latest advertised mode:

    fn mode(
        &mut self,
        sender_id: ObjectId,
        _flags: wayland::wl_output::Mode,
        width: i32,
        height: i32,
        _refresh: i32,
    ) {
        for wallpaper in self.wallpapers.iter() {
            let mut wallpaper = wallpaper.borrow_mut();
            if wallpaper.has_output(sender_id) {
                wallpaper.set_dimensions(width, height);
                break;
            }
        }
    }

[YaLTeR]

It should be using the current mode though: https://wayland.app/protocols/wayland#wl_output:enum:mode:entry:current

[LGFae]

Well, sure, but the protocol says that non current mode are deprecated. I could add a match statement preventing it from using anything other can current, but I don't think the compositor should be issuing non-current mode events.

[LGFae]

Solved by #467