7

I recently upgraded from Debian 12 to Debian 13 (Trixie) and now using GNOME Shell 48.4 on Wayland.

Before the upgrade, I knew that many classic X11 utilities wouldn’t work on Wayland, but I was confident that there were Wayland-native alternatives.

However, after a clean install of Debian 13, I’ve discovered that the Wayland tools that are supposed to work are not working.

For example, I used to use:

  • xdotool
  • xrandr
  • xprop
  • wmctrl
  • scrot
  • maim (for sending screenshots to stdout) etc.

Wayland alternatives I expected to work (but don’t);

  • wlrctl
  • wtype
  • grim
  • grimshot
  • flameshot
  • ydotool (not in Debian 13 repos) etc.

The errors are as follows:

% grimshot copy area compositor doesn’t support zwlr_layer_shell_v1 % grim compositor doesn’t support wlr-screencopy-unstable-v1 % slurp compositor doesn’t support zwlr_layer_shell_v1 % wtype -M ctrl plus -m ctrl Compositor does not support the virtual keyboard protocol % wlrctl keyboard type “abc” Virtual Keyboard interface not found! 

I prefer to stay on Wayland if possible, since GNOME has made it increasingly difficult to use X11 and will likely drop support entirely by GNOME 50.

Does GNOME/Mutter intentionally not implement certain protocols (like virtual-keyboard, foreign-toplevel, etc.) that these tools depend on?

What are the official GNOME-supported ways to:

  • Simulate keyboard/mouse input
  • Capture screenshots to stdout (pipe to another process)

Is there a recommended developer-friendly path for scripting and automation under GNOME Wayland?

I really like Wayland’s design goals, but losing scripting and automation makes it very difficult for power users.

Any guidance on what currently works, and what the roadmap is for tools like wtype, wlrctl, or proper GNOME APIs for automation, would be hugely appreciated.

1 Answer 1

5

Does GNOME/Mutter intentionally not implement certain protocols (like virtual-keyboard, foreign-toplevel, etc.) that these tools depend on?

Most of those protocols are specific to the wlroots code base, which Mutter doesn't use, and deliberately does not implement these protocols either – as one of Wayland's design goals per GNOME was specifically that apps cannot get such access without explicit permission, aside from specific components. (Another point is GNOME's general preference for D-Bus rather than Wayland as the "generic" IPC transport, so where GNOME does have equivalents they're usually implemented via D-Bus.)

For example, screen recording or screen sharing in Mutter is only accessible through the XDG Portal system (using a D-Bus API rather than an integrated Wayland protocol) where the portal – the trusted component – always shows a GUI confirmation dialog unless previous access has been remembered. In contrast, many wlroots-based compositors apparently have no access control whatsoever.

(The portal backend or 'implementation' is swappable, so that the same frontend API works on GNOME, KDE, indeed also on wlroots-based WMs. In theory you could patch the xdg-portal-gnome backend so that it doesn't show any confirmation dialogs and directly gives the requested access.)

Screenshots can be made using gnome-screenshot. Mutter does support a virtual keyboard for its built-in RDP/VNC component (using libei) but I don't think that's accessible to other programs. With root privileges, it would be possible to create a fake input device via uinput which would be seen as a keyboard by Mutter and could inject key events. If I remember correctly, the display control tool was gdctl.

2
  • 1
    Can unix.stackexchange.com/q/603834/206574 be done in gnome using gdctl or anything else. In that question I used xdotool to send keypress. Commented Oct 23 at 1:21
  • @AhmadIsmail I'd ideally do that by patching the terminal emulator to directly recognize Ctrl-Scroll if possible... Commented Oct 24 at 4:20

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.