PoC: feat(platform): add system clipboard integration

[kakra]

Summary

• add a platform clipboard abstraction
• publish UTF-8 text through an isolated XCB connection on X11 and Xwayland
• publish UTF-8 text through wl_data_device on native Wayland
• connect the available provider to ImGui's platform clipboard callback

Motivation

ImGui's default Linux fallback only stores clipboard contents inside the current process. Consequently, text copied from an ImGui field cannot reach another desktop client.

Clipboard ownership also requires the owner to keep serving protocol requests. The XCB provider therefore uses a private connection and bounded background event loop. The Wayland provider reuses the application's borrowed display and latest input serial, while keeping its registry, protocol objects, and event processing on a vkShade-owned queue. Neither provider consumes application events.

The abstraction also provides the infrastructure needed by explicit Copy controls for the live log and developer diagnostics.

Scope

The integration publishes text from vkShade to the clipboard of the compositor on which the application runs. On a nested compositor such as Gamescope, this is the nested clipboard namespace. Bridging it to the host clipboard remains the compositor's responsibility.

The current interface covers clipboard writes. Existing ImGui text fields can exercise it through Ctrl+C, and later Copy controls can use the same backend.

Verification

• release build
• all seven unit tests
• runtime X11 smoke test using an independent xclip client:
• TARGETS, UTF8_STRING, TEXT, and STRING were advertised
• UTF-8 clipboard contents were transferred successfully
• native Wayland provider passes build and unit verification; runtime verification remains pending

[Jahfry]

Sorry to post here but don't know if there's a better place.

I'm curious if this will in some form give a game running in gamescope with vkShade running access to/from the system clipboard?

I currently run a hack in Faugus to allow copy/paste (pre-launch: sh -c 'while true; do wl-paste --no-newline | DISPLAY=:1 xclip -selection clipboard 2>/dev/null; sleep 1; done' & && post-launch: killall xclip 2>/dev/null || true).

I could see a lot of value add if vkShade were the solution to that? Maybe using vkShade as a bridge between clipboards in Gamescope and Linux. Since it's already running (even if effects are toggled off, vkShade would need to be running to check for toggles). Might be considered scope creep but if it's doable without massive extra effort I really see it being useful. Maybe a setting in the .ini to enable it and have it off by default.

[kakra]

I'm curious if this will in some form give a game running in gamescope with vkShade running access to/from the system clipboard?

Most likely not, I think rather gamescope would need to bridge the clipboard between the system and its nested compositor. So maybe you should report an issue in the gamescope project?

Also, vkShade has no business in creating such workarounds. If even possible, it would be very hacky, not just scope creep.

Your hack already shows that it is a problem bridging different compositor technologies (Xorg and Wayland) for the clipboard, and it's probably just a missing implementation in gamescope.

[kakra]

Update: this branch now also includes a native Wayland wl_data_device provider.

@Jahfry This does not address your Gamescope use case. Games running through XWayland inside Gamescope use vkShade's XCB provider, and the resulting clipboard remains inside Gamescope's nested namespace. Bridging that namespace to the host clipboard remains Gamescope's responsibility.

The native Wayland provider has passed build and unit verification but remains runtime-untested for now.