Skip to content

Home

Jump to bottom
Coldaine edited this page Oct 12, 2025 · 1 revision

Welcome to the ColdVox wiki! Short answer: Yes — libportal / the RemoteDesktop (InputCapture) portal is reaching practical maturity and is worth trying, but treat it as “stable-ish but still evolving” and always provide a ydotool (uinput) fallback for users/compositors that don’t fully support every portal backend. ([libportal.org]1)

Here’s the evidence + what to watch for.

What the web shows (high-value findings)

  • libportal exposes a complete RemoteDesktop / InputCapture API (Xdp.Portal.create_remote_desktop_session and friends) you can call from apps (C/GObject, Python bindings via gi, Vala, etc.). The API is documented and intended for exactly this use. ([libportal.org]2)
  • Desktop support is real and shipping: KDE Plasma added Remote Desktop features in Plasma 6.1 and upstream docs and announcements reference the RemoteDesktop portal. Many distributions/desktops advertise support. That means on modern Plasma 6.x installs there is a real path for portal-based input injection. ([KDE]3)
  • But it’s not identical everywhere — backend differences exist. Some portal backends (xdg-desktop-portal-gtk, xdg-desktop-portal-wlr, xdg-desktop-portal-kde, etc.) vary in whether they implement RemoteDesktop / InputCapture fully; some backends lacked or lagged InputCapture/RemoteDesktop support historically. You need to verify the portal backend on your target distro/compositor. ([GitHub]4)
  • There are a few outstanding rough edges reported upstream: session persistence/restore is a known feature request and there are occasional reports of input going unresponsive after authorization in specific configurations. These have been discussed and tracked (issues/PRs), which indicates active maintenance but also that some edge cases remain. ([GitHub]5)

Practical verdict

  • Mature enough to try in production if you:

    1. Test thoroughly on the specific KDE Plasma 6.x versions and Linux distributions you target. Plasma 6.1+ is explicitly mentioned as supporting this route. ([KDE]3)
    2. Detect portal availability at runtime and handle failures gracefully. If the portal or backend isn’t present or the user declines permission, fall back to ydotool (uinput) for immediate compatibility. (This hybrid approach is exactly what real STT apps do.) ([libportal.org]2)
    3. Implement robust session handling and reconnection logic — be prepared for the session to be closed by screensaver/sleep and for different backends to behave slightly differently (session persistence is still being improved). ([GitHub]5)

Quick engineering checklist (to decide “go / no-go”)

  1. Check runtime support on your target machine

    • xdg-desktop-portal --version (or check package versions for xdg-desktop-portal, xdg-desktop-portal-kde/-gtk/-wlr).
    • Confirm the backend supports org.freedesktop.portal.RemoteDesktop / InputCapture. (If unsure, test a simple create_remote_desktop_session call — see example below.) ([Flatpak]6)

  2. Prototype a minimal libportal client (or use Python gi bindings) to request a RemoteDesktop session and keyboard_key(); confirm the permission prompt appears and keys arrive in the focused window. ([libportal.org]2)

  3. Test across targets: Plasma 6.1/6.2, GNOME 46+, and any wlroots-based DEs you care about (some wlroots backends added or lag RemoteDesktop support). ([GitHub]4)

  4. Plan fallback: implement the ydotool/uinput fallback (documented setup) and automatic fallback in code. Real projects use that pattern for robustness. ([libportal.org]1)

  5. Watch issues: especially session persistence/restore and occasional unresponsive-input reports — include reconnection and user guidance in your UX. ([GitHub]5)

Minimal Python prototype (libportal / gi) — use for testing only 

# Requires: pygobject + libportal bindings available via gi (and a portal backend that supports RemoteDesktop)
import gi
gi.require_version('Xdp', '1.0')
from gi.repository import Xdp, GLib

def on_created(src, res, user_data):
    try:
        session = src.create_remote_desktop_session_finish(res)
        print("Session created:", session)
        # request keyboard device (example, adapt to bindings)
        session.request_devices(Xdp.DeviceType.KEYBOARD)
        # later: session.keyboard_key(keycode, True/False)
    except Exception as e:
        print("Failed to create session:", e)
        loop.quit()

portal = Xdp.Portal()
portal.create_remote_desktop_session_async(None, on_created, None)
loop = GLib.MainLoop()
loop.run()

(Adapt for sync/async style you prefer; use session.keyboard_key or the binding’s equivalent per the libportal docs.) ([libportal.org]2)

Final recommendation

  • Yes — try libportal (RemoteDesktop) as your first-class path, especially if you want a secure, user-authorized, Wayland-native solution.
  • But don’t rely on it alone yet: implement a tested ydotool/uinput fallback and a test matrix across the Plasma/GNOME/wlroots variants you plan to support. That hybrid pattern gives the best UX today and the best forward compatibility tomorrow. ([libportal.org]1)

If you want, I’ll:

  • (A) Build a small, runnable test app (Python) that tries libportal RemoteDesktop and logs success/failure and the observed behavior on your machine; or
  • (B) Produce a short compatibility matrix and CI test plan (which distro/compositor versions to test and exactly what to assert).

Which one do you want me to do next?

Clone this wiki locally