Emacs no longer speaks to the Wayland clipboard in 20260908

English Applications
1

(This is my first post here, please be lenient.)

Since upgrading from 20260904 to 20260908, I can no longer copy and paste between Emacs and other applications (I verified that vanilla emacs -q is also affected). The Tumbleweed 20260908 changelog lists a gtk3 version update (3.24.52 → 3.24.52+git59.b30343717d) with clipboard-related changes merged in https://build.opensuse.org/requests/1375925/changes, which I suspect to be related.

Trying to paste text from Emacs into a terminal shows the following clipboard error:

g-io-error-quark (15):
Kein kompatibles Übertragungsformat gefunden

——————————
KGX: 50.0
Adw: 1.9.2 (1.9.3)
Vte: 0.84.0 (0.84.1)
  Features: +BIDI +GNUTLS +ICU +SYSTEMD
Gtk: 4.22.4
  Display: GdkWaylandDisplay
  Surface: GdkWaylandToplevel
  Renderer: GskVulkanRenderer
GLib: 2.88.2 (2.88.3)
OS: openSUSE Tumbleweed ((null))
  XDG_CURRENT_DESKTOP: GNOME
  XDG_SESSION_DESKTOP: gnome
  XDG_SESSION_TYPE: wayland
  LANG: de_DE.UTF-8

Is anyone else seeing this or has a solution? Thanks!

2

So I found a workaround to reenable clipboard access: I added

export EMACS_TOOLKIT=gtk

to my ~/.profile, where the default choice was wayland due to my $XDG_SESSION_TYPE in GNOME being wayland. This setting will cause emacs to effectively launch /usr/bin/emacs-gtk rather than /usr/bin/emacs-wayland. The value of the window-system variable in Emacs will then be ‘x’ (not ‘pgtk’) and clipboard sharing works.

3

I’m pretty sure I’m affected by this as well - clipboard was previously working with pgtk, broke recently, x/gtk build is unaffected. It’s more complicated in my case because I’m running on WSL, so there is an additional layer involved in all of this. I haven’t been able to find any bug reports on any of the involved packages about this.

4

I’m also a “heavy” user of emacs but on the kde side:

$ kinfo
Operating System: openSUSE Tumbleweed-Slowroll 20260901
KDE Plasma Version: 6.7.5
KDE Frameworks Version: 6.29.0
Qt Version: 6.11.2
Kernel Version: 6.18.49-11.sr20260802-longterm (64-bit)
Graphics Platform: Wayland
Processors: 22 × Intel® Core™ Ultra 9 185H
Memory: 32 GiB of RAM (30.9 GiB usable)
Graphics Processor 1: Intel® Arc
Graphics Processor 2: NVIDIA GeForce RTX 4060 Laptop GPU

with

$ echo $XDG_SESSION_TYPE 
wayland

I just checked because for me: emacs-gtk is slower than emacs-wayland and for me: it works. I can copy from kate to emacs-wayland and from emacs-wayland to kate.

You may have something else going or it may be related to gnome or some security/selinux settings.

5

Thanks. I see you are on Slowroll 20260901. This is shortly before the clipboard broke for me. I know the problem appeared when updating from 20260904 to 20260908, which narrows down the possible sources quite a bit and I strongly suspect the gtk3 update (3.24.52 → 3.24.52+git59.b30343717d). In short, I supsect you will see the problem as well when this update reaches slowroll before getting addressed.

6

Thanks for pointing this out.

Hopefully it will be fixed by next month. I depend on emacs!

  • wikis
  • calendaring/scheduling
  • name and addresses
  • …
7

If it gets reported at the right place, but I am not sure where that is.
Maybe https://gitlab.gnome.org/GNOME/gtk/-/work_items.

8

I’ve created created bsc#1284143 and upstream GTK#8443. The recently merged GTK!10008 (included in TW since gtk3 3.24.52+git48.b9cc75f19f) has caused this regression. I’ve created GNOME/gtk3#6 for factory, which temporarily reverts the GTK regression and fixes the emacs issue. Binaries are available in home:mwilck:Factory on OBS.

Upstream currently says that it’s a problem in mutter, although the regression has been introduced in GTK. I’ve built mutter with the upstream fix in home:mwilck:Git:Factory as an alternative to the gtk3 revert, and it fixes the emacs clipboard issue for me under GNOME, too.

I believe that emacs is not the only victim; copy and paste between other applications is also affected (e.g. GTK#8446).I think any recent issues with copy/paste between different applications under Wayland are worth reporting. Unfortunately this kind of issue is tricky to debug. It can help to set the environment variable WAYLAND_DEBUG=1 before running the affected application and watch out e.g. for set_selection(). Interpreting these logs is for wayland experts though (I am not one of them).

2 Likes
9

A fix in mutter is on the way. (https://build.opensuse.org/request/show/1383105).

10

Thanks a lot for tracking this down and reporting at the right places. It did start to work shortly after your report, but it is now again broken since a few days. :frowning:
So I’m now again setting export EMACS_TOOLKIT=gtk in my .profile as a workaround.