X11/XLib中剪贴板选择（Selection）与Atom的工作原理及核心技术疑问

Hey there! Let's dive deep into how X11 Selections (like Primary and Clipboard) work, especially since you're running Arch with Bspwm—no full DE means we get to look at the raw X11 mechanics instead of relying on a desktop environment's abstractions.

1. How GUI apps like Firefox interact with the X11 CLIPBOARD Selection #

First, let's clear up a common misconception: X11 doesn't have a "clipboard buffer" that apps copy data into directly. Instead, Selections work on an ownership + on-demand data transfer model. Here's what happens when you copy text in Firefox:

• When you hit Ctrl+C, Firefox stores the text in its own internal buffer (as you noted).
• At the same time, Firefox claims ownership of the CLIPBOARD Selection. It tells the X server: "Hey, I'm the one holding the CLIPBOARD data right now."
• When a tool like xclip -selection clipboard -o runs, it doesn't read from a pre-filled X11 buffer. Instead, it sends a request to the X server asking for the CLIPBOARD data in a specific format (like UTF-8).
• The X server forwards this request to Firefox (the current owner of CLIPBOARD), which then sends the text data back to xclip via the X server.

That's why xclip can read the data even though Firefox didn't "store" it in some global X11 buffer—Firefox only sends the data when asked, as long as it still owns the Selection (it loses ownership if another app copies something else to CLIPBOARD).

2. Understanding the Atoms in your X11 code #

Let's break down what each Atom does, and why your random-string experiments still work. First, note a small typo in your code: the third argument to XConvertSelection should be target, not str—I assume that's just a copy-paste error.

Key Atom Roles #

• clip: The Selection you're requesting (in this case, CLIPBOARD). This one can't be random—if you changed this to a made-up Atom, the code would fail because there's no owner for that non-existent Selection.
• target: The data format you want to receive (e.g., UTF8_STRING, TEXT).
• prop: A temporary window property name that the Selection owner will use to store the requested data, so your app can read it via XGetWindowProperty.

Why random target and prop Atoms still work #

Random prop Atom

The prop Atom is just a temporary label for the data transfer. X11 doesn't care what name you use here, as long as it's unique to your request (so it doesn't clash with other properties on your window). When you use a random string, XInternAtom creates a new, unique Atom for that string. The Selection owner uses this property to write the data, your app reads it, and then you can (and should) delete the property afterward. Since the name is just a temporary identifier, any unique string works.

Random target Atom

This one is a bit trickier. When you pass a target that the Selection owner (like Firefox) doesn't recognize, the X11 protocol lets the owner fall back to a format it does support. Most text-aware apps will default to sending plain text (usually in UTF8_STRING or COMPOUND_TEXT format) if they get a request for an unknown target. The X server handles this negotiation: if the owner can't provide the requested target, it may send a different format that it thinks is compatible, and your code still reads it because you're using AnyPropertyType in XGetWindowProperty (which accepts any data type).

If you tried a non-text target (like IMAGE_PNG) with a random string, you'd likely get no data back, but for text-focused apps, they'll gracefully fall back to a text format.

A quick improvement to your code #

You should delete the temporary property and free the allocated data after reading it to clean up:

XGetWindowProperty(d, w, prop, 0, ~0, False, AnyPropertyType, &type, &fmt, &nitmes, &bytes_rem, &data);
if (data) {
    printf("%s\n", data);
    XFree(data); // Free the allocated data buffer
    XDeleteProperty(d, w, prop); // Clean up the temporary property
}
quit = 1;

内容的提问来源于stack exchange，提问作者RudraSama