press_key should use the active portal RemoteDesktop keyboard session

[maxburto]

Summary

On Plasma Wayland, press_key should use the already-active XDG RemoteDesktop keyboard session before falling back to ydotool.

Observed behavior

The bundled Codex Desktop copy (codex-computer-use-linux 0.3.1-linux-alpha1) has a working portal keyboard-session path: Plasma type_text obtains ensure_portal_keyboard_session() and uses it for the KDE clipboard paste chord. However, the press_key handler parses the requested chord and unconditionally invokes ydotool:

// src/server.rs, press_key (installed build lines 1124-1136)
let Some(key_events) = key_sequence(&params.key) else { /* ... */ };
let mut args = vec!["key".to_string()];
args.extend(key_events);
let result = run_ydotool(&args).await.map(|output| vec![output]);

This ignores the cached/active portal keyboard session even though the RemoteDesktop portal can inject keyboard keycodes for a started keyboard-enabled session.

Impact

press_key needs a user-scoped ydotoold, /dev/uinput access, and a master build of ydotool on this Plasma system solely for key combos. Capture and pointer/input consent are already handled by the portal, but keyboard consent is a separate portal grant; once granted, the active keyboard session should be the preferred route.

Requested behavior

When a portal keyboard session is active (or can be established according to the existing backend policy), translate the press_key chord to portal keycodes and send it through that session. Preserve ydotool as the existing fallback when no keyboard session is available. The result should identify the backend used.

Acceptance

• On Plasma Wayland with a keyboard-enabled RemoteDesktop session, targeted press_key Ctrl+S saves a focused Kate document with no ydotool binary or daemon installed.
• If keyboard consent is absent or the portal send fails, the existing fallback/error behavior remains explicit.
• The implementation keeps the current focus verification before input.

[avifenesh]

Thanks for the excellent report — the observed-behavior analysis was spot on: press_key never consulted the portal session that type_text already establishes.

Implemented in #51: chords are parsed into evdev codes by a shared parser and sent through the existing press_keycode_chord portal path whenever a keyboard session is already active (reusing your granted consent even when ydotool is present), when ydotool is absent, or when COMPUTER_USE_LINUX_FORCE_PORTAL_KEYBOARD is set. Plasma is included for chords (the KDE exclusion only applies to literal text, which routes to the clipboard backend). Portal failures surface explicitly and clear the cached session; ydotool remains the fallback.

Unit tests, fmt, and clippy are green, but I don't have Plasma hardware in the loop — if you're able to build the fix/press-key-portal-keyboard branch and confirm the Ctrl+S-into-Kate acceptance case on your system, that would be very helpful before it ships.