Support for Wayland

[hluk]

Support for Wayland

[hluk]

Below is update for CopyQ running on Wayland from #1243.

Current problems in Gnome 3.34 running on Wayland:

• Clipboard cannot be accessed unless the window has focus (so basically clipboard won't get stored).
• Notifications get keyboard focus when they appear -- it doesn't seem possible to create a window with Qt that can be shown without getting focus. There is feature request #1247 for CopyQ to support native notifications.
• Copying with mouse selection (as X11 primary selection) won't work because Wayland doesn't support it.
• Global shortcuts don't work and AFAIK there is no support in Wayland itself.

Solution

Workaround for most problems is to set QT_QPA_PLATFORM environment variable and use Xwayland (xorg-x11-server-Xwayland fedora package) to handle X11 apps.

E.g. launch CopyQ with:

env QT_QPA_PLATFORM=xcb copyq

If CopyQ autostarts, you can change Exec=... line in ~/.config/autostart/copyq.desktop:

Exec=env QT_QPA_PLATFORM=xcb copyq

Note: Mouse selection will work only if the source application itself supports it.

[opensource-assist]

@hluk On my Plasma Wayland session, one way for the shortcuts to work is as follows:

• Run System Settings, then click on Shortcuts > Custom Shortcuts > Edit > New > Global Shortcut > Command/URL
• Click on Trigger > Shortcut, then set the shortcut
• Click on Action > Command/URL and input copyq toggle
• Click Apply

But I don't know if that's possible programmatically, anyway you can instruct users for manually doing so.

[zetorian]

for wlroots compositors (swayWM and friends) there is a new protocol specifically for clipboard managers:
swaywm/wlr-protocols#25
example implementation a la xclip:
https://github.com/bugaevc/wl-clipboard

not super widely implemented, but incredibly useful where it is

[hluk]

Please open new issue if you have some problems but see the known issues below first.

Not everything can be currently supported on Wayland - it depends on a window compositor implementation.

List of unsupported stuff by Wayland:

• global shortcuts
• windows size and position restoring
• issuing copy and paste commands to other apps
• clipboard monitoring may not work in some desktop environments like Ubuntu (they do not implement the protocol) - use Wayland Support or environment variable QT_QPA_PLATFORM=xcb as workaround (requires XWayland support)

I'm going to close this issue since there is nothing else I can do now.

[hluk]

On the technical side, how does the wayland support work?

Apart for smaller fixes, there is now a separate clipboard handler for Wayland that uses a protocol used by Sway and some other compositors. The protocol allows CopyQ to monitor and access clipboard while the app itself is not active.

The original code is taken from Klipper clipboard manager. I've implemented few fixes on top of this and I haven't seen any issues using CopyQ in Sway. Even copying screenshots or other bigger content works fine on my side, but maybe I'm also lucky. :)

The relevant code is here: https://github.com/hluk/CopyQ/tree/master/src/platform/x11/systemclipboard

[beruic]

The work-around by @opensource-assist works fine on Gnome too.

Tip: Use copyq toggle to be able to hide the window with the same keys.

[tnilzon]

Things that don't work under Wayland in Gnome (what I have found so far):

• Global hotkey Show/Hide
• Paste to current window (by Enter key or double click)
• Focus last window

[hluk]

Workaround for now is to set global shortcuts in desktop environment, but I don't know if there is a utility that allows to send shortcuts to window for pasting in Wayland (like xdotool for X11). Perhaps Wayland doesn't support this anyway.

[pbar1]

In the meantime, for those here when trying to use copyq with Alacritty - copy the Alacritty.desktop file into your home applications directory as such:

cp /usr/share/applications/Alacritty.desktop ~/.local/share/applications/

Then modify the Exec line to force Alacritty to run under XWayland:

Exec=env WINIT_UNIX_BACKEND=x11 alacritty

After doing this, copyq should work just fine.

[hluk]

@hluk in light of the fact that Ubuntu 22.04 will have Wayland on by default: How is this issue coming along? What is the status?

Clipboard and selection (if supported by window manager) works well now. Global shortcuts need to be assigned in desktop environment - it does not work in the app (I don't know any way around this). Window position and size cannot be restored by the app itself in many (all?) Wayland window compositors. Pasting (and copying) from the app (e.g. on Enter key) does not work without using app like ydotool (see #27 (comment)).

That said, I've been using CopyQ with Sway (Wayland tiling window manager) and occasionally in KDE/Wayland and it works well enough for me.

[hluk]

I have also tried copyq triggerGlobalShortcut "Show main window under mouse cursor" after install Wayland Support script without luck.

AFAIK, Wayland does not support setting custom window position.

[hluk]

CopyQ should work under Wayland but there are still few thing unimplemented -- global shortcuts, window focusing, sending copy/paste shortcuts (it may be possible to replace these by invoking external utilities and binding shortcuts in DE).

I tried Wayland some time ago but it was bit unstable and there are still no official packages for Arch Linux. I can work on implementing this after it's stable on my system and hardware.

I would be glad if anyone can help implement those features.

[hluk]

@thebunnyrules Thanks for the detailed description.

app A and app B both on the X.org. app A can see exactly what's on app B's gui, capture it's keystrokes, audio, as well inject keystrokes into it.

Unfortunately, injecting keystrokes is what CopyQ does to be able to paste directly to target window. Surprisingly, this still works on OS X and Windows.

The easiest work around for that would be to have a copyq daemon that can be given commands to show CopyQ via terminal

This already works with copyq show and similar. [1]

The question is how much Wayland (or a window manager) restricts window focusing or prevents focus stealing. The command itself doesn't tell the system that it's focusing given window, it just sends a message to main application to show the window.

I'm really happy you're looking into Wayland.

I'm still not using Wayland because of some issues (mainly: having unfriendly NVidia graphics card on one machine, screen sharing for video conferencing doesn't work). So any help is really appreciated.

[1] http://copyq.readthedocs.io/en/latest/scripting-api.html#show

[hluk]

Often, when I want to select an older image from the clipboard history, the image is truncated while it is pasted to e.g. xwayland windows.

@cmprmsd Thanks for the report. It is probably caused by some custom multi-threading I added to the clipboard handling to avoid some application lockups. Perhaps it is not needed anymore so I will remove the custom code and update the rest from the latest kguiaddons code base in #1944.

[hluk]

May there be a way to analyze the timeouts and find a root cause for them?

The problem the app could not send/receive own clipboard content to/from a sub-process. The best solution I found was to use separate threads to send/receive data so the app won't get stuck.

I will try to fix the multi-threaded code so it works with larger amount of data reliably.

[kohnish]

Copy seems to work out of the box on sway (Fedora) but paste on select isn't working on wayland with copyq 6.3.2, but it can be worked around by adding the following to ~/.config/copyq/copyq-commands.ini. It'd be nice if there is an official support.

8\Command="copyq:
    copy(mimeItems, input())
    execute('wl-copy', '-p', null, clipboard())
    hide()
    execute('wtype', '-M', 'shift', '-P', 'insert')"
8\Icon=\xf328
8\InMenu=true
8\Input=application/x-copyq-item
8\Name=Paste on Select
8\Shortcut=enter, return
size=8

[trysten]

I struggled getting CopyQ to show/hide on sway. It didn't seem to want to stay floating. I was using the wrong criteria for wayland.

app_id
Compare value against the app id. Can be a regular expression. If value is focused, then the app id must be the same as that of the currently focused window. app_id are specific to Wayland applications.
class
Compare value against the window class. Can be a regular expression. If value is focused, then the window class must be the same as that of the currently focused window. class are specific to X11 applications.

Use app_id instead of class

[scottkosty]

Does this come for free by using Qt 5 or is there extra coding necessary? It seems like to test on ubuntu all one needs to do is install gnome-session-wayland. Let me know if you think it is ready for testing and I could give it a run.

[hluk]

I'll have to upgrade my Ubuntu in VM and test it (I have NVIDIA graphic card and I don't think they have support for Wayland yet).

