Remove Linux screen capture support due to xcap maintenance burden

[codefromthecrypt]

Motivation

The xcap crate's Linux support creates significant maintenance burden:

Heavy dependencies

xcap 0.5.0+ requires pipewire, wayland, dbus, and other system libraries not available in standard CI/cross-compilation environments. Issue #3914 raised by @DOsinga - xcap contributes to large binary size.

Cross-compilation blockers

• Cross-rs uses Ubuntu 20.04 for glibc compatibility
• Ubuntu 20.04 lacks pipewire in standard repos
• PPA approach fails due to GPG signature issues in Docker
• PR chore: Bump xcap to 0.7.0, let android can cargo build without extra patch #4344 attempted xcap 0.7.0 upgrade, was closed after months of CI failures

Version lock

To avoid Linux deps, we're locked to xcap 0.4.0 which:

• Uses objc2 (fixes macOS core-foundation 0.10.1 compatibility)
• Only needs dbus + xcb on Linux (already in Cross.toml)
• v0.4.1+ adds libwayshot, v0.5.0+ adds pipewire/zbus

Proposal

Remove screen capture support on Linux while keeping it on macOS/Windows.

Alternatives Considered

Alternative	Why not
Keep xcap 0.4.0 forever	Locks us to old version, miss bug fixes
Fork xcap with feature flags	Maintenance burden, xcap issue #35 open since Jan 2023
Custom Dockerfile for cross	Complex, fragile, Ubuntu 20.04 PPA issues persist
Disable xcap entirely	Loses useful macOS/Windows functionality

Implementation

Use conditional compilation to exclude screen capture on Linux:

#[cfg(not(target_os = "linux"))]
use xcap::{Monitor, Window};

#[cfg(not(target_os = "linux"))]
#[tool(...)]
pub async fn list_windows(...) { ... }

#[cfg(not(target_os = "linux"))]
#[tool(...)]  
pub async fn screen_capture(...) { ... }

Update Cargo.toml:

[target.'cfg(not(target_os = "linux"))'.dependencies]
xcap = "0.8.0"

[jmservier]

I could agree the original motivation around reducing maintenance burden on Linux – especially the issues caused by PipeWire, Wayland, and friends in our current cross‑compilation setup. However, I think the assumption that “Ubuntu 20.04 must remain our base image for glibc compatibility” is no longer valid in 2026 and is worth revisiting.

Ubuntu 20.04’s standard support effectively ended in April 2025. From that point on, continuing to build new releases on top of 20.04 means:

• relying on a base system that is itself deprecated (outside of ESM),
• getting increasingly stale system libraries,
• and fighting the distro every time we want to use newer desktop/multimedia stacks like PipeWire.

By contrast, the current LTS releases provide more modern glibc while still being actively supported:

• Ubuntu 22.04 LTS ships glibc 2.35
• Ubuntu 24.04 LTS ships glibc 2.39

Historically, we chose Ubuntu 20.04 primarily to minimize the required glibc version so that the binaries would run on as many distributions as possible. But once that base LTS falls out of standard support and newer LTS releases have moved to glibc 2.35 / 2.39, it is reasonable to assume that most of our target users are also in the process of migrating, or already have migrated, to similarly recent environments.

In other words, there is diminishing value in continuing to optimize for very old glibc versions when the underlying distribution is itself deprecated. At the same time, the cost of staying on 20.04 keeps growing:

• we need PPAs or ad‑hoc workarounds to get up‑to‑date PipeWire and Wayland,
• container images become harder to maintain securely,
• and the “Linux screen capture is too hard to support” conclusion is largely a side effect of clinging to an obsolete base.

Given that, I think it is healthier for the project to:

1. Move the cross‑compilation base from Ubuntu 20.04 to a supported LTS (22.04 or 24.04).
2. Explicitly document the new minimum supported glibc version (2.35 or 2.39, depending on the choice).
3. Once that’s done, re‑evaluate the Linux screen‑capture support with xcap, now that PipeWire and Wayland are first‑class citizens in the official repositories of these LTS releases.

This approach keeps our build story aligned with modern, supported distributions, removes the need to maintain workarounds on top of an EOL base, and gives us the option to restore Linux screen capture without the same level of CI and Docker complexity. It also sets a clearer, more sustainable expectation for users: if they are still on much older systems, they are already outside the mainstream support window of their own distro, and it is reasonable that our binaries target current LTS baselines instead.

Overall, I think migrating the base image to a current Ubuntu LTS and then revisiting the xcap decision is a more future‑proof path than continuing to optimize our tooling around Ubuntu 20.04, which is now effectively deprecated.

[codefromthecrypt]

@jmservier unless you are answering as "we" like you work on cross, the main implication is that the 20.04 is coming from cross not us directly..

https://github.com/cross-rs/cross/blob/main/docker/Dockerfile.x86_64-unknown-linux-gnu#L1

So, the "Custom Dockerfile for cross" thing I had in the alternatives, if that bumps past 20.04, we need to figure out why cross are locked in that base version and what if anything it does to the process if we raise it, right? Do you have time to try it out?