https://bugs.kde.org/show_bug.cgi?id=524613
Bug ID: 524613
Summary: Remote Input from android is not working with Bazzite
Classification: I don't know
Product: kde
Version First unspecified
Reported In:
Platform: Bazzite
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Title: Remote input (mousepad) fails on Wayland — RemoteDesktop portal
CreateSession never receives a Response, no permission dialog shown
Summary:KDE Connect's remote input (mouse/keyboard) plugin fails completely on
a fresh Plasma Wayland session. kdeconnectd logs "Unable to handle remote
input. RemoteDesktop portal not authenticated" and "Failed to create session
with code 2" in a tight loop (~20ms interval, one new CreateSession call with a
fresh handle token every iteration). No system permission dialog for remote
control ever appears.
Steps to reproduce:
Fresh Bazzite (Fedora 44-based) install, Plasma 6, Wayland session, Nvidia RTX
3060 (nvidia-open driver).
Pair an Android device via KDE Connect.
On the Android device, open the remote input / touchpad screen and attempt to
move the mouse.
Observed result:
journalctl --user -f | grep kdeconnect spams: kdeconnectd[PID]: Unable to
handle remote input. RemoteDesktop portal not authenticated kdeconnectd[PID]:
Could not create the remote control session
QDBusError("org.freedesktop.DBus.Error...
dbus-monitor "interface='org.freedesktop.portal.RemoteDesktop'" shows
kdeconnectd issuing a new CreateSession call roughly every 20ms, each with a
unique handle_token/session_handle_token, without waiting for a response to the
previous call.
No KWin permission dialog for remote control is ever shown.
Isolating the cause:To rule out kdeconnectd-specific behavior, I manually
invoked the same portal method directly:
gdbus call --session --dest org.freedesktop.portal.Desktop --object-path
/org/freedesktop/portal/desktop --method
org.freedesktop.portal.RemoteDesktop.CreateSession '{"session_handle_token":
<"testsession123">, "handle_token": <"testhandle123">}'
This returns a valid request object path
(/org/freedesktop/portal/desktop/request/.../testhandle123) with no D-Bus
error. However, monitoring that specific request object with:
gdbus monitor --session --dest org.freedesktop.portal.Desktop --object-path
/org/freedesktop/portal/desktop/request/.../testhandle123
never receives a Response signal, and no permission dialog appears on screen —
even when called manually, completely outside of KDE Connect.
This suggests the issue is in xdg-desktop-portal-kde's RemoteDesktop backend
not completing session negotiation / never surfacing the consent dialog, rather
than being specific to kdeconnectd's request handling.
Ruling out portal backend conflicts:To make sure this wasn't a portal
routing/selection issue (e.g. xdg-desktop-portal-gtk being installed alongside
xdg-desktop-portal-kde and picked instead), I checked the shipped portal
configuration:
cat /usr/share/xdg-desktop-portal/kde-portals.conf [preferred] default=kde
org.freedesktop.impl.portal.Settings=kde;gtk;
org.freedesktop.impl.portal.Secret=kwallet
org.freedesktop.impl.portal.Notification=plasmanotify
cat /usr/share/xdg-desktop-portal/portals/kde.portal
Interfaces=...org.freedesktop.impl.portal.RemoteDesktop;...
cat /usr/share/xdg-desktop-portal/portals/gtk.portal
Interfaces=org.freedesktop.impl.portal.FileChooser;... (RemoteDesktop NOT
listed)
RemoteDesktop is only advertised by kde.portal, and default=kde is set with no
competing backend for that interface. No /etc or ~/.config overrides exist for
xdg-desktop-portal. This confirms the router has no ambiguity and correctly
dispatches RemoteDesktop.CreateSession to
org.freedesktop.impl.portal.desktop.kde — consistent with what dbus-monitor
showed. The failure is therefore isolated to xdg-desktop-portal-kde's internal
handling of the RemoteDesktop session/consent flow (likely its communication
with KWin to show the consent dialog), not a portal selection or third-party
backend conflict.
Cross-application confirmation (not KDE Connect specific):While investigating
further, kdeconnectd's error changed on a later attempt from "RemoteDesktop
portal not authenticated" (silent non-response) to an explicit D-Bus error:
kdeconnectd[PID]: Could not create the remote control session
QDBusError("org.freedesktop.DBus.Error.AccessDenied", "Portal operation not
allowed: Unable to open /proc//root")
This exact error string — "Portal operation not allowed: Unable to open
/proc//root" for both RemoteDesktop and ScreenCast session creation, with no
permission dialog ever shown — has also been reported independently against
Sunshine (a game-streaming server, completely unrelated to KDE Connect) on KDE
Plasma 6.6 Wayland / Fedora KDE:
https://github.com/LizardByte/Sunshine/issues/4753
This strongly suggests the bug is not specific to kdeconnectd's request
handling, but is a broader issue in xdg-desktop-portal-kde's RemoteDesktop (and
possibly ScreenCast) session creation path on recent Plasma/portal-kde
versions, affecting any client application that requests these portals.
I ruled out the more common causes of "Unable to open /proc/PID/root":
SELinux: system is in Enforcing mode, but `ausearch -m avc -ts recent` and
`journalctl -k` show no relevant AVC denials for either kdeconnectd or the
portal.
Yama ptrace_scope: /proc/sys/kernel/yama/ptrace_scope = 0 (unrestricted).
/proc hidepid mount option: not set (mount shows plain `proc on /proc type proc
(rw,nosuid,nodev,noexec,relatime)`, no hidepid=).
systemd sandboxing: neither kdeconnectd.service nor
xdg-desktop-portal.service/xdg-desktop-portal-kde have ProtectProc, ProcSubset,
PrivateUsers, or NoNewPrivileges restrictions set (all default/unrestricted).
Environment:
OS: Bazzite (Fedora 44 base), immutable/rpm-ostree
kdeconnectd: 26.04.3-1.fc44
xdg-desktop-portal-kde: 6.7.4-1.fc44
Plasma: 6.x (Wayland session)
GPU: Nvidia RTX 3060, nvidia-open driver
(ghcr.io/ublue-os/bazzite-nvidia-open:stable)
Session type confirmed via $XDG_SESSION_TYPE = wayland
org.freedesktop.impl.portal.desktop.kde confirmed running and registered on the
session bus (busctl --user list)
Note: Bazzite's KDE image ships no X11 session (/usr/share/xsessions/ is
empty), so X11 fallback could not be tested.
Additional notes:
Bluetooth speaker media control via KDE Connect (MPRIS-based) works correctly,
confirming the base KDE Connect ↔ Wayland session pairing/connection is
otherwise healthy.
This appears to be a fresh package combination given Bazzite's rolling nature;
may not yet be widely reported.
--
You are receiving this mail because:
You are watching all bug changes.