These features need to be tested:

• clipboard monitoring,
• global shortcuts,
• window focusing (focus main window using global shortcut and paste to current window from main window and tray menu),
• sending copy/paste shortcuts to other windows.

These things are implemented for X11 so it could work on Wayland it there is some transition layer for X11 library.

[dualmoon]

I saw this and was wondering if you have any plans on working on this. A big problem a lot of us have using wayland DEs is the lack of clipboard shared between wayland apps and apps running on the xwayland x11 mini server. If you could find and build a way for copyq to sync those clipboards for one then you'd be considered a hero by me at least.

[thebunnyrules]

I've tested CopyQ on Gnome-Shell Wayland:

CopyQ does work under Wayland via the XWayland compatibility layer (that term just means that it sends it off to X11) but it would be ideal if it worked natively on Wayland due to the massive security vulnerabilities present in X11 and the delicate nature of the information being handled by this application. I left some articles below but to summarize these issues: suppose you have app A and app B both on the X.org. app A can see exactly what's on app B's gui, capture it's keystrokes, audio, as well inject keystrokes into it. In most cases that's not a big deal but for some people it is because they may be sandboxing an untrusted app on X11 across a restricted account, for example, a video game running off of steam or GOG which is running on X and they don't know or trust the author.

As for hotkeys on Wayland, the in app hotkeys that are used when the CopyQ window is focused work fine but the global hotkeys that CopyQ relies on to show and hide it do not work due to Wayland's restriction on keystroke capture. The easiest work around for that would be to have a copyq daemon that can be given commands to show CopyQ via terminal, for example: copyqd --showclipboard or copyqd showsnippets etc. We can then go to our Desktop Environments and set the hotkeys for these commands manually or CopyQ can even use the gsettings (or it's KDE equivalent) to register the hotkeys with the Desktop Environment.

