Alacritty: Wayland clipboard intermittently broken

[pschyska]

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.

[pschyska]

When I'm in a broken alacritty session, pasting text copied from other applications into alacritty doesn't work as well, but copying text in alacritty and then pasting to another application works. So it seems to me that just the clipboard loading is broken in any case.

That it either fails all the time or never within one session could indicate a race-condition during startup.

[chrisduerr]

@trimental Any idea?

[trimental]

@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

[trimental]

@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

[pschyska]

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

Attached a logfile.
debug.log

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'm afraid I don't. I don't know much about rust and I keep getting compile errors because the types don't implement Display or Debug. Additionally, the changes I do make directly in ".cargo/registry/src/github.com-1ecc6299db9ec823/smithay-clipboard-0.3.3/" don't seem to take effect on subsequent alacritty builds. (I used cargo build in the .cargo directory above).

If you can send me a patch with useful println!() statements and tell me how to build it I'm happy to try it out.

[pschyska]

Sorry @trimental, disregard above log. I had some changes I did for testing in copypaste.
Here is a log taken when it works:
debug.working.log

Here is a log when it doesn't:
debug.log

[Freyr666]

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.

[pschyska]

So I tried some inspection in lldb on the line you indicated earlier.
First of all, I found it odd that lldb stopped two threads on that breakpoint at the same time. Is that supposed to happen? The breakpoint was immediately hit after I ran the program.

I then evaluated the arguments to implement_seat.

(lldb) br set --file threaded.rs --line 206
Breakpoint 1: where = alacritty`smithay_clipboard::threaded::clipboard_thread::_$u7b$$u7b$closure$u7d$$u7d$::hd00b46a12c0fd096 + 783 at threaded.rs:207:20, address = 0x0000000000b7e66f
(lldb) run
Process 25744 launched: '/home/p/projects/alacritty/target/debug/alacritty' (x86_64)
Process 25744 stopped
* thread #2, name = 'alacritty', stop reason = breakpoint 1.1
    frame #0: 0x00005555560d266f alacritty`smithay_clipboard::threaded::clipboard_thread::_$u7b$$u7b$closure$u7d$$u7d$::hd00b46a12c0fd096(event=GlobalEvent @ 0x00007ffff4949200, reg=WlRegistry @ 0x00007ffff4949228) at threaded.rs:207:20
  thread #4, name = 'alacritty', stop reason = breakpoint 1.1
    frame #0: 0x00005555560d266f alacritty`smithay_clipboard::threaded::clipboard_thread::_$u7b$$u7b$closure$u7d$$u7d$::hd00b46a12c0fd096(event=GlobalEvent @ 0x00007ffff4748200, reg=WlRegistry @ 0x00007ffff4748228) at threaded.rs:207:20

