r/wayland

Hey everyone,

I wrote a small POSIX shell script called fuzz-wall that lets you pick wallpapers interactively using fuzzel's dmenu mode. I wanted something dead simple that worked regardless of which WM or wallpaper setter I was using, so I built it.

What it does

You run fuzz-wall, fuzzel opens with a list of your wallpapers, you pick one, it gets applied. ESC to exit. No config file, no GUI, no bloat.

Supported wallpaper setters

- swaybg (Sway)

- swww (Hyprland, with fade transitions)

- hyprpaper (Hyprland)

- feh (i3, bspwm, dwm)

- nitrogen (openbox, bspwm)

- xwallpaper (general purpose)

The script auto-detects which one you have installed. On Wayland it prefers Wayland-native setters, on X11 it falls back to X11 setters.

Configuration

There is only one option, the wallpaper directory. It defaults to ~/Pictures/wallpapers and can be overridden:

FUZZ_WALL_DIR=~/Pictures/walls fuzz-wall

You can bind it to a key in your WM config:

# Hyprland

bind = $mod, W, exec, fuzz-wall

# Sway

bindsym $mod+w exec fuzz-wall

# i3

bindsym $mod+w exec fuzz-wall

Install

It is on the AUR:

```paru -S fuzz-wall

yay -S fuzz-wall```

Or clone manually and copy to ~/.local/bin.

Source: https://github.com/youngcoder45/fuzz-wall

AUR: https://aur.archlinux.org/packages/fuzz-wall

This is my first AUR package. Happy to hear feedback, bug reports, or suggestions for new wallpaper setters to support. If your WM or setter is not listed, open an issue and I will add it.

wdotool is an xdotool replacement for Wayland. It uses libei via the RemoteDesktop portal for input and KWin scripting (same machinery as kdotool) for window ops on KDE. The code has shipped since v0.1.x and unit tests pass, but I've never run the matrix on a real Plasma session because I'm on Hyprland and won't dual-boot just to verify it. So right now the strongest claim I can make about the KDE backend is "I think it works," which is not a great claim to ship under.

The verification doc is here: docs/verification/kde-plasma-6.md.

Twelve operations (key, type, mousemove, click, scroll, search, windowactivate, etc.) across six conditions:

• Default
• Fractional 125%
• Fractional 175%
• Mixed-scale dual-monitor
• Wayland session restart
• fcitx5 active

Plus two special tests: portal token revoke + recovery, and a 5-step wflow workflow that exercises the one-consent-many-ops property end-to-end (wflow migrated to wdotool-core as a library in v0.6.0, so this test is now first-class instead of the "TODO once wflow migrates" placeholder it used to be). Each cell takes a ✅ / ❌ / N/A. ~30-45 min if everything passes.

If anything fails I'll fix it or file it as its own issue, no expectation that you debug. Just need real-hardware ground truth from someone whose daily driver is Plasma. The PR closes issue #1.

For comparison with the alternatives: xdotool is X11-only, ydotool writes to /dev/uinput which means root and no compositor focus awareness. wdotool stays inside the portal permission model, which is why KDE specifically matters (the consent dialog flow is half the surface I need verified).