I'm really happy you're looking into Wayland. This is by far my favorite clipboard manager and the prospect of being able to use it again makes me really happy. Best of luck and let me know if you need a Beta tester on Wayland.

Info about X11 Vulnerabilities:
Your Linux PC isn't as secure as you think it is
Ubuntu’s Snap packages aren’t yet as secure as Canonical’s marketing claims (X11)
The Turla espionage operation also infected Linux systems with malware

[thebunnyrules]

Hi hluk, thanks for your response.

Unfortunately, injecting keystrokes is what CopyQ does to be able to paste directly to target window.
Surprisingly, this still works on OS X and Windows

Yeah, I would expect that injecting text directly into a Window would be a problem but I don't think that would be affected by CopyQ running natively in Wayland or not. The restriction on injecting text happens at the destination Window and not at the source app. That being said, there would be no restrictions on manipulating the clipboard. So you can still bring up CopyQ, peruse and select the clip you want. It will get sent to clipboard just as in X and the clipboard monitoring will still work as it did before. It just means now that you need an extra step after you've selected the clip: Ctrl-V.

This already works with copyq show and similar. [1]

The question is how much Wayland (or a window manager) restricts window focusing or prevents focus stealing. The command itself doesn't tell the system that it's focusing given window, it just sends a message to main application to show the window.

That's really good to know. I can test the focusing issue and let you know. EDIT: Good news! The focus worked perfectly. I just made a Hotkey in Gnome's Keyboard prefs for: copyq show - it works beautifully.

I'm still not using Wayland because of some issues (mainly: having unfriendly NVidia graphics card on one machine, screen sharing for video conferencing doesn't work). So any help is really appreciated

Yeah, I know what you mean. I have another machine with an nVidia card on it and I wouldn't run Wayland on it either. Good news is that they're working on it at nVidia but it's probably going to be a while before it's stable. No worries, I'm happy to give you a hand in any way I can. Just ask. PS - If you ever want a Wayland enviro to test to on, you can always download virtualbox and just install an Ubuntu 17.10 or KDE neon iso on it. They both have Wayland as default.

[knservis]

@hluk I have tried your workaround to set the shortcut in the desktop environment and it does not work exactly. Even though the shortcut brings up the main window, copyq is trying to paste it to the previous to last window that was on focus in my case. Sometimes paste works sometimes not.

[tnilzon]

