dnut / clipboard-sync Goto Github PK

1. finish #2 so you only need to run a rust binary and not run.sh
2. publish crate #11
3. systemd service instead of daemon.sh
4. PKGBUILD: belongs in aur, probably not github #8

PKGBUILD can go in the aur repo, use make

it's pointless to maintain my own logging implementation if other well maintained crates support the same behavior.

options:

• log (common)
• tracing (featureful)

is this compatible with the current features?

• runtime logging configuration: yes
• excluding timestamps for systemd: yes https://stackoverflow.com/questions/48850403/change-timestamp-format-used-by-env-logger
• configurable masking of log messages that are marked as having sensitive information: yes, because I can continue doing this the same way, as a wrapper around another logging macro

this used to be handled but now the equivalence checking sets all the clipboards to useless junk. if any clipboard has a non-empty string before launch, one of those clipboard contents should become the contents for all the clipboards after setup

I started using a nested sway display for the first time in several weeks. I encountered a problem the first time I tried to paste something into a window within sway. Nothing came out of the clipboard. Now it has recovered, but I saw some weird error messages occurring in the logs around the same time.

Jun 09 15:42:23 hp1040 env[223179]: ERROR - error getting status of child process 243388: ECHILD: No child processes
Jun 09 15:42:23 hp1040 env[223179]: DEBUG - routinely attempting to kill child process 243388.
Jun 09 15:42:23 hp1040 env[223179]: ERROR - error killing child process 243388: ESRCH: No such process

also saw this a bit earlier

Jun 09 15:23:46 hp1040 env[216387]: thread 'main' panicked at 'child process 221573 panicked too many times.', src/main.rs:81:25
Jun 09 15:23:46 hp1040 env[216387]: note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Jun 09 15:23:46 hp1040 systemd[189653]: clipboard-sync.service: Main process exited, code=exited, status=101/n/a

full logs from the day are attached

err.log

I did screenshot my screen and obviously copied image data to clipboard, but other session's clipboard appears to be empty.
Text based data work though, but I already use xsel to sync text based clipboard.

Edit:
So IMO, it's not worth to add more repo list or installing rust

thank you for author who show us how to use raw github content as package source.list

Reply here to vote for this feature.

I exclusively use arch linux so I won't prioritize this work unless someone is interested. One person is enough to get me to look into it. Just be sure to actually comment, a thumbs up won't notify me.

This happens during the necessary stage of identifying new clipboards. To do this, it sets values to the clipboard and then retrieves the value from the same or other clipboards. It's hard to completely avoid this but ideally it can be reduced somehow.

there's already this to reset it back to the value from before checking

    for c in clipboards.iter() {
        c.set(&start)?;
    }

but occasionally i hit the clipboard in the middle of the search and get a display number anyway. this would restore it sooner but i don't know how much better it would be. need to weigh this against the fact that it's reading and writing to all the clipboards ~twice as many times

fn are_same(one: &Box<dyn Clipboard>, two: &Box<dyn Clipboard>) -> MyResult<bool> {
    let one_orig = one.get()?;
    let two_orig = two.get()?;
    let d1 = &one.display();
    let d2 = &two.display();
    one.set(d1)?;
    if d1 != &two.get()? {
        one.set(&one_orig)?;
        return Ok(false);
    }
    two.set(d2)?;
    if d2 != &one.get()? {
        one.set(&one_orig)?;
        two.set(&two_orig)?;
        return Ok(false);
    }
    one.set(&one_orig)?;

    Ok(true)
}

splitting out this work from #32 which is for the implementation of other mime-types, because these docs shouldn't take as long.

add to the docs:

• clear explanation of exactly which mime types are supported (currently only text)
• uninstall instructions, including the exact commands to cleanly remove everything from debian-based distros (I'll need to test that this really cleans things out properly without screwing anything up)

While working on #4, I realized hybrid clipboards may not even be needed. Maybe there's a better more flexible design for this service. Keep a vec of all getter clipboards and all setter clipboards. Monitor getter.get() for each getter, and if there's a change, set it for every setter. There's no need for a hybrid clipboard because you don't need to link a display's input channel with its output channel.

Why is this advantageous? Doesn't it just make it harder to understand what's happening to a single display when it's split in multiple places? Yes but that may be unavoidable to an extent. It may be too hard to even identify what constitutes both the getter and setter for a single display, especially if there are x11 displays with their own display numbers that don't correspond directly to a wayland display number, meanwhile you need to use the x11 clipboard to connect to a gnome wayland getter.

Maybe it makes more sense to simply figure out anything you can plug into as either an input or an output, agnostic of whether there's a display that associates some input with some output. Accept updates from anywhere, regardless of whether you think there's some input associated with it. Broadcast updates to anywhere, regardless of whether you think there's some output associated with it.

Sometimes I notice all the clipboards break after the service has been working fine for hours or days. Not only is it not synced but I can't even copy and paste within a single display. Restarting the service always fixes it.

Something is getting into a bad state, but I'm not sure what. I have a suspicion there are some issues with some displays starting and stopping while the service is running but I don't see how that fully explains it. I need to add some extensive debug logging (probably do #10 at the same time) and check out the logs whenever this happens.

somehow the user systemd service this creates breaks plasma 6 global shortcut service. I vertified this by removing /home/zany130/.config/systemd/user/graphical-session.target.wants/clipboard-sync.service.

before the removal adding a shortcut to a script in plasma settings produces this error in the terminal

kcmshell6 kcm_keys
qt.qml.typeresolution.cycle: Cyclic dependency detected between "qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml" and "qrc:/qt/qml/org/kde/desktop/MenuItem.qml"
qrc:/kcm/kcm_keys/main.qml:466:5: QML OverlaySheet: Binding loop detected for property "implicitHeight"
qrc:/qt/qml/org/kde/desktop/private/TextFieldContextMenu.qml:235:5: QML MenuItem: Binding loop detected for property "implicitWidth"
org.kde.kcm_keys: "Error while calling objectPath of added applicationnotify-send.desktop"
org.kde.kcm_keys: "org.kde.kglobalaccel.NoSuchComponent" "The component 'notify-send.desktop' doesn't exist."

removing the file allows me to successfully add the same shortcut.

I tried reinstalling the clipboard-sync package both from the aur and by https://github.com/dnut/clipboard-sync#advanced-installation

and it still breaks.

here is the KDE issue where I was troubleshooting this
https://discuss.kde.org/t/unable-to-add-shortcuts-plasma-6-regression/13383

timestamps are redundant for systemd services. also maybe debug mode or more generally log level can be configured with something other than a const

The hybrid clipboard struct should simply accept two clipboard types: one for get and one for set. then it's possible to construct any hybrid. We'll continue to use the same approach to handle gnome clipboards but it'll be constructed via composition with a constructor function.

Some library interacts with the clipboard by opening a hidden window that you never see. Usually I don't see this unless my computer sits idly for a long time, and then I come back to see a huge number of anonymous windows in my dock in gnome. They close immediately when I click on them, or they all close at once if I restart this service.

This problem is not straightforward to solve. It may require gnome to implement the wlr standard, which they have stated explicitly they are not interested in doing. Otherwise there is writing an integration with gnome but I think this API is supposed to be private. More research is needed.

An alternative approach would be to simply restart the clipboard tracking process more frequently rather than only waiting for EMFILE error to restart. If the process restarts every minute for example, that may prevent a huge number of these windows from accumulating. This restarting behavior could be made customizable as part of the implementation for #2.

These are problems in libraries that are already being handled here in an acceptable manner. But ideally they would be fixed upstream so we can get rid of the weird quirks that are needed to deal with it. This meta-issue tracks all of those issues so those upstream bugs can be monitored and new issues can be created in this repo when they are fixed.

Current

History

These have already been resolved upstream and integrated. The mitigation listed here is no longer in use.

this could be split into multiple tickets

• sha256sums for arch linux
• PGP signing for debian repo
• deb verifiable builds. ideally users can verify that the deb is derived from the source code in this git repo. a simple approach would be to write a shell script that builds the deb in a docker image and compares the hash to the repo version

this is a problem on master, not 0.1.0

for some reason it thinks every single x11 display is a real display but it figures out they are all duplicates.

previously it would find a few dupes but not all 255

Reply here to vote for this feature.

I exclusively use arch linux so I won't prioritize this work unless someone is interested. One person is enough to get me to look into it. Just be sure to actually comment, a thumbs up won't notify me.

I use citrix workspace within sway, and the xwayland clipboard from that app has never synced, I was hoping this would fix the syncing between those things, but it appears to not do anything at all

the copied text is still available from citrix with xclip -o in an alacritty window (however if I run it within xterm, i get a different output, further complicating things)

Not sure what exactly is going on or what logs to send, might be an upstream issue with xwayland/sway

test and document how to use make for a local/user install instead of a system-wide install.

It has been a headache trying to build deb files and test them in different versions of debian and ubuntu due to libc and libxcb dependencies. It would be great if these dependencies could be statically linked. The goal is the ability to build a fully portable binary that only depends on the linux kernel and x64 architecture. It should run in any version of debian, ubuntu, arch, etc.

I try to paste something that I recently copied from the same display, and there's nothing there. eventually it seems to recover

in some cases this hangs. it happened during setup when it was checking that the wlr and x11 clipboards are actually the same. so it may have something to do with interacting with the x11 clipboard causing the wlr clipboard to become unresponsive, until the wlr clipboard setter is called. that specific issue is handled now by setting to empty string before using the clipboards but this issue should be explored further to have a robust solution that could avoid issues during setup regardless of the displays and the order they are checked

Shortly after coming back from suspend, I saw this behavior. I would copy something into the clipboard but then I couldn't paste anything. The clipboard was empty. I was getting multiple log lines for each time that I copied something. Sometimes 2 sometimes 3. I did see that I could paste a couple times though when I was messing around in the terminal. But I was never able to copy and paste in firefox.

Resumed from suspend at 9:01. I saved all the systemd logs from that time to my computer in the bugs folder.

May 10 09:03:34 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:03:34 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:03:53 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:03:53 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:03:53 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:04:00 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:04:00 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:04:00 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:04:03 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:04:03 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:02 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:02 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:02 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:05 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:05 hp1040 env[1233853]: INFO - clipboard updated from display :0
May 10 09:05:29 hp1040 env[2352]: DEBUG - child 1233853 is still alive, as expected.
May 10 09:05:29 hp1040 env[2352]: DEBUG - routinely attempting to kill child process 1233853.
May 10 09:05:29 hp1040 env[2352]: DEBUG - child process 1233853 completed with: Signaled(Pid(1233853), SIGTERM, false)

Since polling happens frequently, this error happens every few minutes, which breaks the rust process so it must exit and be restarted:

thread 'main' panicked at 'Sending a message failed.: EMFILE', /home/drew/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.29.4/src/rust_imp/proxy.rs:211:39

This is a problem in wayland-rs, see YaLTeR/wl-clipboard-rs#12 and Smithay/wayland-rs#235.

The current solution is to just restart the app with a shell script any time it exits. I'm sure there is a more elegant way to do this.

Ideally the process can clean up its own open files, but I'm not sure there's a way to do this without fixing the library. So we probably have to live with the fact that the process must terminated to close all the files, and then a new process must be spawned.

At the very least we can manage the process by forking from rust instead of bash. Some exit status can be used to indicate why the process had to exit. So when the failure is EMFILE the process can be restarted, but otherwise it can exit the entire service if desired.

it has to go through its restart cycle (10 minute period) to get new ones, which is annoying

when i run it in a docker container i get 254 errors about failure to connect to wlr clipboard, and i get the summary warning for x11 clipboards failing with the gnome message.

it should probably just have info summary messages