(lldb) frame var id
(unsigned int) id = 17
(lldb) frame var version
(unsigned int) version = 5
(lldb) frame var *seat_map_clone.ptr.pointer
(alloc::sync::ArcInner<std::sync::mutex::Mutex<std::collections::hash::map::HashMap<alloc::string::String, (alloc::sync::Arc<std::sync::mutex::Mutex<smithay_client_toolkit::data_device::data_device::DataDevice>>, u32, alloc::sync::Arc<std::sync::mutex::Mutex<core::option::Option<wayland_protocols::unstable::primary_selection::v1::generated::client::zwp_primary_selection_device_v1::ZwpPrimarySelectionDeviceV1>>>, alloc::sync::Arc<std::sync::mutex::Mutex<core::option::Option<wayland_protocols::unstable::primary_selection::v1::generated::client::zwp_primary_selection_offer_v1::ZwpPrimarySelectionOfferV1>>>), std::collections::hash::map::RandomState> > >) *seat_map_clone.ptr.pointer = {
  strong = {
    v = (value = 3)
  }
  weak = {
    v = (value = 1)
  }
  data = {
    inner = 0x00007fffe8000c60
    poison = {
      failed = {
        v = (value = '\0')
      }
    }
    data = {
      value = {
        hash_builder = (k0 = 8166481854200182992, k1 = 9720562631116616057)
        table = {
          capacity_mask = 18446744073709551615
          size = 0
          hashes = {
            __0 = {
              pointer = 0x0000000000000001
              _marker = {}
            }
          }
          marker = {}
        }
        resize_policy = {}
      }
    }
  }
}
lldb) frame var *last_seat_name_clone.ptr.pointer
(alloc::sync::ArcInner<std::sync::mutex::Mutex<alloc::string::String> >) *last_seat_name_clone.ptr.pointer = {
  strong = {
    v = (value = 3)
  }
  weak = {
    v = (value = 1)
  }
  data = {
    inner = 0x00007fffe8000de0
    poison = {
      failed = {
        v = (value = '\0')
      }
    }
    data = {
      value = {
        vec = {
          buf = {
            ptr = (pointer = "", _marker = core::marker::PhantomData<unsigned char> @ 0x00007fffe8000e30)
            cap = 0
            a = {}
          }
          len = 0
        }
      }
    }
  }
}
(lldb) frame var data_device_manager
(wayland_client::protocol::wl_data_device_manager::WlDataDeviceManager *) data_device_manager = 0x00007fffe8000d38
(lldb) frame var reg
(wayland_client::protocol::wl_registry::WlRegistry) reg = {
  __0 = {
    _i = {}
    inner = (internal = core::option::Option<alloc::sync::Arc<wayland_client::imp::proxy::ProxyInternal>> @ 0x00007ffff4949228, ptr = 0x00007fffe8000f10, wrapping = core::option::Option<std::thread::ThreadId> @ 0x00007ffff4949238)
  }
}
(lldb) frame var *primary_selection_device_manager_clone.ptr.pointer
(alloc::sync::ArcInner<std::sync::mutex::Mutex<core::option::Option<wayland_protocols::unstable::primary_selection::v1::generated::client::zwp_primary_selection_device_manager_v1::ZwpPrimarySelectionDeviceManagerV1> > >) *primary_selection_device_manager_clone.ptr.pointer = {
  strong = {
    v = (value = 3)
  }
  weak = {
    v = (value = 1)
  }
  data = {
    inner = 0x00007fffe8000d60
    poison = {
      failed = {
        v = (value = '\0')
      }
    }
    data = (value = core::option::Option<wayland_protocols::unstable::primary_selection::v1::generated::client::zwp_primary_selection_device_manager_v1::ZwpPrimarySelectionDeviceManagerV1> @ 0x00007fffe8000db0)
  }
}

I have to admit I have no clue about any of this :smirk:. Can you tell me what you are looking for specifically @trimental ?

[pschyska]

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.

[trimental]

@pschyska @Freyr666 If you could test branch https://github.com/Smithay/smithay-clipboard/tree/roundtrip-before-n-after with

diff --git a/Cargo.toml b/Cargo.toml
index 2e8fd4d..8d1289c 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -14,3 +14,4 @@ incremental = false

 [patch.crates-io]
 servo-freetype-sys = { path = "servo-freetype-proxy" }
+smithay-clipboard = { git = "https://github.com/smithay/smithay-clipboard", branch = "roundtrip-before-n-after" }

it would be appreciated :)

[pschyska]

Hey @trimental, with this branch, loading the clipboard still only works sometimes, but loading the primary selection doesn't seem to work at all anymore.
Additionally, I got a SIGSEGV during one of my trials:

#0  get_next_argument (signature=0x4031 <error: Cannot access memory at address 0x4031>, details=0x7ff0c25199a0) at src/connection.c:445
#1  0x00007ff0c5d94b1d in wl_argument_from_va_list (signature=<optimized out>, args=<optimized out>, count=<optimized out>, ap=0x7ff0c25199c8) at src/connection.c:508
#2  0x00007ff0c5d92772 in wl_proxy_marshal_constructor (proxy=proxy@entry=0x7ff0b8059330, opcode=opcode@entry=0, interface=0x7ff0c5d9b980 <wl_callback_interface>) at src/wayland-client.c:820
#3  0x00007ff0c5d93849 in wl_display_sync (wl_display=0x7ff0b8059330) at ./protocol/wayland-client-protocol.h:958
#4  wl_display_roundtrip_queue (display=0x55e2cb6eb4e0, queue=0x7ff0b8000b80) at src/wayland-client.c:1233
#5  0x000055e2c9fa909c in wayland_client::imp::event_queue::EventQueueInner::sync_roundtrip (self=0x7ff0b8000b30)
    at /home/p/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.23.5/src/native_lib/event_queue.rs:70
#6  0x000055e2c9fafb50 in wayland_client::event_queue::EventQueue::sync_roundtrip (self=0x7ff0c251a798) at /home/p/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.23.5/src/event_queue.rs:157
#7  0x000055e2c9ede571 in smithay_clipboard::threaded::clipboard_thread (display=0x7ff0b8000c00, event_queue=0x7ff0c251a798, request_recv=..., load_send=...)
    at /home/p/.cargo/git/checkouts/smithay-clipboard-22ebaedc6c141020/ca238ed/src/threaded.rs:260