Great, thanks!

[beruic]

Somehow global shortcuts seems to work for me on Ubuntu 19.10 Wayland now.
Any info I can provide to investigate?
Anyone experiencing the same?

[beruic]

Seems I way wrong. It does work when Chrome, PyCharm or GitKraken is in focus, but not in GEdit, Files or Gnome Terminal.

[hluk]

I think the global shortcuts work only when you start CopyQ with environment variable QT_QPA_PLATFORM=xcb and press the shortcut in another X11-capable app. Otherwise, you have to use the shortcut settings provided by the desktop environment.

[bkedryna]

thanks guys. sorry for opening that bug #1390. i restarted copyq with "env QT_QPA_PLATFORM=xcb" in front, created a shortcut in keyboard settings (on my fedora 32: Settings->Keyboard Shortcuts, hit the + at the bottom, entered 'copyq' for name, 'copyq show' for command and ctrl+ as the shortcut) and now when i press ctrl+, copyq pops up like before.
the only problem i have is that when i select something and double click it, it doesn't automatically paste, but it's not a huge deal - i can just press ctrl-v to paste it.

[dylanmorroll]

@hluk On my Plasma Wayland session, one way for the shortcuts to work is as follows:

* Run `System Settings`, then click on `Shortcuts > Custom Shortcuts > Edit > New > Global Shortcut > Command/URL`

* Click on `Trigger > Shortcut`, then set the shortcut

* Click on `Action > Command/URL` and input `copyq toggle`

* Click `Apply`

But I don't know if that's possible programmatically, anyway you can instruct users for manually doing so.

This is great, thanks! Anyone know if there's a cli option for showing the main window under the mouse cursor?? Is a minor thing so no worries if not, just glad to get it working again!

[hluk]

There is now wayland branch with some code changes to support Wayland compositors:

• Clipboard/selection support - this depends on compositor - tested with Sway which supports the clipboard manager protocol.
• Notifications (uses knotifications library) - notification daemon must be running and some of these doesn't support all features (e.g. buttons/actions)

Other problems I noticed with Sway compositor:

• Positioning windows doesn't work (for floating window).
• Getting mouse pointer position doesn't work outside of the application (copyq pointerPosition gives last position in the app windows).

[hluk]

The functionality to paste from the main window can be emulated in Wayland with ydotool:

Old Command

[Command]
Command="
    copyq:
    // Safely types item text or encrypted item without using clipboard (simulates key presses).
    // Requires \"ydotool\".
    var maxChars = 16
    var initialDelay = 100
    var delayBeetweenKeystrokesMs = 10
    var notificationTimeoutMs = 8000
    
    function typeText(slice) {
        var result = execute(
            'ydotool',
            'type',
            '--file', '-',
            '--key-delay', delayBeetweenKeystrokesMs,
            null, slice)
    
        if (!result) {
            throw 'Failed to type text'
        }
    
        if (result.exit_code != 0) {
            throw 'Failed to type text: ' + result.stderr
        }
    }
    
    function notify(title, message) {
        notification(
            '.id', 'decrypt-type',
            '.time', notificationTimeoutMs,
            '.icon', '\xf13e',
            '.title', title,
            '.message', message || ''
        )
    }
    
    function decryptText() {
        var encrypted = data('application/x-copyq-encrypted')
        if (encrypted.size() == 0)
            return data(mimeText)
        var decrypted = plugins.itemencrypted.decrypt(encrypted)
        return unpack(decrypted)[mimeText] || data(mimeText)
    }
    
    var text = decryptText()
    if (text.size() == 0) {
        abort()
    }
    
    hide()
    // Wait to focus a target window.
    sleep(initialDelay)
    
    try {
        notify('Typing text...')
        for (var i = 0; i < text.size(); i += maxChars)
            typeText( text.mid(i, i + maxChars) )
        notify('Text typed.')
    } catch (e) {
        notify('Failed to type!', e)
    }"
Icon=\xf2d2
InMenu=true
Name=Paste Text in Wayland
Shortcut=return

Edit (2020-12-22): I've added the updated command to copyq-commands repository. See Sway and Wayland Support.

