lgfae / swww Goto Github PK
View Code? Open in Web Editor NEWA Solution to your Wayland Wallpaper Woes
License: GNU General Public License v3.0
A Solution to your Wayland Wallpaper Woes
License: GNU General Public License v3.0
Hi, I've installed swww out of curiosity, and everything has been okay except the title of this issue.
I have noticed how wallpapers get set to a 1280x720 resolution (as reported by swww query
)¹, even though my native res is 2560x1440 and so is the wallpaper's.
They look pixelated, same way that xwayland programs look due to scaling issues between sway
trying to go for e.g 150% but x11 staying at 100%, giving it the same pixelated effect.
I've compiled this program using Nix and made a derivation for it, including a module and systemd service here (line 394).
The systemd services successfully start, wallpaper gets set, so the binary works as well. If I set any random image as a wallpaper using e.g swww img random.png
, it gets the same issue.
¹ swww query
returns eDP-1 = 1280x720, currently displaying: image: "bg3.png"
Distro: NixOS (22.11.20220824.b784c5a)
WM: Sway
Device: ThinkPad T480
Display: QHD (2560x1440)
swww -V
: swww 0.4.2
Here is the error
warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
warning: ran fix_zsh_completion.sh script.
Compiling swww v0.6.0 (/home/luxluth/Softwares/swww)
Compiling swww-daemon v0.1.0 (/home/luxluth/Softwares/swww/daemon)
/home/luxluth/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-d0d50995ab5830a5.so(+0x30e3f33)[0x7f2282ee3f33]
/usr/lib/libc.so.6(+0x38a00)[0x7f227fc51a00]
[0x7f2266bf9b8f]
error: could not compile `swww-daemon`
Caused by:
process didn't exit successfully: `rustc --crate-name swww_daemon --edition=2021 daemon/src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=3391a53e699c0a8e -C extra-filename=-3391a53e699c0a8e --out-dir /home/luxluth/Softwares/swww/target/release/deps -C linker=clang -C strip=symbols -L dependency=/home/luxluth/Softwares/swww/target/release/deps --extern keyframe=/home/luxluth/Softwares/swww/target/release/deps/libkeyframe-ce70edb7e446baea.rlib --extern log=/home/luxluth/Softwares/swww/target/release/deps/liblog-786fbf621861e7e9.rlib --extern simplelog=/home/luxluth/Softwares/swww/target/release/deps/libsimplelog-10ce44a333451d4c.rlib --extern smithay_client_toolkit=/home/luxluth/Softwares/swww/target/release/deps/libsmithay_client_toolkit-9720adc25f2b5202.rlib --extern utils=/home/luxluth/Softwares/swww/target/release/deps/libutils-f8f874f9639a6a2d.rlib -C link-arg=-fuse-ld=mold -L native=/usr/lib -L native=/home/luxluth/Softwares/swww/target/release/build/lzzzz-0d4c38b91445ca09/out` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
/home/luxluth/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/librustc_driver-d0d50995ab5830a5.so(+0x30e3f33)[0x7f2be3ee3f33]
/usr/lib/libc.so.6(+0x38a00)[0x7f2be0acba00]
[0x7f2bc3bf9d8f]
The following warnings were emitted during compilation:
warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
warning: ran fix_zsh_completion.sh script.
error: could not compile `swww`
Caused by:
process didn't exit successfully: `rustc --crate-name swww --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=35a396be4b4feabe -C extra-filename=-35a396be4b4feabe --out-dir /home/luxluth/Softwares/swww/target/release/deps -C linker=clang -C strip=symbols -L dependency=/home/luxluth/Softwares/swww/target/release/deps --extern clap=/home/luxluth/Softwares/swww/target/release/deps/libclap-5143ad88642ef8ce.rlib --extern fast_image_resize=/home/luxluth/Softwares/swww/target/release/deps/libfast_image_resize-2c348cceaaaff75e.rlib --extern image=/home/luxluth/Softwares/swww/target/release/deps/libimage-95628370f2e2e1ad.rlib --extern rand=/home/luxluth/Softwares/swww/target/release/deps/librand-3c00f24cb7f97880.rlib --extern utils=/home/luxluth/Softwares/swww/target/release/deps/libutils-f8f874f9639a6a2d.rlib -C link-arg=-fuse-ld=mold -L native=/home/luxluth/Softwares/swww/target/release/build/lzzzz-0d4c38b91445ca09/out` (signal: 11, SIGSEGV: invalid memory reference)
cargo build
works fine
Hi!
I'm fine tuning an swww integration with sunpaper to allow smooth transitions between time-of-day wallpaper changes. (thank you, btw, this is awesome. I'd previously been using hacky oguri solution for animation that never really worked well)
I'm not sure I fully understand the role of step in the animation process. I'm looking for a sweet spot of longish transition but smooth. Using 3 fps now and 3 step.
Any assistance is appreciated.
Hello,
Thanks for this application. I installed it according to the readme instruction and added the command "swww init && swww IMG /path/to/image/file" to background command in wayfire.ini. when I logged out and logged in again it didn't work. I separated the two commands and it still did not work.
So I decided to try the command in the terminal and it worked. But after rebooting it didn't work again even in terminal giving the above error message. I can't figure out what went wrong or how to go about debugging.
I also noticed that the error keeps repeated while the command is active. Any help is appreciated.
Thanks
I tried putting everything into .bash_profile but it didn't work.
The protocol for native fractional scale has been merged upstream as wp-fractional-scale-v1.
It is also available in wayland-rs.
Implementing this could result in sharper images when using fractional scale, and less overhead (since the compositor won't need to resize as much).
I've been putting this off long enough. More than one person has had trouble understanding the meaning of --transition-step
. We need to have a proper, good explanation for it, in some place where it is easier to read than buried deep inside swww img help
.
I believe clap
can auto generate man-pages for us. We can try that and see how it goes.
what do you think about this idea, maybe swww could save the location of the last image used after it is killed, and then use that image when the daemon is initialized again?
Using the command below
swww img wallpaper.jpg && swww img wallpaper.jpg
results in error:
Error: "Failed to receive answer: io error: Resource temporarily unavailable (os error 11)"
and higher than normal memory usage sometimes above 200M
after this, using the command
swww kill
then fails with the same error.
I then have to kill the daemon and remove the socket manually.
PID: 81438 (swww-daemon)
UID: 1000 (kyle)
GID: 985 (video)
Signal: 6 (ABRT)
Timestamp: Sat 2023-01-21 09:19:45 CST (2min 36s ago)
Command Line: swww-daemon
Executable: /usr/bin/swww-daemon
Control Group: /user.slice/user-1000.slice/session-11.scope
Unit: session-11.scope
Slice: user-1000.slice
Session: 11
Owner UID: 1000 (kyle)
Boot ID: 92700ab9320f43cbb885e4fbeb2564e5
Machine ID: 0ab96a8a596c4eaab4191e79cb217e43
Hostname: archlinux
Storage: /var/lib/systemd/coredump/core.swww-daemon.1000.92700ab9320f43cbb885e4fbeb2564e5.81438.1674263985000000.zst (present)
Size on Disk: 3.4M
Message: Process 81438 (swww-daemon) of user 1000 dumped core.
Stack trace of thread 81892:
#0 0x00007f70feea264c n/a (libc.so.6 + 0x8864c)
#1 0x00007f70fee52938 raise (libc.so.6 + 0x38938)
#2 0x00007f70fee3c53d abort (libc.so.6 + 0x2253d)
#3 0x0000558dc6e81cf7 n/a (swww-daemon + 0x5ecf7)
#4 0x0000558dc6e81ce6 n/a (swww-daemon + 0x5ece6)
#5 0x0000558dc6ebcca6 n/a (swww-daemon + 0x99ca6)
#6 0x0000558dc6ebef0f n/a (swww-daemon + 0x9bf0f)
#7 0x0000558dc6ebeb84 n/a (swww-daemon + 0x9bb84)
#8 0x0000558dc6ebeaec n/a (swww-daemon + 0x9baec)
#9 0x0000558dc6ebeac1 n/a (swww-daemon + 0x9bac1)
#10 0x0000558dc6e2fdd2 n/a (swww-daemon + 0xcdd2)
#11 0x0000558dc6e4eb6b n/a (swww-daemon + 0x2bb6b)
#12 0x0000558dc6e53990 n/a (swww-daemon + 0x30990)
#13 0x0000558dc6ebf9b5 n/a (swww-daemon + 0x9c9b5)
#14 0x00007f70feea08fd n/a (libc.so.6 + 0x868fd)
#15 0x00007f70fef22d20 n/a (libc.so.6 + 0x108d20)
Stack trace of thread 81438:
#0 0x00007f70fef22356 epoll_wait (libc.so.6 + 0x108356)
#1 0x0000558dc6e5a6dc n/a (swww-daemon + 0x376dc)
#2 0x0000558dc6e670f6 n/a (swww-daemon + 0x440f6)
#3 0x0000558dc6e4a5d3 n/a (swww-daemon + 0x275d3)
#4 0x0000558dc6e6dd4c n/a (swww-daemon + 0x4ad4c)
#5 0x00007f70fee3d290 n/a (libc.so.6 + 0x23290)
#6 0x00007f70fee3d34a __libc_start_main (libc.so.6 + 0x2334a)
#7 0x0000558dc6e329a5 n/a (swww-daemon + 0xf9a5)
ELF object binary architecture: AMD x86-64
swww query
(eDP-1: 2133x1199, scale: 2, currently displaying: color: 000
)
Scale in Hyprland set to 1.2
Would it be possible to allow an image to be spanned over multiple monitors?
I could try to implement this myself. I would just need a hint, where in the code the image is drawn on a specific output.
I gues I would just need to split the image data into n
chunks and then send them to the appropriate outputs.
I use swww
with the following script:
#!/usr/bin/env sh
swww init
while true;
do
echo "Changing image"
swww img $(~/.config/sway/scripts/wallpaper.sh) --transition-step 3
sleep 55
done
where wallpaper.sh
returns the path of a random wallpaper.
Occasionally, I observe the following bug:
swww
works normally.swww img
command.swww img
command gets issued.swww
again works normally (until the bug appears again after some later img
command).Hello. Greetings. I have fun using your wallpaper daemon. I can't believe after it caches a 315MB high-quality gif file, it hovers around 15% cpu usage (Yes I know I can use a smaller one like your demo gif so it hovers around 2-8% but still wow). I have submitted this to the openSUSE X11:Wayland repository to share your tool.
Again. Thanks for creating this wonderful tool! 🥳
Hello! I am grateful for this amazing program and love everything about it
I have a small library of GIFs that I use to switch wallpapers from time to time to keep things fresh.
However, I have noticed a peculiar issue where GIFs with smaller sizes (<1MB) sometimes, or don't load at all at startup. However, GIFs with relatively larger sizes (say 2MB and greater) have no issues whatsoever loading in on startup.
These 2 GIFs are of different resolutions.
Do note, that once I manually execute swww img /PATH/TO/GIF
, the wallpaper sets itself, regardless of the resolution
I only use a single monitor(1600x900), with my laptop monitor being disabled by the WM itself.
I am using hyprland
WM with the following lines in my config file which correspond to my wallpaper set up
exec-once = swww init
exec-once = swww img /PATH/TO/GIF
In both the cases, I have confirmed that swww init
was running. I am also going to attach the GIFs in question that I have used to test my theory
This GIF doesn't work
This GIF works
I am not sure if I can provide any log files, as afaik, swww
doesn't provide any logging options
hi there :) thanks for your work.
I am trying to build. new with rust, so forgive me if this is a simple issue.
jaymedavis@jayme-port-fedora swww]$ cargo build --release
Compiling smithay-client-toolkit v0.16.0
Compiling swww v0.7.2 (/home/jaymedavis/Source/swww)
Compiling keyframe v1.1.1
Compiling image v0.24.5
Compiling fast_image_resize v2.5.0
warning: generated shell completion file: "completions/swww.bash"
warning: generated shell completion file: "completions/_swww"
warning: generated shell completion file: "completions/swww.fish"
warning: generated shell completion file: "completions/swww.elv"
error: failed to run custom build command for `smithay-client-toolkit v0.16.0`
Caused by:
process didn't exit successfully: `/home/jaymedavis/Source/swww/target/release/build/smithay-client-toolkit-fccdcef68e554481/build-script-build` (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=XKBCOMMON_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=XKBCOMMON_STATIC
cargo:rerun-if-env-changed=XKBCOMMON_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
--- stderr
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"xkbcommon\"` did not exit successfully: exit status: 1\nerror: could not find system library 'xkbcommon' required by the 'smithay-client-toolkit' crate\n\n--- stderr\nPackage xkbcommon was not found in the pkg-config search path.\nPerhaps you should add the directory containing `xkbcommon.pc'\nto the PKG_CONFIG_PATH environment variable\nPackage 'xkbcommon', required by 'virtual:world', not found\n"', /home/jaymedavis/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.16.0/build.rs:5:49
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
libxkbcommon is installed. just pulled source and ran cargo build --release
. what am I missing?
cheers
@flick0 since you are the main contributor here
I think nothing illustrates this better than a video. The options used here are:
--transition-step 1 --transition-type any --transition-duration 5 --transition-fps 255 --transition-bezier=0.85,0,0.15,1
Even using "no beziers" it is still pretty slow.(--transition-bezier=0,0,1,1
)
I know that bezier is a bit performance heavy, but compared to the last release(0.5.0), it's noticeably faster than both of the above
Options used here are: --transition-speed 20 --transition-type any --transition-fps 255
Currently(at least from what I've observed), swww will put every image you load into ram, which is not great since I change my wallpapers quite commonly
I hope that there could be a subcommand that will "clean" everything except the currently loaded wallpaper
Maybe sth like cleancache
swww reports wrong dimensions:
> swww query
DP-2 = 4586x1920, currently displaying: color: 000
Sway reports the correct sizes:
> swaymsg -t get_outputs
Output DP-2 'Ancor Communications Inc ROG PG348Q #ASMuhJCcVsHd' (focused)
Current mode: 3440x1440 @ 59.973 Hz
Position: 0,0
Scale factor: 1.500000
Scale filter: linear
Subpixel hinting: unknown
Transform: normal
Workspace: 2 2:二
Max render time: off
Adaptive sync: disabled
Available modes:
3440x1440 @ 59.973 Hz
3440x1440 @ 49.987 Hz
1024x768 @ 60.004 Hz
800x600 @ 60.317 Hz
640x480 @ 60.000 Hz
640x480 @ 59.940 Hz
Output eDP-1 'Sharp Corporation 0x148B Unknown' (inactive)
Available modes:
3840x2160 @ 59.997 Hz
Pointed out by @max-ishere in #86, because the client sends the image before the full gif processing is complete, swww
will sometimes "hang" in the first frame, which can be jarring in some scenarios.
The idea is to do all the reading, decoding, and resizing of the image in the client, so that the daemon just have to worry about animating it.
Benefits:
cli
, or the image
crate, etc. Also, the client doesn't have to depend on smithay
)criterion
benchmarks on our compression code (currently I am doing that in a separate, personal project)Problems: I've tried this a long time ago, but wasn't very familiar with cargo workspaces, which is why I abandoned the idea back then.
The speed problem can be mitigated by first sending just the first frame, and then decoding, compressing, and serializing the rest of the gif's frame, as the daemon plays out the transition animation. Furthermore, we can assure the user the process isn't hanging by printing a progress report, which can be silenced with a --quiet
flag. This, of course, comes at the price of even more complex communication between the processes.
Finally, this would represent a big breaking change to all packagers. They would have to rewrite their packaging scripts (which would now install 2 binaries instead of 1). For the end user, things would be more or less the same, swww init
would simply call the daemon instead of forking.
Overall, this is very complicated, but I think the benefits are worth it. I will see if I can implement it this December.
I use wayland/wayfire on Arch , it was working fine with swww-git version , previously using swww from aur was throwing error like cache path not found but after using swww-git version it resolved , it was working fine but when i logout from my Wms using loginctl and logged back it did not start ,
i tried ,
swww init
but not starting daemon :
WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited
Error: "Failed to receive answer: io error: Connection reset by peer (os error 104)"
throwing this error
i tried removing swww.socket but not worked .
Hi!
I like your software and I had noticed that it didn't have an AUR package.
So I decided to learn how to package software for AUR, I don't know if it is supposed to be done this way but it installs it with completions.
Feel free to mention it in README.md
https://aur.archlinux.org/packages/swww
I had enabled notifications for releases, so I can update the package when you release a new version.
Since updating to the latest version, a week or two ago. I don't know for sure what the old version i was using was.
The fade-in animation swww used to have when setting new wallpapers stopped working all of a sudden, so i had to change my configs to use other animations, which seem to work normally.
When using the command manually, i noticed it gave me an error: failed to get cache path: failed to create cache_path: No such file or directory (os error 2)
.
Looked up the man pages and saw it would look for cache files in $XDG_CACHE_HOME/swww
or $HOME/.cache/swww
. ~/.cache/swww
seemed to not exist so i made a new folder with the same name: nothing changed.
I didn't have XDG_CACHE_HOME
set, so i used XDG_CACHE_HOME=~/.cache/ swww img <PATH>
to fix the issue, which worked in the sense that it stopped giving me the warning about the cache path, but still couldn't get the fade-in animation working.
First off, great project.
I've been trying to build swww on my M1 Mac running Asahi Linux today but it fails with the following error message in release
Both operands to a binary operator are not of the same type!
%7198 = xor i64 %7197, i32 4
in function _ZN5image2io14free_functions12load_decoder17h972a54ccb2943d7eE
LLVM ERROR: Broken function found, compilation aborted!
error: could not compile `swww`
Caused by:
process didn't exit successfully: `rustc --crate-name swww --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=313bff2c136129f8 -C extra-filename=-313bff2c136129f8 --out-dir /home/curtisy/swww/target/release/deps -C strip=symbols -L dependency=/home/curtisy/swww/target/release/deps --extern bincode=/home/curtisy/swww/target/release/deps/libbincode-3471bfd3a21c41ad.rlib --extern clap=/home/curtisy/swww/target/release/deps/libclap-b0083cad16eb3bb1.rlib --extern fast_image_resize=/home/curtisy/swww/target/release/deps/libfast_image_resize-6ffcf43ef1ad24bd.rlib --extern fork=/home/curtisy/swww/target/release/deps/libfork-a88127e95e4d0aac.rlib --extern image=/home/curtisy/swww/target/release/deps/libimage-1be0f6cd5a85dbe3.rlib --extern keyframe=/home/curtisy/swww/target/release/deps/libkeyframe-fa0b216abfb58feb.rlib --extern lazy_static=/home/curtisy/swww/target/release/deps/liblazy_static-3be040a087e9797f.rlib --extern log=/home/curtisy/swww/target/release/deps/liblog-48f21aabe46af05d.rlib --extern lzzzz=/home/curtisy/swww/target/release/deps/liblzzzz-bb8df0835a92e3a7.rlib --extern rand=/home/curtisy/swww/target/release/deps/librand-00b8660841df70ef.rlib --extern serde=/home/curtisy/swww/target/release/deps/libserde-bec4c4a54a6d005a.rlib --extern simplelog=/home/curtisy/swww/target/release/deps/libsimplelog-da9c39d74fa6aed7.rlib --extern smithay_client_toolkit=/home/curtisy/swww/target/release/deps/libsmithay_client_toolkit-1bbbebdc277ae777.rlib -L native=/home/curtisy/swww/target/release/build/lzzzz-ee97ccfbf62b1f56/out -L native=/usr/lib` (exit status: 101)
cargo build --release --verbose 20,552 user 0,091 system 99% cpu (20,677 wasted time).
When I disable lto in Cargo.toml, it seems to be working fine, so it's not a huge issue. Would be great if it worked out of the box though, so I could use the AUR.
If there's anything I can do to help troubleshoot, please let me know.
When setting image with a big disk size such as 4K wallpapers.
I used this one: https://www.pexels.com/photo/bird-s-eye-view-of-city-2246476/
I get this error before the wallpaper gets set:
Error: "Failed to receive answer: io error: Resource temporarily unavailable (os error 11)"
The wallpaper still gets displayed correctly.
Hi, noob question here... never compiled with cargo.
I get this: is listed in workspace’s default-members but is not a member.
Clear renders a single colour, so single-pixel-buffer is ideal for it. It's a rather new protocol, and, from the description:
Some use-cases include drawing background surfaces or toplevel decorations.
See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/104
Even for compositors where the new protocol is not supported, using a 1x1px buffer and wp_viewporter should reduce some unnecessary memory usage.
Hello, thanks for the great app ! Is it possible to add an option to automatically show wallpaper on newly connected monitor ?
I'm Not sure if it's intended behavior, so i'll refrain from assigning a label.
Upon physically powering off a screen, swww doesn't kill the daemon but unsets itself. On screen powerup i need to manually use the swww img command to set the image again.
Is it possible to store the loaded image and when swww detects a screen powering on (and thus swww query returns the screen data) to autoload what was previously on that screen?
I have a gif which has a ~1min duration, and during this time, the CPU fly at 100%.
Is there a way to pre-cache :
I'm unsure about possibilities, but this can avoid my CPU to be 100% at my computer start for~1min
First mention: #93 (comment)
#93
swww img any_gif_doesnt_matter.gif
GIF may play for less than a second and then stops.
Calling swww clear
only "unpauses" the GIF for a short instant.
Restart the daemon with swww kill ; swww init
Calling swww img
many times concurrently? It is hard to figure out as of now.
Since the exact causes are unknown and the issue does not happen often I consider the priority to be low. This may only affect users that run swww on gifs very frequently (e.g. to chain gifs or because 2 swww scripts are running at the same time).
I decided to write this in order to clarify some things I wrote in the README.
First of all, I already changed the code so that adding different types of transitions will be fairly easy. As soon as some ideas come to me, I'll probably start doing those.
Second, and more importantly, the README accuses the possibility of a memory leak in the Caveats/Limitations section. As I have said, I couldn't figure out precisely what's causing it.
Now, I haven't actually put a lot of time into this because the smithay-client-toolkit (and wayland-rs in general) is currently getting a large overhaul (see here). In fact, one of the things that have changed is a memory leak in backend-sys. Since we depend on sctk, it is entirely possible that the major changes it is currently going through will cause big changes in our current code as well, so it seems sort of pointless to go crazy with optimizations right now. Furthermore, there is also the possibility that the culprit is actually the image crate. Though, as I've said, I haven't dug deep enough to be sure either way.
The plan is to wait for the sctk version, update the code, and THEN investigate whether or not we have a leak. This issue will be closed once that has been done.
Currently the speed of the transition must be configured via --transition-step
and --transition-speed
. Tweaking these values require some pretty delicate understanding of the how transitions are implemented, keeping in mind screen resolution, and possibly some basic math.
I believe the current approach is designed this way since it directly exposes the internals of the transitions implementations.
I'd like to propose merging these into a --transition-duration
flag, which merely takes an integer with the transition duration in milliseconds. This is something a lot "friendlier" and handles just one value that's very simple to understand.
The correct values for transition-speed
and transition-step
can be calculated based on --transition-duration
and --transition-fps
.
I believe the error:
$ swww img example.gif
failed to get cache path: failed to create cache_path: No such file or directory (os error 2)
is caused by utils/communication.rs:324.
I tried to create .cache/swww
but it still gives me this error.
$ stat $HOME/.cache/swww
File: /home/max_ishere/.cache/swww
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: 254,2 Inode: 395962 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 1000/max_ishere) Gid: ( 1000/max_ishere)
Access: 2023-02-19 17:20:30.772317103 +0200
Modify: 2023-02-19 17:20:30.772317103 +0200
Change: 2023-02-19 17:20:30.772317103 +0200
Birth: 2023-02-19 17:20:30.772317103 +0200
I dont know if this is related but after calling swww clear
and then displaying a gif (swww img example.gif
) is hangs on the first frame for quite some time. Would be nice if the first frame would only appear after swww is ready to play the entire gif.
I've noticed that if you display an image that has a lower resolution than your native display res, swww defaults to stretching the image to fill the display. Is it feasible to implement the option to centralize the image instead, filling the border with a color of your choice?
I have a nice animation on boot that transitions to a static image. In #93 I have figured out that you can
swww img i.gif
swww kill
swww init
and the loading time in init
is basically 0. So is there a reason we cant have a command that makes the daemon perform those really fast steps that happen in init, but for loading the GIF while it is already running?
When running a command without first initializing the daemon you get this error message.
Error: "Failed to connect to socket: No such file or directory (os error 2)"
It's not immediately obvious what the problem is.
I think it would be helpful if a suggestion to check if the daemon is running was added (as a second line maybe?).
Something like this could work.
Is the swww daemon running?
Hello!
When using animated gif pixel art it would be nice to be able to keep the crispy square pixels even if the original art has a very small resolution compared to the display resolution.
Currently I'm doing the conversion with gifscicle but it creates huge gifs which can take up to 10 seconds to be loaded by swww.
When I load the original gif it is loaded almost instantly but clearly has some filtering making the pixels look fuzzy/blurry.
Thanks for such a great application!
This is a weird request, but I wish it's possible to do something like this
cat wallpaper.png | swww img -
where -
stands for read from standard input as most program do
For some reasons we may wish to set wallpapers with no filename extension (for example, I have a script to move wallpaper to ~/.local/share/background
) . However, swww refuses to use such files, throwing Error: "failed to open image '\"/home/aleksana/.local/share/background\"': The image format could not be determined"
.
In most cases on desktop linux, we do not determine file by its filename extension, but use mine types instead. You can use file --mime-type foo.bar
to view a file's type.
Hi! Thanks for working on this fun little program!
I have found a bug/regression between versions 0.3.0 and 0.4.0.
There is an undocumented change when scaling the wallpaper image. In 0.3.0
swww used to fill
the wallpaper, now it strech
es the image.
0.4.0
and master
When The requested wallpaper image has a different aspect ratio then the target output.
Then The displayed image is stretched.
0.3.0
When The requested wallpaper image has a different aspect ratio then the target output.
Then The displayed image is zoomed in.
Can we return the old behavior or turn it into an option?
$ swww query
DP-2 = 2560x1440, currently displaying: image: "wallpaper.bmp"
HDMI-A-1 = 2560x1080, currently displaying: image: "wallpaper.bmp"
sway
DP-2
is a 16:9 4k screen with 1.5
scaling, HDMI-A-1
is a 21:9 ultrawide.wallapaper.bmp
is a 1080p 16:9 image.I'm running swww version 0.4.3 on Arch, using Sway as the compositor.
Running sway init and then setting an image as the background works, when using my laptop display alone, or using my laptop's display plus an external display that is plugged in.
However, when the swww daemon is running and I plug / unplug the display, the daemon gets into a state where it can not be communicated with.
Setting the background with:
swww img --transition-speed=1 --transition-step=1 ~/Pictures/my_wallpaper.png
results in:
Failed to receive answer: io error: Resource temporarily unavailable (os error 11)
Running swww kill results in the same error.
I can only get it running again by killing the process, and removing the socket manually.
I'm talking about is_daemon_running()
in src/main.rs
. I understand why the daemon check was necessary (I read through #11 and #26), but I think there's a much cleaner solution to this problem: daemons can use inotify
to check whether the socket they created has been removed or not. If a running daemon determines that its socket was removed, it should exit immediately. When a new daemon is started, it immediately removes any existing socket file, which will force past daemons (if they exist) to exit. There's a nice Rust crate for using inotify
(which is also, quite helpfully, called inotify
), and since inotify
instances are just file descriptors, they can be inserted into the daemon's main event loop quite easily.
I think this is a better solution because 1) it doesn't require traversing the entirety of /proc
whenever the daemon starts up; 2) it allows swww init
to deal with possibly-existing daemons better; and 3) it allows the daemon process to detect that its socket file has been removed and to exit accordingly, which it currently does not do. I'm not asking you to implement this feature - I'd quite like to, actually - but I want to confirm that if I do implement it and open an MR for it, it would be accepted.
I have some larger U/HD images that exceed the screen real estate when using this tool.
What commands are available to make it only fit to screen (usually called stretch or fit)
built the program with cargo build --release
Trying to run the daemon:
> ./swww init --no-daemon
WARNING: socket file /run/user/1000/swww.socket was not deleted when the previous daemon exited
thread 'main' panicked at '[SCTK] A missing global was required: zwlr_layer_shell_v1', /home/luis/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.16.0/src/environment.rs:193:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[1] 149731 IOT instruction (core dumped) ./swww init --no-daemon
env:
cargo 1.65.0
rustc 1.65.0 (Arch Linux rust 1:1.65.0-1)
Let me know if you need more information.
Hey, I recently decided to make my own wallpaper gif with ffmpeg
, but whenever I run swww init
and swww img path/to/the/gif
it displays the first frame with the fading in animation and drops to default Sway background (I use Sway).
The gif.
I used this command to get the gif (However, I used other commands to get the input.gif
):
ffmpeg -i input.gif -filter_complex "fps=30,scale=1920:1080,split[a][b]; [a]palettegen=stats_mode=full [palette]; [b][palette]paletteuse=dither=sierra2_4a" output.gif
$ swww --version
swww 0.6.0
The only reason im asking this is because cargo is really slow in compiling everything and thus updates take a long time
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.