Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
eteq opened this issue Oct 8, 2024 · 6 comments
Open

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

eteq opened this issue Oct 8, 2024 · 6 comments
Labels
bug Something isn't working

Comments

@eteq
Copy link

eteq commented Oct 8, 2024

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

@eteq eteq changed the title Screenshots dont scale in COSMIC DE (alpha) SWWW backgrounds dont scale properly in COSMIC DE (alpha) Oct 8, 2024
@LGFae
Copy link
Owner

LGFae commented Oct 27, 2024

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?

@LGFae LGFae added the bug Something isn't working label Oct 27, 2024
@YaLTeR
Copy link

YaLTeR commented Oct 28, 2024

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
Copy link
Author

eteq commented Oct 28, 2024

@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
Copy link
Owner

LGFae commented Oct 28, 2024

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

@eteq
Copy link
Author

eteq commented Oct 28, 2024

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
Copy link
Owner

LGFae commented Oct 28, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants