Your Linux desktop has two clipboards, and the reason goes back to a 1980s design decision Wayland chose to keep

Published Nov 5, 2026, 1:30 PM EST I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account Did you know that, on many Linux distributions, you can highlight text, move to another window, and click the middle mouse button to paste? You never pressed Ctrl+C, and if you press Ctrl+V in the same spot, you'll probably see entirely different text. That's all thanks to the fact that Linux desktops can use two separate selections: PRIMARY, which holds highlighted text, and CLIPBOARD, which handles explicit copying and pasting. Sometimes it's not obvious which you're using, either. For example, I've got used to using Shift+Insert to paste in some places, but that shortcut is actually inconsistent across applications. Depending on your terminal emulators, that might paste PRIMARY, but in others, such as Konsole, it pastes CLIPBOARD. A regular GTK text box also treats Shift+Insert as a clipboard paste, meaning that the same shortcut can pull different text depending on the currently focused window. The reason this exists is older than Linux itself, with roots in the X Window System from 1987. The X Window System assigned PRIMARY a fixed atom number in its protocol in 1987, which was a time where Xerox PARC and Sun Microsystems were already using primary and secondary selections in their own systems. The conventions that governed X11 selections were made the following year, with contributions from engineers at Sun, DEC, and MIT. Even Wayland, which was designed to replace X11, eventually brought PRIMARY back. GNOME 50 has now disabled middle-click paste by default, but the selection itself hasn't gone anywhere. Linux has a selection and a clipboard, and they work differently Two buffers, one desktop For starters, CLIPBOARD behaves the way you'd expect if you're used to Windows or macOS. You choose to cut or copy something into it, then paste it when you need it. PRIMARY is different; selecting text in an app that supports it will usually update the selection automatically, and a middle click will then paste those contents. If you copy a URL to CLIPBOARD, highlight a sentence somewhere else, you can paste either one depending on the shortcut you use. In X11 applications own their selections, and they're not transferred automatically to the X server. Ownership, in this case, means that the application supplies the data when requested. When pasting, the application you're pasting into will request the selection through the X server, and that request gets forwarded to its owner. That application then provides the data. There are some useful consequences as a result of that design, too. A receiving app can ask which formats are available and choose a preference, which allows copied content to arrive as plain text in a terminal or as formatted text in a word processor. The downside is that this also means closing the application you copied from can leave you with nothing to paste, because the owner is now gone. The freedesktop.org clipboard specification, published in 2000, highlights this exact problem and the solution proposed was a clipboard daemon that could preserve the data after an app exits. That's what a clipboard manager does today. Funnily enough, there's even a third selection that's called SECONDARY, along with an older mechanism known as cut buffers, though neither sees much use today. The freedesktop.org specification only has this to say about SECONDARY: "No one ever does anything interesting with SECONDARY as far as I can tell." Yeah, makes sense. The idea of a primary selection predates X Xerox and Sun got there first Terms like "primary selection" and "secondary selection" were already in use at Xerox PARC by 1983. The Cedar Manual from June of that year describes the Tioga document editor's primary selection as "A chunk of text that has been distinguished, usually by mouse clicks, as an argument to a future editing operation," while the secondary selection served "as the second argument to a future editing operation." You were able to make a primary selection, hold Shift and select another piece of text, and that would be copied to the primary selection's caret. Tioga was even swap the two selections around. The clipboard that Cedar had wasn't really a clipboard in the way we think of them today. Copying in Tioga happened directly between selections without using an intermediate buffer, though Xerox's editors took different approaches to this. Larry Tesler, creator of the world's first dynamic object oriented programming language, wrote that "The term copy and paste appears to have originated in Gypsy," which was an editor he built at PARC in the mid-1970s. However, both the Xerox Star and BravoX editors skipped a separate clipboard. Sun took a different approach with its early window system. Looking at the SunOS 1.1 User's Manual from January 1984, it describes a facility that "called a selection, which provides for limited inter-tool communication and mouse-oriented text manipulation." You would click the left mouse button to select a character, use the middle button to extend selection, and open a menu with the right click button. This menu contained "Stuff" as its lone entry, which inserted the selected text "as though they had been typed at the keyboard." That didn't have to be the same window where the selection was made, either. With SunOS 2.0 in 1985, Sun's dbxtool debugger added a new shortcut, where a user could press Shift and right-click at the same time to "stuff" the selection without needing to open the menu. SunView, which arrived with SunOS 3.0 in February 1986, expanded this system into four "ranks" of selection: the Caret (wjhich was the insertion point), Primary, Secondary, and "Shelf." The Shelf effectively served as a clipboard, with Sun's programmer's guide describing it as "the global buffer which is loaded by Delete and Put operations, and which may be retrieved by a Get operation." Each operation had its own function key, and holding one down also allowed users to make a secondary selection. Sun explains that this let you "perform an operation without disturbing the current primary selection and insertion point." I'm sure you've noticed that none of these systems actually use the middle mouse button to paste, though. Middle clicking in Cedar selected whole words, and SunOS 1.1 and SunView used it for adjusting the size of a selection. Even influential hardware like the Blit, a graphics terminal built by Rob Pike and Bart Locanthi at Bell Labs in the early 1980s, used the middle button "for local operations such as editing," but that referred to opening a pop-up menu, not pasting text. The middle-click paste behaviour that Linux users are now familiar with appeared from elsewhere. Middle-click paste arrived with X11 in 1987 X10 used a right click instead X10 was the predecessor to the X Window System still in use today, and it didn't have X11-style selections. What it used instead was a global chunk of text stored on the X server known as a cut buffer, and any app could read or overwrite it. if you used X10R3's xterm after February 1986, you could drag with the middle mouse button to save text into the cut buffer, then use a right click to "type" it back into the terminal. X10R4 arrived later that year, but pasting also required holding Shift. The xterm manual from that era even warned that "Since the cut buffer is globally shared among different applications, you should regard it as a 'file' whose contents you know." X11 then came in September 15, 1987, and its xterm rearranged those controls. In X11R1, "The left button is used to save text into the cut buffer," while "The middle button 'types' (pastes) the text from the cut buffer." This is the earliest mention I could find of selecting with left-click and pasting with middle-click, but it still relied on a cut buffer rather than a selection. The xterm source file responsible for those controls is credited to Jim Gettys under a 1987 DEC copyright, but it doesn't say who actually made that decision in the first place. X11's protocol defined selections from the very beginning, granting special status to PRIMARY and SECONDARY. In X11R1's Xatom.h header, PRIMARY is predefined as atom 1 and SECONDARY as atom 2, while the eight cut buffers occupy atoms 9 through 16. Meanwhile, CLIPBOARD is nowhere to be found, including in the X11R1 protocol specificaiton. Even though it's almost 40 years later, the X11 protocol still actually assigns PRIMARY and SECONDARY the same numbers. They're part of the wire protocol that X clients and servers use to communicate, and changing them would break compatibility. Those numbers have no bearing on the behaviour of selections, though. The original specification states that "predefined" is "only in the sense of having numeric values, not in the sense of having required semantics," and that "The selection atom is uninterpreted by the server." In other words, X11 made it possible for applications to own and request named selections, but the rules that actually say how they should be used were kept separately. The ICCCM defined how X11's selections should work The clipboard was originally for deleted text The Inter-Client Communication Conventions Manual, or ICCCM, is what established how X11 applications should interact with eachother. Its first draft arrived with X11R2, written by David Rosenthal of Sun Microsystems on February 25, 1988. Rosenthal's acknowledgements state that "The author's role in preparing this document was limited to asking questions and writing down the answers; the ideas are all due to others," while the selection section credits "Jerry Farrell, Phil Karlton, and Bob Scheifler." Phil Karlton was at DEC and Bob Scheifler was at MIT, which is where he led the design of X. Jerry Farrell is listed in the X11R1 contributors file simply as "Jerry Farrell, Sun," with his name appearing first in the ICCCM's selection credits through to 1994. He was difficult to find information on, though, as I wanted to establish if he had worked on Sun's own selection service. ICCCM's first draft defines CLIPBOARD in a way that sounds very similar to SunView's Shelf. It states that "The selection named by the atom CLIPBOARD is used to hold deleted data," and describes a "single, special client" that takes ownership of the clipboard and preserves whatever has been deleted. SunView's Shelf, meanwhile, was "loaded by Delete and Put operations." ICCCM's draft also assigns SECONDARY two different purposes: "As the second argument to commands taking two arguments, for example 'exchange primary and secondary selections'" "As a means of obtaining data when there is a primary selection, and the user does not wish to disturb it" These are, essentially, the same roles that secondary selections fulfilled in Cedar and SunView. PRIMARY's job, in contrast, was "used for all commands which take only a single argument." There's still nothing about automatically copying highlighted text or pasting it with the middle mouse button. CLIPBOARD's definition had changed by the time ICCCM 1.0 was finalised in July 1989. At the time, it became "data being transferred between clients, normally being 'cut' or 'copied', and then 'pasted'," which is a lot closer to how we use it today. X11R3 had already arrived in October 1988, bringing an xterm that made highlighted text "the PRIMARY selection when the button is released." Middle-clicking now pasted "from the PRIMARY selection, if any, otherwise from the cut buffer." X11R3 also brought xclipboard, the dedicated clipboard client described by the ICCCM. Sun later made the relationship between the two systems explicit with XView, the company's toolkit that it developed to bring SunView's programming interface to X. It was contributed to X11R4 in 1989, and included a function that mapped their selections directly. SunView's Primary became X's PRIMARY, Secondary became SECONDARY, and the Shelf became CLIPBOARD. XView's text editor also kept SunView's function keys for Put, Get, and Delete, but renamed the operations Copy, Paste, and Cut, with the Shelf now called the Clipboard. Apps spent a decade disagreeing on how it should be used Freedesktop settled it in 2000 ICCCM may have defined three different selections, but it left room for interpretation that applications took full advantage of. By 2000, there were two primary interpretations: Qt 2 and GNU Emacs 20: PRIMARY for everything, including highlighting text, middle-click paste, and explicit cut, copy, and paste commands. Netscape, Mozilla, XEmacs, and some GTK apps: CLIPBOARD for explicit copying and pasting while reserving PRIMARY for highlighted text and middle-click paste. If you were using programs that differed in their interpretation, copying and pasting between them could be, well, unpredictable. To address this, a freedesktop.org clipboard specification adopting the second approach was published in December 2000 by Havoc Pennington of Red Hat, and Qt 3 and GNU Emacs 21 respected it. These rules ultimately defined what Linux desktops do today: selecting text updates PRIMARY without replacing CLIPBOARD, middle-click pastes PRIMARY rather than CLIPBOARD, and explicit paste commands retrieve CLIPBOARD. At the time, Pennington described PRIMARY as "an 'easter egg' for expert users, regular users can just ignore it; it's normally pastable only via middle-mouse-click." The developer of Lucid Emacs, Jamie Zawinski, had already been following that convention for several years, explaining his reasoning in a 1997 Usenet post. His problem with the old cut buffers was that their contents had to be transferred to the X server immediately, rather than supplied on request, which was a big deal for X terminals at the time. He noted that until around 1994, he was "still doing a lot of my development on an X terminal that only had a 38.4kbps connection to the host machine." His commentary on cut buffers pulls no punches: "Obsolete. Never, ever, ever use them. Ever." Some applications, including xterm, still support cut buffers as a fallback. Wayland kept PRIMARY, and GNOME switched off pasting Only the default has changed Wayland was created as a replacement for X11, and its core protocol doesn't define an equivalent to X11's PRIMARY selection. However, a separate primary selection protocol, copyrighted by Red Hat in 2015 and 2016, was developed to provide "a primary selection device to match that of the X server." GTK initially used its own version before adding support for the shared protocol in GTK 3.24.23 in 2020, as compositors like KWin only supported the shared one. Today, GNOME's Mutter, KDE's KWin, Sway, Hyprland, COSMIC, and plenty of others support the protocol, although Wayland's reference compositor, "Weston," is a notable exception. GNOME 50 broke that convention, though. On January 3, 2026, GNOME developer Jordan Petridis opened a merge request to change the default value of gtk-enable-primary-paste from true to false, calling middle-click paste "an X11ism" and arguing that "dumping your entire clipboard while having no indication that this will happen is nothing short of a dumpster fire." He closed off the commit message with "Goodbye X11," and the pull request was merged on January 9 before shipping with GNOME 50 in March. It's also important to note that Petridis' assertion that it dumps "your entire clipboard" is incorrect, as strictly speaking, it pastes PRIMARY rather than CLIPBOARD. Because the merge request's discussion was restricted to project members, objections instead appeared in a GNOME Discourse thread titled "Please retain middle-click paste." Firefox declined to follow GNOME's lead, even with Petridis submitting a matching proposal to disable middle-click paste in Firefox on Linux. It was closed as WONTFIX, with Firefox's Martin Stránský arguing that disabling primary selection should happen at the compositor level rather than in individual applications. "There's nothing actionable on Firefox side, we're not going to add Firefox hacks only for it," he wrote. As for other desktop environments, KDE Plasma already provides a setting to disable middle-click paste, and a Fedora KDE proposal that would disable it by default is still open at the time of writing. GNOME only changed the default behaviour, though. What this setting controls is whether GTK applications paste PRIMARY on a middle click, even while GTK's own built-in default for that property is still set to true. GNOME's compositor can still supports the primary selection protocol, and the underlying mechanism hasn't been removed. Anyone who wants middle-click paste back can restore it with a single command: gsettings set org.gnome.desktop.interface gtk-enable-primary-paste true I'm not a GNOME user, so I don't have any first-hand experience when it comes to non-GTK applications and how they behave when the setting is disabled. Firefox, for example, can still handle middle-click pastes separately and continues using PRIMARY if the compositor supports it. Still, it was a noticeable change for some users. If Wayland had wanted to leave PRIMARY behind, it had plenty of opportunities, but Red Hat's own devised protocol intentionally brought it back instead. The most significant undertaking in trying to move away from this convention is GNOME 50, but the actual change is pretty minor. Middle-click paste is disabled by default in GTK applications, but PRIMARY still exists underneath, and GNOME's compositor still supports it. Nearly 40 years after PRIMARY was defined in X11, GNOME has changed how people interact with it while still refraining from removing the mechanism itself.