fix(cua-driver): wait for EIS to acknowledge libei input before replying - #4880

What

On GNOME and KDE Wayland, portal input goes through the libei worker (wayland/libei.rs). The worker replied to the caller once the input requests had been flushed to the socket. A flush is not delivery. with_focused_window activates the target, sends input, then restores the user's window. If the compositor had not yet processed the queued input when the restore happened, the input could land in whichever app was restored.

Now, after each input command (click, move, scroll, type, key, key sequence, drag), the worker:

1. sends ei_connection.sync and flushes;
2. keeps the caller's reply pending until EIS sends the callback's done. EIS sends that only after processing every earlier request on the connection;
3. fails the call with EIS did not acknowledge input within 5s; delivery is unknown if no done arrives in 5 s, and EIS connection unavailable for input acknowledgement if there is no connection object.

WaitReady and commands that already failed reply immediately, as before. Callers wait up to 20 s for a reply, so the 5 s window fits inside it. The event loop dispatches every 20 ms, so expiry is checked promptly.

Behaviour change to note: on a compositor that is slow to process input, a call that used to report success optimistically can now return the "delivery is unknown" error. That is the intended trade: the result now reflects what the compositor confirmed.

Credit

Ported verbatim from T3 Code's Linux patch to Cua Driver 0.34.0: pingdotgg/t3code#16975, patches/cua-driver-linux/0.34.0.patch. T3 Code is MIT-licensed, Copyright (c) 2026 T3 Tools Inc. T3 validated it live on GNOME (their installed build 2757). The THIRD_PARTY_NOTICES row comes with #4877 and is extended once that merges.

Testing

• libei.rs is behind the portal-input feature. CI: Rust Linux unit compiles it (cargo check -p cua-driver --features portal-input), but the default unit run does not include it.
• There is no unit test for the acknowledgement path: it needs a live EIS server. The Linux live smoke uses Xvfb (X11), so it does not exercise libei either.
• Live evidence is T3's GNOME validation. A GNOME VM check on our side is a follow-up (Linear).

Linear: CUA-1237 (tracking CUA-1233)

🤖 Generated with Claude Code