alacritty: Wayland clipboard intermittently broken

Which operating system does the issue occur on? Fedora 30, on both alacritty 0.3.3 and alacritty master. I’m running in gnome-session-wayland-session 3.32.0. If on linux, are you using X11 or Wayland? Wayland. This issue doesn’t occur in X11 at all.

I noticed that sometimes, neither the Selection nor Clipboard works at all. I can’t fix it without restarting alacritty. I ran a test just running it from my shell from another alacritty instance many times, and it’s 50-50 each trial if the clipboard is either completely broken, and never works, or always works.

I’ve added some debug statements:

diff --git a/alacritty_terminal/src/clipboard.rs b/alacritty_terminal/src/clipboard.rs
index 0e40cd4..85e3378 100644
--- a/alacritty_terminal/src/clipboard.rs
+++ b/alacritty_terminal/src/clipboard.rs
@@ -83,18 +83,21 @@ pub enum ClipboardType {

 impl Clipboard {
     pub fn store(&mut self, ty: ClipboardType, text: impl Into<String>) {
+        debug!("Clipboard#store ty={:?}", ty);
         let clipboard = match (ty, &mut self.selection) {
             (ClipboardType::Selection, Some(provider)) => provider,
             (ClipboardType::Selection, None) => return,
             _ => &mut self.clipboard,
         };
-
-        clipboard.set_contents(text.into()).unwrap_or_else(|err| {
+        let text = text.into();
+        debug!("Clipboard#store text={}", text);
+        clipboard.set_contents(text).unwrap_or_else(|err| {
             warn!("Unable to store text in clipboard: {}", err);
         });
     }

     pub fn load(&mut self, ty: ClipboardType) -> String {
+        debug!("Clipboard#load ty={:?}", ty);
         let clipboard = match (ty, &mut self.selection) {
             (ClipboardType::Selection, Some(provider)) => provider,
             _ => &mut self.clipboard,
@@ -105,7 +108,10 @@ impl Clipboard {
                 debug!("Unable to load text from clipboard: {}", err);
                 String::new()
             },
-            Ok(text) => text,
+            Ok(text) => {
+                debug!("Clipboard#load text={}", text);
+                text
+            },
         }
     }
 }

The output is as follows:

[2019-06-22 11:08] [DEBUG] Clipboard#store ty=Selection
[2019-06-22 11:08] [DEBUG] Clipboard#store text=alacritty
[2019-06-22 11:08] [DEBUG] Clipboard#store ty=Clipboard
[2019-06-22 11:08] [DEBUG] Clipboard#store text=alacritty
[2019-06-22 11:08] [DEBUG] Clipboard#load ty=Selection
[2019-06-22 11:08] [DEBUG] Clipboard#load text=
[2019-06-22 11:08] [DEBUG] Clipboard#load ty=Clipboard
[2019-06-22 11:08] [DEBUG] Clipboard#load text=

So it seems the data is passed into smithay-clipboard, but it doesn’t come out again.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 8
  • Comments: 61 (45 by maintainers)

Commits related to this issue

Most upvoted comments

@kchibisov - I just compiled your branch and ran it 10 times… copy/paste worked 10 out of 10 times.

Nice work!

+5
rrichardson on Aug 13, 2019

For now it seems like mutter doesn’t implement zwp_primary_selection_device_manager_v1 at all (tested on Arch Linux). I couldn’t find any reference on their github mirror and it doesn’t appear in dump with patch I’ve mentioned here.

That is correct, it simply fell through the cracks… AFAIR the zwp_primary_selection protocol was heavily based on the gtk_primary_selection one, and a AFAICS it’s essentially a 1:1 copy. It shouldn’t be hard to handle both on the client side in the interim.

Mutter will eventually support the wayland-protocols one, but I can’t promise it’ll be as soon as 3.34.0

+4
garnacho on Aug 12, 2019

Just to clarify some things.

A tty issue is much more complicated, since the problem can be out of scope of wayland clipboard and alacritty. The PR I’ve sent should address main concerns people have with wayland clipboard on GNOME in this issue, so I’ll likely open a separate issue just to track this bug after PR will be merged.

+2
kchibisov on Aug 14, 2019

I’ve pushed more commits to #2715, so both primary and clipboard clipboards should work now.

+2
kchibisov on Aug 13, 2019

Would someone provide info on their compositors/DE on Wayland? I guess this issue appears more frequently on GNOME, since for me on sway it happens quite seldom (I can’t reproduce it just by launching terminals and copy/pasting). It usually happens to me after long period of time and not always, so information on environment should speed up things a bit.

Update: The information on distro that you are running will also help, since I’m likely just install it in vm/on one of my machines to troubleshoot/fix this bug.

+2
kchibisov on Aug 8, 2019

@trimental Would you mind if I’ll work on this one? Just want to learn some wayland.

+2
kchibisov on Jul 26, 2019

I think I’m seeing two threads because alacritty actually starts two clipboard context. When I change this

--- a/alacritty_terminal/src/clipboard.rs
+++ b/alacritty_terminal/src/clipboard.rs
@@ -47,13 +47,7 @@ impl Clipboard {
                         ),
                     )
                 },
-                selection: unsafe {
-                    Some(Box::new(
-                        WaylandClipboardContext::<WaylandPrimaryClipboard>::new_from_external(
-                            display,
-                        ),
-                    ))
-                },
+                selection: None,
             };
         }

