crashes on hyprland since 0.56

[ExpandingMan]

lan-mouse has been crashing hyprland for me since 0.56. This happens on the client only (i.e. the machine being controlled). I was able to capture the following lines from stderr

Io error: Too many references: cannot splice (os error 109)
[2026-08-05T03:06:56Z ERROR input_emulation::wlroots] Io error: Too many references: cannot splice (os error 109)
[2026-08-05T03:06:56Z ERROR input_emulation::wlroots] Io error: Too many references: cannot splice (os error 109)
[2026-08-05T03:06:56Z WARN  lan_mouse::emulation] input emulation exited: error emulating input: `wayland error: `Io error: Too many references: cannot splice (os error 109)``
[2026-08-05T03:06:56Z INFO  lan_mouse::emulation] releasing capture: 192.168.1.234:36413 entered this device

This may be a hyprland bug but it does not cause hyprland to produce any logs.

[SturmB]

Corroborating this on Hyprland 0.56.2 with lan-mouse 0.11.0 release. The observed Too many references: cannot splice was the terminal symptom of the InputCapture session leak tracked in hyprwm/xdg-desktop-portal-hyprland#419 and lan-mouse #472.

The portal log reached input-capture-38, then ConnectToEIS failed with ETOOMANYREFS; xdg-desktop-portal aborted, xdg-desktop-portal-hyprland segfaulted, and the desktop session collapsed. The peer log at the same timestamp showed repeated entering client / immediate releasing capture: ... entered this device / sending Leave event transitions.

Environment: Hyprland 0.56.2, xdph 1.4.1, xdg-desktop-portal 1.22.1, libei 1.6.0, dbus-broker 37. We have disabled the bidirectional automatic-backend setup pending session reuse and portal cleanup fixes.

[ExpandingMan]

For reference, I did some more investigation here. Seems to agree with what @SturmB reports. May be a bug in xdg-desktop-portal or xdg-desktop-portal-hyprland.

[0xFlo]

I reproduced this and opened #491 with a fix.

Cause: State::add_client in the wlroots emulation backend creates a virtual keyboard per emulation client and sends the compositor a keymap descriptor. It is the same descriptor every time. Wayland caps descriptors per sendmsg (MAX_FDS_OUT), so under client-creation churn they queue faster than the compositor drains them and the send is eventually refused.

The reason it surfaces on an idle desktop is that too_many_unix_fds() compares the user's total in-flight SCM_RIGHTS count against the sender's RLIMIT_NOFILE, not this process's descriptor table. A distro with the traditional 1024 soft limit is already near the ceiling before lan-mouse contributes anything.

Reproduction (added as an example in the PR, so it can be re-run):

cargo run --release -p input-emulation --example keymap_fd_churn

On Arch, Hyprland 0.56.2, ulimit -n 2048:

FAILED at iteration 896
error: wayland error: `Io error: Too many references: cannot splice (os error 109)`

With --control, which holds the client count at one and sends the same number of events, descriptors stay flat at 12 and it completes clean. That is what identifies client creation rather than the event path as the source.

Worth noting the threshold is environment dependent: a limit below the machine's ambient in-flight count fails at iteration 0 regardless of this bug, and a limit far above it never trips.

One thing I could not determine: what drove enough client creation on your system to hit this. In my testing the daemon reaps clients for peers that go silent, via the 5s sweep in ListenTask::run, so ordinary use stays bounded. If you have a log from a crash, the number of distinct peer source addresses in it would say whether reconnect churn was involved.