1- # The Final Solution to your Wayland Wallpaper Woes
1+ # A Solution to your Wayland Wallpaper Woes
22### Efficient animated wallpaper daemon for wayland, controlled at runtime
33
44## Dependencies
1515 - Up to date stable rustc compiler and cargo
1616
1717To build, clone this directory and run:
18- ``` bash
18+ ```
1919cargo build --release
2020```
21- Then, put the binary at ` target/release/fswww ` in your path.
21+ Then, put the binary at ` target/release/swww ` in your path.
2222Optionally, autocompletion scripts for bash, zsh, fish and elvish are offered
2323in the ` completions ` directory.
2424
@@ -35,12 +35,12 @@ There are two main reasons that compelled me to make this, the first, that
3535[ oguri] ( https://github.com/vilhalmer/oguri ) hasn't updated in over a year as I
3636am writting this (02 Feb 2022), despite there being serious problems with
3737excess of memory use while displaying certain gifs (see [ this] ( https://github.com/vilhalmer/oguri/issues/38 ) ,
38- for example). The best alternative I've found for oguri was [ mpvpaper] ( https://github.com/GhostNaN/mpvpaper ) ,
38+ for example). The best alternative I've found for oguri was [ mpvpaper] ( https://github.com/GhostNaN/mpvpaper ) ,
3939but if felt like quite the overkill for my purposes.
4040
41- Comparing to ` oguri ` , ` fswww ` uses less cpu power to animate once it has cached
41+ Comparing to ` oguri ` , ` swww ` uses less cpu power to animate once it has cached
4242all the frames in the animation. It should also be ** significantly** more
43- memory efficient (make sure to see the
43+ memory efficient (make sure to see the
4444[ Caveats/Limitations] ( #CaveatsLimitations ) though).
4545
4646The second is that, to my knowledge, there is no wallpaper daemon for wayland
@@ -52,33 +52,33 @@ makes switch from one image to the next to happen very abruptly.
5252## Usage
5353
5454Start by initializing the daemon:
55- ``` bash
56- fswww init
55+ ```
56+ swww init
5757```
5858Then, simply pass the image you want to display:
59- ``` bash
60- fswww img < path/to/img>
59+ ```
60+ swww img <path/to/img>
6161
6262# You can also specify outputs:
63- fswww img -o < outputs> < path/to/img>
63+ swww img -o <outputs> <path/to/img>
6464
6565# Control how smoothly the transition will happen and/or it's frame rate
6666# For the step, smaller values = more smooth. Default = 20
6767# For the frame rate, default is 30.
68- fswww img --transition-step < 1 to 255> --transition-fps < 1 to 255>
68+ swww img --transition-step <1 to 255> --transition-fps <1 to 255>
6969```
7070If you would like to know the valid values for * \< outputs\> * then you can query
7171the daemon. This will also tell you what the current image being displayed is,
7272as well as the dimensions detected for the outputs. If you need more detailed
7373information, I would recommend using [ wlr-randr] ( https://sr.ht/~emersion/wlr-randr/ ) .
74- ``` bash
75- fswww query
74+ ```
75+ swww query
7676```
7777Finally, to stop the daemon, kill it:
78- ``` bash
79- fswww kill
8078```
81- For a more complete description, run * fswww --help* or * fswww \< subcommand\>
79+ swww kill
80+ ```
81+ For a more complete description, run * swww --help* or * swww \< subcommand\>
8282--help* .
8383
8484## Caveats/Limitations
@@ -87,15 +87,15 @@ I had a glorious name when I started this project, but alas, I couldn't quite
8787get there, here are some issues with it:
8888
8989 - To initialize the daemon already displaying and image, use:
90- ``` bash
91- fswww init --img < path/to/img> # Do this
90+ ```
91+ swww init --img <path/to/img> # Do this
9292 ```
9393 Do ** NOT** use something like:
94- ``` bash
95- fswww init && fswww img < path/to/img> # Don't do this
94+ ```
95+ swww init && swww img <path/to/img> # Don't do this
9696 ```
9797 As that might straight up not work. In particular, it tends to fail when using
98- it in a compositor's init script (which is probably where you will want to
98+ it in a compositor's init script (which is probably where you will want to
9999 ` init ` the daemon).
100100 - Despite trying my best to make this as resource efficient as possible,
101101 ** memory can still be an issue** . From my testing, this seems to be mostly
@@ -104,6 +104,6 @@ get there, here are some issues with it:
104104 Strangenly, it also seems that openning the same image again will * not*
105105 increase usage further. Still trying to understand what's going on here.
106106 - If the daemon exits in an unexpected way (for example, if you send SIGKILL to
107- force its shutdown), it will leave a ` fswww .socket` file behind in
108- ` $XDG_RUNTIME_DIR ` (or ` /tmp/fswww ` if it isn't set). If you want to
107+ force its shutdown), it will leave a ` swww .socket` file behind in
108+ ` $XDG_RUNTIME_DIR ` (or ` /tmp/swww ` if it isn't set). If you want to
109109 reinitialize the daemon, you will have to remove that file first.
0 commit comments