[zsolt-donca]

Hi everybody!

First of all, thanks for the amazing work on copyq, and in particular on the wayland support!

I've recently moved full-time to wayland using sway, and in need of a clipboard manager, started using copyq compiled from the wayland branch mentioned here. I didn't have any issues until I stumbled into this one: swaywm/wlroots#2548 In a nutshell, if an XWayland-client application copies something large to the clipboard (couple of hundred kilobytes) and copyq is running, then simply sway crashed. It turned out to be an issue in xwayland's clipboard support.

With the given patch suggested in the thread, there are no more crashes and copy/pasting now works in all circumstances correctly with the only exception being copyq (quoting):

The only issue I've found is around copyq: if I have it running, pasting doesn't work immediately after copying, and I need to try to paste a couple of times to get something out, and even then the output is messed up with sections of the text repeating. If I take a look at the contents of the clipboard inside copyq's UI, there isn't only a single entry (as it should), but multiple ones with various fragments of the text, and also some weird binary-looking entries. Can this be because of issues with the above code? Either way, I am running copyq's experimental wayland branch, so this might be just a bug in it.

Also quoting @Xyene 's response:

Yeah, I'm not surprised it doesn't work well. What's basically happening is:

• the X11 application requests the contents of the clipboard
• the clipboard contents are too large to be sent in one go, so they have to be sent incrementally
• wlroots starts sending chunks of clipboard data
• partway through this, the application requests the contents of the clipboard again

I'm not sure what should be done in this case. The patch above just resets the transfer to the beginning, which is probably why you're seeing garbled text: you'd get part of the old transfer and part of the new.

Since @Xyene's patch seems to work well when copyq is not involved, including when using another clipboard manager (https://github.com/yory8/clipman), then I'm wondering if there is something that copyq could be doing differently?

[hluk]

@zsolt-donca Thanks for the info. X11 clipboard was always wonky when it comes to bigger data (probably related to how Qt handled it).

I have been using development version of CopyQ with Sway for a while without any big issue.

Most of the Wayland fixes were merged to master branch (not yet released though).

The "wayland" branch now contains only fixes for notifications. But this is a big change so I might not be merging any time soon -- it adds dependencies which make building the code difficult on other platforms and, since this uses native notifications, not everything may work on some systems - e.g. rich text and buttons in notifications.

To launch the app with proper Wayland support (instead of X11 or XWayland):