#8  0x000055e2c9eddcaa in smithay_clipboard::threaded::ThreadedClipboard::new_from_external::{{closure}} () at /home/p/.cargo/git/checkouts/smithay-clipboard-22ebaedc6c141020/ca238ed/src/threaded.rs:93
#9  0x000055e2c9f02182 in std::sys_common::backtrace::__rust_begin_short_backtrace (f=...) at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/sys_common/backtrace.rs:136
#10 0x000055e2c9f3de31 in std::thread::Builder::spawn_unchecked::{{closure}}::{{closure}} () at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/thread/mod.rs:470
#11 0x000055e2c9ed99c1 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once (self=..., _args=()) at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panic.rs:309
#12 0x000055e2c9edad27 in std::panicking::try::do_call (data=0x7ff0c251a9d0 "\340\264n\313\342U") at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panicking.rs:293
#13 0x000055e2ca6106aa in __rust_maybe_catch_panic () at src/libpanic_unwind/lib.rs:87
#14 0x000055e2c9eda470 in std::panicking::try (f=...) at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panicking.rs:272
#15 0x000055e2c9ed9cf3 in std::panic::catch_unwind (f=...) at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/panic.rs:388
#16 0x000055e2c9f3d8c2 in std::thread::Builder::spawn_unchecked::{{closure}} () at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libstd/thread/mod.rs:469
#17 0x000055e2c9f3e1c4 in core::ops::function::FnOnce::call_once{{vtable-shim}} () at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/libcore/ops/function.rs:231
#18 0x000055e2ca5f862f in call_once<(),FnBox<()>> () at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/liballoc/boxed.rs:702
#19 0x000055e2ca60fad0 in call_once<(),alloc::boxed::Box<FnBox<()>>> () at /rustc/3c235d5600393dfe6c36eeed34042efad8d4f26e/src/liballoc/boxed.rs:702
#20 start_thread () at src/libstd/sys_common/thread.rs:14
#21 thread_start () at src/libstd/sys/unix/thread.rs:80
#22 0x00007ff0c5c015a2 in start_thread (arg=<optimized out>) at pthread_create.c:486
#23 0x00007ff0c5b14303 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[pschyska]

