Package: kwin-wayland Version: 4:6.3.6-1 Severity: normal Tags: upstream KWin's libeis backend logs a single, contextless line when it fails to add an input device to an EIS client's session:
kwin_libeis: Libeis: Failed to add device, disconnecting client No device type, no error code, and no further detail precedes or follows it in the journal. The effect is that the entire EIS client connection is torn down, not just the one device that failed to add. Every input-injection call the client makes afterward fails at the socket level (broken pipe / EPIPE on the client side) for as long as that client keeps trying to use the now-dead connection. ENVIRONMENT (where this was observed) - kwin-wayland 4:6.3.6-1 (Debian 13/trixie) - libeis1 1.3.901-1 - xdg-desktop-portal-kde 6.3.5-1 - Client: lamco-rdp-server, an RDP server using libei (via the RemoteDesktop portal) for input injection OBSERVED Fired twice within a 12-hour period on the same machine, both times within under a minute of the client establishing or re-establishing its EIS session. In the more visible case, 35 seconds after an RDP client reconnected, every mouse and keyboard injection attempt failed with a broken pipe (500+ occurrences logged client-side) until the RDP client itself gave up and disconnected roughly 7 minutes later. To the end user this presented simply as "keyboard and mouse stopped working." UPSTREAM STATUS Filed upstream as https://bugs.kde.org/show_bug.cgi?id=525307. It was auto-closed RESOLVED/UNMAINTAINED by KDE's bug-janitor bot within half an hour, on version-support grounds (6.3.6 predates KDE's current support window), not on technical merits -- the bot suggested reporting to Debian instead, which is what this is. FRESH EVIDENCE THIS MAY BE TRIXIE-SPECIFIC I reproduced the same disconnect/reconnect sequence against a KWin 6.7.4 / libeis1 1.5.0-3+b1 host (Debian sid) today. Three consecutive disconnect-then-reconnect cycles against the same lamco-rdp-server client produced zero "Failed to add device" occurrences in the KWin journal -- clean reconnects every time, where the trixie host fails close to reliably. So this looks like it may already be fixed somewhere between libeis 1.3.901 and 1.5.0, or between KWin 6.3.6 and 6.7.4, rather than being a live upstream bug -- but I don't have the means to bisect which package or which exact change fixed it. REQUEST Given the above, this may be resolvable either by backporting whatever fixed it to trixie's libeis/kwin, or simply noting it as fixed upstream if that's confirmed. Happy to provide the full journal excerpt from either machine, or test further, if that helps narrow it down. -- System Information: Distributor ID: Debian Description: Debian GNU/Linux 13 (trixie) Release: 13 Codename: trixie Architecture: amd64 Kernel: Linux 6.12.101+deb13-amd64