1. Build the code from the "wayland" branch (or master if you don't care about notifications).
2. Set QT_QPA_PLATFORM=wayland environment variable.
3. Add Sway and Wayland Support command to have copy/paste and other features.

[zsolt-donca]

Thank you for your answer, @hluk !
I did not know that the master branch practically had wayland support - that means that I can just use copyq-git from AUR to get a proper build (instead of rolling my own).

I just retested everything just as you recommended: with the env variable (which I always had), with the latest master and with the Sway and Wayland support script installed (which I didn't have it before, as it was, and still is, working without it). It seems to me the same: pasting right after copying might not work at all, requiring me to copy it once again, and the contents are only partial. However, I was just able to find a full entry in copyq's history, but I am not sure if this is an improvement or just luck...

On the technical side, how does the wayland support work? Is copyq relying on Qt for accessing the clipboard, or is it directly using some lower-level API? The reason I'm asking is that in the thread in wlroots, the issue is suspected to be related to copyq copying the contents of the clipboard to soon, before the previous transfer is complete. Is this something that can be addressed in copyq, or is this in some external dependency, such as in Qt?

[hsantanna]

Related to Bug #1644

[gowallasnewpony]

Didn't really got it to work with Wayland. What I did is turning Wayland off in Manjaro Gnome what is an easy task:
Manjaro Hello --> Gnome Layouts Manager --> Settings --> toggle Wayland off
I don't care for Wayland as long as I have CopyQ working properly! CopyQ is the ruler above all others! Thank you hluk!

[beruic]

@hluk in light of the fact that Ubuntu 22.04 will have Wayland on by default:
How is this issue coming along? What is the status?

[cmprmsd]

I have trouble with copying from and to VMware Player and Workstation vms when in Sway. I tried both xcb and wayland frontends 😢

But this might be a Wayland issue. When I slowly move over the top part of the VMware ui data gets copied to xwayland forth and back correctly and is displayed in the vm.

But if you switch without the mouse e.g. hostkey+left or right, then the clipboard is not being updated between both systems :(

[cmprmsd]

@hluk Hey Lukas,
I have another strange behaviour on Wayland. Often, when I want to select an older image from the clipboard history, the image is truncated while it is pasted to e.g. xwayland windows.

The following shows the issue when I copy a screenshot to Signal. Signal in xwayland and copyQ natively running with: QT_QPA_PLATFORM=wayland exec copyq

When I use wl-paste > test.png the image is not truncated.
Should I open a new issue or is this related to this ongoing general issue?

[hluk]

I will remove the custom code and update the rest from the latest kguiaddons code base in #1944.

Unfortunately, the updated clipboard handling code does not work well - I see a lot of timeouts. I will probably have to revert back to use the multi-threaded code.

[cmprmsd]

Oh okay :(
May there be a way to analyze the timeouts and find a root cause for them?

[cmprmsd]

Great! In the mean time I migrated my browser to Wayland. So Signal is the only bad boy left. :)

[hluk]

I've added workaround to the Wayland Support commands to support clipboard monitoring on Gnome. The clipboard monitor process would launch using XWayland (if available).

[username0136]

@hluk Please add perfect support for wayland fedora 36 is going to release soon and I have heard that it will only use wayland so no xorg but I really like this tool I want this to support wayland it's been a year I am watching this issue 😢

[hluk]

Please add perfect support for wayland fedora 36 is going to release soon and I have heard that it will only use wayland so no xorg but I really like this tool I want this to support wayland it's been a year I am watching this issue cry

@git-Hmmm I've been using CopyQ on Wayland for a long time and for my use cases it works fine. Is there any specific issue you have?

[username0136]

@hluk It doesn't stores copying history and not even able to paste.

[ntzb]

@hluk I've installed ydotool and the wayland support script, and it mostly works when double clicking from the history window ("mostly" because it's not pasted correctly in some windows (namely the terminal) - Ubuntu 22.10/GNOME 43).
is there a way to make it also work when selecting from the tray?

[grass29]

What is the command for toggling the tray menu? I.e. like 'copyq toggle', but for the tray menu?

P.S. Found it: copyq menu

[Gufderald]

@hluk I've installed ydotool and the wayland support script, and it mostly works when double clicking from the history window ("mostly" because it's not pasted correctly in some windows (namely the terminal) - Ubuntu 22.10/GNOME 43). is there a way to make it also work when selecting from the tray?

Same here. Have you found some workaround?

[ntzb]

unfortunately, no..

[Gufderald]

unfortunately, no..

Have you tried opening another issue? What compositor do you use? I'm running Hyperland.

Tried to investigate this for a couple of hours. There is a chance that there is an ydotool problem - I couldn't make none of my terminal emulators (gnome-terminal, kitty, alacritty, foot) to perform a "paste" action with shortcut, mentioned in wayland support script:

        sendShortcut('42:1', '110:1', '110:0', '42:0')

UPD: my bad, seems i forgot quotes. It works, and it repeats copyq paste behaviour for me: one time it can paste nothing, another time it can paste previous (not current) component of clipboard, and another time it can paste some random component, which is specific until I restart copyq.

[Gufderald]

@ntzb opened a new issue for this problem, also found some workaround. Feel free to visit it if it is actual XD
#2557

[zhanglongqi]

the shortcut works after I added an empty shortcut in system settings under KDE NEON wayland desktop.

[elbowz]

the shortcut works after I added an empty shortcut in system settings under KDE NEON wayland desktop.

Same on:

Operating System: Arch Linux
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-arch1-1 (64-bit)
Graphics Platform: Wayland

But it uses the last window position and size...no under mouse cursor.

I have also tried copyq triggerGlobalShortcut "Show main window under mouse cursor" after install Wayland Support script without luck.