@trimental So alacritty passes None as seat_name, and smithay-clipboard tries to figure it out by itself by listening to pointer events (here I think: https://github.com/Smithay/smithay-clipboard/blob/master/src/threaded.rs#L518). The clipboard is immediately initialized when alacritty starts. What happens when there are just no events yet? Wouldn't this mean we don't know the seat_name and last event serial in this case?

I'm starting alacritty with a keyboard shortcut, or from the terminal which means I'm not touching my mouse.

[trimental]

@pschyska you would still get a keyboard enter event. Also you need to press keyboard keys or mouse buttons in order to actually paste or copy anything (e.g Ctrl C)

[pschyska]

Yes that's true.

[pschyska]

So, any new ideas @trimental? Can I help you by testing something else?

[trimental]

@pschyska right now that SIGSEVG is probably the most important thing to investigate as it could be an issue with wayland-rs or libwayland. Do you know whether you are able to reproduce it reliably or is it a rare event?

[pschyska]

@trimental I will try to repro on the weekend.

[pschyska]

@trimental I can reproduce it "reliably" by starting and killing alacritty in rapid succession. I get a SIGSEGV every 20 to 100 cycles. I inspected the last 3 coredumps and the backtraces are identical to the one I pasted earlier.
I was unable to reproduce this issue with the last stable version of alacritty and with c6a0167, so I assume it is caused by the changes in https://github.com/Smithay/smithay-clipboard/tree/roundtrip-before-n-after.
Also, these changes didn't seem to change anything in regards to the original bug, so it's maybe a red herring to hunt it down?

[greenfoo]

I don't know if this is of any help but I can also reproduce the same issue on the latest "master" and the only difference between the log messages on a "good" session and a "bad" session is that, just after pressing "Ctrl+Shift+V", the next message only appears on the "good" session:

[INFO] glutin event: Awakened

[trimental]

@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

[pschyska]

@trimental This didn't change anything unfortunately.
I tried to strip down alacritty to make it store and load a bunch of strings in bootup, but the load never works on wayland (it works for Xorg so in principle it should). The symptoms are the same as in this bug (store and load don't error, but the load always returns an empty string)

Can you tell me if there is a way to query the wl_display for the current seat, so maybe we can try to always specify it when creating the clipboard and can rule out the seat determination heuristic?

[kchibisov]

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

[chrisduerr]

@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.

[trimental]

@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.

[rrichardson]

I have Fedora 30 and am experiencing the same problem. I have started tracing but haven't found anything yet. If anyone has something for me to try, I'd be happy to.

[kchibisov]

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.

[rrichardson]

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. :)

[kchibisov]

Hm, I was able to repro this quite reliable on GNOME/Fedora 30 in a virtual box. However for me on sway the clipboard dies in a different way, when it dies it dies completely so no copy/paste at all (copy and paste to a different app doesn't work). So the issues are quite different from my point of view. Anyway, I'll try to fix it on fedora and maybe it'll work for me as well.

[pschyska]

Hm, I was able to repro this quite reliable on GNOME/Fedora 30

Awesome, thank you. I was also using gnome/f30. I couldn't repro on sway yet because the package version in F30 is quite old and I didn't get it to work at all, and didn't get around building it manually.

[kchibisov]

If someone could post the output of the following patch it will be appreciated. You should apply it to the latest master. This patch doesn't do anything related to clipboard, it just dumps interfaces(protocols?), which are available.

diff --git a/copypasta/Cargo.toml b/copypasta/Cargo.toml
index ae65a7c..1f06a9f 100644
--- a/copypasta/Cargo.toml
+++ b/copypasta/Cargo.toml
@@ -17,7 +17,7 @@ objc-foundation = "0.1"

 [target.'cfg(all(unix, not(any(target_os="macos", target_os="android", target_os="emscripten"))))'.dependencies]
 x11-clipboard = "0.3"
-smithay-clipboard = "0.3.2"
+smithay-clipboard = { git = "https://github.com/kchibisov/smithay-clipboard", branch = "gather-stats" }
 wayland-client = { version = "0.23.3", features = ["dlopen"] }

 [target.'cfg(all(unix, not(any(target_os="macos", target_os="android", target_os="emscripten"))))'.dev-dependencies]

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. This name is presented on sway though (which is expected, since this protocol is supported? in wlroots).

[rrichardson]

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

[zhelezov]

Looks like their interface is called gtk_primary_selection_device_manager: https://github.com/GNOME/gtk/blob/7869ffbb49cf99fcf7c4a7f1b4925262991d1e5d/gdk/wayland/protocol/gtk-primary-selection.xml#L26

Found also the discussion on bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762561

[pschyska]

Looks like their interface is called gtk_primary_selection_device_manager: https://github.com/GNOME/gtk/blob/7869ffbb49cf99fcf7c4a7f1b4925262991d1e5d/gdk/wayland/protocol/gtk-primary-selection.xml#L26

Found also the discussion on bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=762561

But it does work sometimes; both primary and clipboard selections under Gnome. How is that possible when zwp_primary_selection_device_manager_v1 is not implemented? Are you sure it's not redirected to gtk_primary_selection_device_manager somewhere else?

[kchibisov]

But it does work sometimes

@pschyska That's why I've ask here, since for me it doesn't work at all. I've tried 20-30 times copy/paste to/from primary doesn't work(to different apps and to alacritty), which is expected since smithay-clipboard is using zwp_primary_selection_device_manager_v1 and there is no reference in mutter about this protocol, like at all, only gtk_primary_selection_device_manager, so I was wondering why it was working for you. However wlroots supports gtk_primary_selection_device_manager, so I'll investigate in using this one for primary selection.

@trimental , do you have any thoughts about using gtk_primary_selection_device_manager? I've not looked into this myself(will do today), but just asking here, since you were probably aware of this protocol during implementation of smithay-clipboard.

[zhelezov]

But it does work sometimes

It doesn't ever work for me using master on Fedora 30, gnome-session-wayland-session-3.32.0

[trimental]

@kchibisov I think gtk-primary-selection is outdated by the current zwp-primary-selection protocol.

In which case it’s probably best to support it in smithay-clipboard for environments with only the gtk version.

Is adding this backup support something you’d be interested in? If not I could probably add it sometime in the next week or so.

[kchibisov]

Is adding this backup support something you’d be interested in? If not I could probably add it sometime in the next week or so.

@trimental, I can try to add this myself, I guess. It seems like it is quite similar to zwp-primary-selection, but I'll let you know in case I face any problems during implementation.

[rrichardson]

One more data point:
I don't know if it matters, but in this particular iteration where I
captured the output, the clipboard did not work.

On Sat, Aug 10, 2019, 6:38 AM Kirill Chibisov [e-mail]
wrote:

Is adding this backup support something you’d be interested in? If not I
could probably add it sometime in the next week or so.

I can try to add this myself, I guess. It seems like it is quite similar
to zwp-primary-selection, but I'll let you know in case I face any problems
during implementation.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/jwilm/alacritty/issues/2574?email_source=notifications&email_token=AAA6KC7J755HOWESSYPQV4DQD3ADXA5CNFSM4H2WMUIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ANVTQ#issuecomment-520149710,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAA6KC52QG5RJ5PADTJEL4DQD3ADXANCNFSM4H2WMUIA
.

[kchibisov]

@rrichardson This shouldn't matter, since the protocol we're using for the primary clipboard isn't implemented in mutter at all and the output should be always consistent here, since we're trusting compositor.

[chrisduerr]

It might be worth checking other applications which use zwp-primary-selection. It seems like it would be very unfortunate to implement another protocol, without actually solving any issues.

[kchibisov]

@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.

[kchibisov]

So as I've expected here, wl-clipboard's wl-copy -p doesn't work on GNOME, when it is built without gtk_primary_selection_device_manager.

I've build with zwp-primary-selection and without gtk-primary-selection, so it was working on sway and wasn't on GNOME at the same time. It says that Primary selection is not supported on this compositor, when running it on GNOME.

So we have 2 tasks here:

• [x] Implement gtk_primary_selection_device_manager
• [x] Fix race? or whatever with normal clipboard

Update:
The second task is not a data race, it's just some arcane magic happening in gnome + mutter + threaded clipboard combination, I know how to fix it (and I've already tested my guess, and yeah, it's working, however there's a big caveat with this approach), so I'll try to track down what's going wrong with the current implementation first.

[kchibisov]

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.

[garnacho]

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

[kchibisov]

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

[rrichardson]

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

Nice work!

[zhelezov]

Yup, working for me too! Thank you!

Though I can confirm that after a tty change both primary selection and clipboard are broken again.

[kchibisov]

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.

[dead10ck]

Sorry, I don't mean to pester, but is there any way this could be released sooner? It looks like there is still quite a bit of work left in the 0.3.4 milestone. This bug is making 0.3.3 unusable on Wayland.

[kchibisov]

@dead10ck You can always build things yourself, It's super easy, consult INSTALL.md. FYI clipboard is only broken for GNOME Wayland session and not Wayland in general, e.g. on sway I've never had this issue.

[kchibisov]

Oh, and in case you're speaking from "system packages" side, you can always suggest this patch to your system's alacritty package maintainers (e.g. Arch Linux is already doing something about X11 transparency bug) .

[dead10ck]

Yeah, I wanted to avoid a nightly build if possible, but that might be my choice if cutting new releases is not on the table. I suppose another option would be building myself on the 0.3.2 branch. As for system packages, Fedora does not ship alacritty; I've been using the pschyska COPR repo listed in the README.

[kchibisov]

You can always pick v0.3.3 and apply only this patch, since it doesn't depend on anything iirc. I personally recommend you to avoid v0.3.2, since v0.3.3 has lots of bug fixes and it's the first version with native Wayland clipboard, otherwise you'll be using xclip.

[chrisduerr]

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.

[dead10ck]

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

[pschyska]

@chrisduerr If you tag a pre-release, I could trigger a build on the alacritty-testing repo.
I might also figure out how to do proper nightlies with rpm (there is some magic versioning thing in rpm for that). Would you be willing to add a webhook to this repo that triggers a build on every push?

[chrisduerr]

Would you be willing to add a webhook to this repo that triggers a build on every push?

I don't like the idea of merging together software and packaging.

[rrichardson]

It seems like Docker would make this a pretty trivial CI task, as long as there was a place to put the resulting binary.

(although the same goes for @dead10ck, it should be pretty easy to make a release from this branch if you use the Nightly docker image. I have been using @kchibisov branch as my main work terminal for the last 3 weeks. )

[chrisduerr]

First of all, while it might be 'trivial' for one version of one distro, it's much less trivial for all versions of all distros.

There are good reasons why packaging and development are conventionally separated and I do not think it's a good idea to change that.

[rrichardson]

@chrisduerr Right. I was not recommending making distro packages, just Linux binaries.

[chrisduerr]

There is no way to build a single binary which will work on all linux systems natively.