Posted on by Martin Flöser

Synchronizing the X11 and Wayland clipboard

One of the greatest annoyances after switching my work systems to Wayland is the lack of clipboard synchronization between the X11 and Wayland windowing system. X11 clipboard is only available to X11 windows and the Wayland clipboard is only available to Wayland windows. It’s the useability problem of the two X11 clipboard (primary and secondary) just exposed on a much higher and more annoying way. Instead of “just” remembering whether you copied or selected text, you need to remember which windowing system you copied from and which windowing system the current window is in. And if they are not in the same, there is just no way.

So getting this problem resolved got quite a priority. It was something I had never really spent any thought on and incorrectly assumed it’s something Xwayland would take care of. But after thinking about the problem I realized that the X11 clipboard is part of ICCCM and not a core feature of the X-Server. It’s a communication protocol between clients.

This means that KWin had to learn to communicate with the X11 clipboard in order to provide the synchronization. Not an easy task as ICCCM is quite complex on this topic and implementing an X11 clipboard is nothing I’m looking forward to. Luckily I remembered that we have a clipboard manager for X11 (klipper) and that this one works without having X11 specific code thanks to Qt’s abstraction.

And this makes the whole thing way easier: by using Qt’s X11 clipboard implementation we only need to interact with Wayland’s clipboard which is thanks to KWayland quite straight forward. The solution involves a small helper binary which gets started by KWin. It’s forced to the xcb windowing system to be able to use Qt’s X11 clipboard and manually connects with KWin through KWayland. The task of the binary is quite simple: whenever the X11 clipboard changes it gets the data and sets it on the Wayland clipboard. Similar whenever the Wayland clipboard changes it gets set on the X11 clipboard.

Unlike the X11 clipboard on Wayland clients are normally not informed about clipboard changes. Only the application currently having keyboard focus gets informed by the Wayland server about what kind of data is available on the clipboard. This means we don’t need to inform all Wayland clients about changes in the X11 clipboard and similar we don’t need to inform X11 about clipboard changes in Wayland all the time. Instead KWin helps the process: when an X11 window gains keyboard focus our helper process gets informed about the current Wayland clipboard content, so that it can be available for the focused X11 window and while X11 windows are focused clipboard changes from the helper application are forwarded to Wayland. So when the next Wayland window gets focused it has the clipboard content set on X11. A small and simple solution which works quite well in practice. At the moment only the “real” clipboard is synchronized. There is not yet the concept of the selection based clipboard on Wayland. A solution might be to just synchronize it to the normal clipboard. But this would again introduce the useability problems of this non-explicit clipboard. So I’m not yet convinced what’s the proper way.

In my last blog post I pointed to our current donation campaign to support the Randa developer sprint. A lot of readers donated after reading this. I want to thank everybody who donated. It’s so important for a free software community to meet in person and we need donations for getting developers to sprints and conferences. Last week I was at openSUSE conference and had a talk about how Wayland improves the quality of Plasma. These are important things to talk about at a conference, but it’s only possible if we have the donations to send people there. Please help to make such developer sprints possible. Thank you!