I’m unable to reproduce the issue anymore! (I tried it about 20 times so far). Could there be a race because two clipboard threads are started simultaneously.

+2
pschyska on Jun 22, 2019

I use alacritty 0.3.3 on arch with Gnome 3.32, and after 0.3.3 neither primary nor secondary buffers work for me on wayland session at all. Never, no conditions like OP mentioned, it simply doesn’t work.

Although Ctrl-Shift-c and pasting to Firefox works, neither Ctrl-Shift-c nor primary selection works in alacritty.

+2
meadofpoetry on Jun 22, 2019

@chrisduerr okay, I appreciate the quick response, and of course, all your guys’ work on Alacritty. 🙂

+1
dead10ck on Aug 29, 2019

Sorry, I don’t mean to pester, but is there any way this could be released sooner?

There is not. The next version will be released as soon as the glutin rework is ready. The milestones on our end are mostly resolved, so it just depends on the upstream changes.

+1
chrisduerr on Aug 29, 2019

I’ve created a PR #2715 to track progress on this issue. If you can test it, it’ll be appreciated. For now Ctrl+Shift+V/Ctrl+Shift+C should work, I hope.

+1
kchibisov on Aug 11, 2019

@chrisduerr I’ll investigate whether I can test it on wl-clipboard(build it without gtk stuff). From my point of view, adding support for gtk_primary_selection_device_manager shouldn’t resolve the main issue we have here on gnome + mutter. So fixing primary selection on gnome is kind of sub task here, which is worth solving, since this issue covers both clipboard.

At least we know that primary is broken, because it’s not implemented (if we can assume that wl-clipboard without gtk isn’t working on gnome+mutter, I’ll test it later today) and “normal” clipboard is broken due to data race somewhere.

+1
kchibisov on Aug 10, 2019 
wl_drm
wl_drm
wl_compositor
wl_compositor
wl_shm
wl_shm
wl_output
wl_output
wl_output
wl_output
zxdg_output_manager_v1
zxdg_output_manager_v1
wl_data_device_manager
wl_data_device_manager
gtk_primary_selection_device_manager
gtk_primary_selection_device_manager
wl_subcompositor
xdg_wm_base
wl_subcompositor
zxdg_shell_v6
xdg_wm_base
wl_shell
zxdg_shell_v6
gtk_shell1
wl_shell
wp_viewporter
gtk_shell1
zwp_pointer_gestures_v1
wp_viewporter
zwp_tablet_manager_v2
zwp_pointer_gestures_v1
wl_seat
zwp_tablet_manager_v2
wl_seat
zwp_relative_pointer_manager_v1
zwp_relative_pointer_manager_v1
zwp_pointer_constraints_v1
zwp_pointer_constraints_v1
zxdg_exporter_v1
zxdg_exporter_v1
zxdg_importer_v1
zxdg_importer_v1
zwp_linux_dmabuf_v1
zwp_linux_dmabuf_v1
zwp_keyboard_shortcuts_inhibit_manager_v1
zwp_keyboard_shortcuts_inhibit_manager_v1
zwp_text_input_manager_v3
zwp_text_input_manager_v3
gtk_text_input_manager
gtk_text_input_manager
+1
rrichardson on Aug 10, 2019

I’m on Fedora 30 Linux msi 5.2.5-200.fc30.x86_64 #1 SMP Wed Jul 31 14:37:17 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Gnome/GDM 3.3.2

Although… I am a long-time i3 user, so sway looks quite enticing at this moment. 😃

+1
rrichardson on Aug 8, 2019

@kchibisov of course, any help would be very welcome 😃

If you need any help or explaination of SCTK, smithay-clipboard or general wayland feel free to message me or ask in the smithay matrix chat room.

+1
trimental on Jul 26, 2019

@kchibisov I’d be surprised if trimental wouldn’t appreciate the support here and as far as I’m concerned this is a relatively high profile issue on Wayland at the moment. So all contributions would be welcome, assuming that @trimental doesn’t have a WIP stashed somewhere and you’d just be doing work that has already been done.

+1
chrisduerr on Jul 26, 2019

@pschyska I’ve pushed some more commits to the https://github.com/Smithay/smithay-clipboard/tree/roundtrip-before-n-after branch if you could test that

+1
trimental on Jul 1, 2019

@pschyska replicating this issue whilst using WAYLAND_DEBUG=1 could be useful.

And if you know how to, putting a debug here https://github.com/Smithay/smithay-clipboard/blob/master/src/threaded.rs#L206 would be useful

I’ll continue trying to replicate it on my machine

+1
trimental on Jun 22, 2019

@chrisduerr i have a suspicion this could be to do with registering a seat for the clipboard however I’ll have to do a bit of testing

+1
trimental on Jun 22, 2019
Read more comments on GitHub
← alacritty: [wayland-client error] Attempted to dispatch unknown opcode 0 for wl_shm, aborting.
alacritty: Wayland window decorations no longer function →