45 Replies to “Synchronizing the X11 and Wayland clipboard”

  1. First of all, thank you for the constant, high quality work on KWin!

    > There is not yet the concept of the selection based clipboard on Wayland.
    Thats sounds a bit frustrating to me, as I use the two different clipboard types regularly and do not want to mix them up. Here is my typical work flow:
    -> I use the regular clipboard (ctrl+c) for more constant things (such as urls, things to remember for later usage) which i like to recall later (using klipper).
    -> I use the middle click clipboard to quickly copy/paste things in the terminal or in an text editor.
    => mixing this things up, will result in situations where many entries are pushed out of the klipper history by some temporary nonsense.

    Are there any alternative concepts on Wayland? I was impressed by the smoothness of some Wayland build and would really like to use it (when it is a bit more stable).

    1. We need to see. I think the current situation on X11 is really bad and confusing. If we come up with a solution it must be way better.

      1. Whatever the solution, I think it would be excellent if the actual action that triggers paste from the selection clipboard can be reassigned to something other than middle click.

    1. Doesn’t address the useability problems I see with the primary selection. Also does not even address the security issues they mention in the same page.

      1. Err… Please, could you elaborate on the usability problem? Because ATM the only usability problem with primary selection I see — is its absence.

        In fact, it is being one of the two «less known but very important» features, without which I can’t count a DE as ready to use. The second one is the Compose key, but I think I could workaround if .XCompose wouldn’t work — e.g. to try creating an extension to an input method. But absence of primary clipboard couldn’t be «workarounded» by anything except the DE.

        1. Please, could you elaborate on the usability problem?

          has it never happened to you that you copied from the wrong clipboard? You selected something and then pasted with ctrl+v? That’s part of the usability problem. Another problem is that it only works for text and you never know whether it worked or not. You will know once you paste. Not before.

          1. Nope, it never happened to me. They somehow clearly separated in my mind, plus if I selected something, I usually want to paste it just at that moment, and not minutes or hours later, because otherwise I know: one more selection, and everything would disappear.

            The problem that images never copied with primary selection seem to be something that definitely should not be solved by removing it completely ?

          2. In fact, I just made an experiment: I selected an image in browser, opened «New Message» in KMail, enabled «Rich Text» there, and pasted with middle mouse. Image were pasted along with the text — so yes, primary selection does work for non-text too.

          3. It did happen to me and it’s annoying as hell. Imo there’s no need for multiple clipboards because they introduce more issues than solve. And most people thinking otherwise only say so because they’re long time X11 users and they don’t wanna change their habits.

            1. This is not true — I’m using GNU/Linux just ?5-6 years, not sure if it’s a «long time X11 user». And I felt in love with the feature once I noticed it. In fact, it is a GNU/Linux specific killer feature, it would be silly to remove.

              How is that annoying to you? Just don’t use it if you don’t like it, is that so hard?

          4. No, never*. The concepts of “clipboard” and “selection” are completely separate in my mind. Primary selection is not clipboard.

            That it works only for text (didn’t know that, BTW. I suppose I haven’t ever tried it on anything else) is a limitation, but hardly a problem for the kind of quick yanking that’s usually done this way. In any way, even with this limitation it’s objectively more usable than no primary selection at all.

            The primary selection is expected to ALWAYS work when an X app lets the user select text. If it doesn’t work, it’s a bug in the application – not with the primary selection concept per se.

            *With the exception of vim, where I used to mix them up for quite some time. However, learning which arcane vim incantation corresponds to which buffer is hardly a problem a common user will ever face ;^)

          5. Just remembered an important thing! There’s a very popular GNU/Linux application relying upon primary selection — it’s Putty! In Windows you copy from it’s terminal just by selecting, and pressing right mouse button. But on GNU/Linux right mouse button just moves selection on its terminal — instead you have to copy with primary clipboard.

      2. Security concerns of primary selection IMO exaggerated. How often do you or anyone select anything that other apps shouldn’t know about? Perhaps it is only passwords, but they would be seen as a dirty talk at TV subtitles — ******.

  3. Mutter and gtk+ already have primary-selection support:
    See https://bugzilla.gnome.org/show_bug.cgi?id=762560
    and https://git.gnome.org/browse/mutter//commit/?id=c6aad6e7

    Currently using their own protocol but, per the commit message, “This protocol is an internal mirror of the primary selection drafts being proposed for wayland-protocols.”

    I’m another very heavy user of primary-selection, including the links and quote in this post.
    Implicit copying on select is really nice (if you know it exists), but clobbering a shared buffer all the time would just make it a pain.

  4. As Till said, thanks for the quality work!

    Probably not the best post to ask about this, but what are the plans for rdp on Wayland?

        1. remote login is nothing we have looked into yet. How that best makes sense is something I don’t know yet. You can already run KWin in a headless mode, so basically it’s all there. One “just” needs to hook up that it gets started.

  5. The current situation on X11 is completely invisible to people who don’t know about the selection keyboard. Therefore, it cannot *possibly* be more confusing than only having a ctrl-c/ctrl-v clipboard.

    1. Not quite – it’s possible to accidentally middle-click, especially on trackpads that use finger-counting or ‘click both buttons’ instead of a dedicated centre button. That leads to text being pasted unexpectedly.

      1. especially if one is to use the libinput driver for touchpads on x11 where the clickpad gets three soft buttons which aren’t configurable.

        Took me some time to figure out what kept closing my browser tabs.

  6. This might be a stupid question, but I’m wondering why is the clipboard tied to X11 or Wayland at all ? Couldn’t it be implemented as say a daemon or dbus service, independently of the graphical environment ?

    I just wish terminal applications could use it as well (without adding a dependency on X11), so that the clipboard, the vim buffers and readline and emacs kill rings could all share the same data (with some network transparency).

    1. Sure one could also design a clipboard based on DBus. No idea why it wasn’t done that way.

      1. I don’t want this to devolve into a flamewar, but it’s probably because dbus isn’t very well-liked. It’s a pain to interface with, but does some things which no other IPC mechanism on Linux does, so it’s a necessary evil to many. But as can be seen from the discussion around the kdbus patchset, dbus is far from ideal in many cases, and it would be best if Linux had an IPC mechanism on which more complex protocols such as dbus could then be built.

        I know first-hand how much of a pain dbus is, because some mpv lua script I use to provide MPRIS2 functionality is implemented on top of a Lua library which wraps a Lua library which wraps the dbus library and still manages to get it wrong by not providing the proper introspection stuff.

        Inadequate IPC is what has hampered the Linux desktop for a long time now, which is why every ecosystem implements its own use-case-specific IPC, e.g. PulseAudio, X11, Wayland, and so on.

  7. Hi Martin,

    Awesome work yet again! This has actually been a worry for me after I bumped really hard into a similar problem in Ubuntu Touch. I’m not clear on the technical details of that and won’t go further. Suffice it to say I’m glad to hear a very sane solution for Plasma.

    Thanks for your hard work as always!

  8. > There is not yet the concept of the selection based clipboard on Wayland.

    This is not entirely true. We have been working on adding a primary selection that works in parallel to the regular clipboard. You can see the initial thread from last year here: https://lists.freedesktop.org/archives/wayland-devel/2015-December/026084.html

    The protocol went through a series of improvements, and the latest iteration, although a private gtk_ protocol, is used by mutter and GTK+ already. The intention is to move that protocol into wayland-protocols making it a properly wp_ prefixed etc. See the gtk_ version here: https://git.gnome.org/browse/mutter/tree/src/wayland/protocol/gtk-primary-selection.xml

    1. Good to know, thanks for working on it. Though after looking at it, this unfortunately doesn’t solve the problem of the bad useability/discoverability.

      2. I don’t think usability is bad at all – separate clipboards are necessary so the user can interact with things without overwriting explicitly-copied content, and copy-paste using only the mouse is very quick.

        Discoverability is, as you say, about as bad as it gets.

        1. Yeah, ?¹, happened to me either: copy with primary selection just because don’t want to overwrite the secondary clipboard.

          About discoverability — it’s not a problem of primary selection specifically. It’s just like that: a user either knows it, and uses, either they don’t know, and don’t use it. But I do agree, it would be nice to have some hint after a distro was installed about the primary selection with a checkbox like «don’t show it anymore» — in the end, primary selection is a killer feature of GNU/Linux desktops, and it’s sad to see some people don’t know about it.

      3. I agree that its a non-optimal feature, and should probably be disabled by default due to the easter-egg-ness of it. However, in order to not force the user who insist on using select-copies-middle-click-pastes to know what backend each application uses, we concluded that a primary-selection like feature would need to imitate the one on X11, so that it won’t be too surprising what happens on middle click. That being said, nothing in the protocol makes it hard to make it discoverable via some user interface (like middle-click opens a menu with the option “paste selection” or something).

        1. Yeah, you are right. After thinking about it for a day, I decided that I put it on my todo list for Plasma 5.8.

  9. >Unlike the X11 clipboard on Wayland clients are normally not informed about clipboard changes.

    If this is the case, does this mean X11 wakes up all clients to tell them that the clipboard changed whenever a user modifies the selection, as that is a clipboard of its own?

    1. Looks like it and thinking about it: klipper would not work if not all clients get notified about changes to the clipboard

      1. Screenshot/capture tools have a similar problem with Wayland already.

        Options are (a) do it in the compositor or (b) add a protocol to request/grant more access?

  10. Does this mean we won’t need to run klipper or some other clipboard manager anymore just to make sure the clipboard doesn’t get cleared whenever the source application is closed?

    It’s really retarded we need to run one for this use case, when I really don’t have any other use case for a manager other than that. Having it clutter up my systray is annoying. So I use the hide systray feature, which is also annoying since I can easily forget that something is running cause it thinks it ought to hide away from the use like that. Having plasma go into hide icons by default mode was a retarded decision I will never understand.

    1. Does this mean we won’t need to run klipper or some other clipboard manager anymore just to make sure the clipboard doesn’t get cleared whenever the source application is closed?

      On Wayland clipboard exchange is done between the processes directly. In order to support that when an application is closed a kind of clipboard manager will be needed.

      1. Yes, this ought to be something plasma or kwin or that little clipboard helper should do for the simple single clipboard entry case. Running a full blown clipboard manager that clutters up my systray is just silly.

  11. Btw, I’m curious, are so called «live wallpapers» easier on Wayland? On X11 it was a video playing on the root window, and it were horribly lagging.

  12. While it is of course technically correct that clipboard is not something a traditional X server provides, I would still think that your initial assumption that XWayland would is a good one.

    It is the definitive integration point for an X11 application running in a Wayland setup, so should provide the infrastructure necessary to bridge between the two worlds.

    After all it is a Wayland client that just happens to provide displaying services to another program.
    Just like KRDC or VirtualBox and friends bridge between the host and client worlds.

Comments are closed.