github-starred/lan-mouse
2
0
Fork 0
mirror of https://github.com/feschber/lan-mouse.git synced 2026-05-15 14:15:52 -06:00
Code Issues 107 Projects Packages Wiki Activity Actions

[GH-ISSUE #220] "device not responding" when typing (keyboard) from Linux to MacOS #103

New issue
Closed
opened 2026-05-05 22:09:32 -06:00 by gitea-mirror · 9 comments
gitea-mirror commented 2026-05-05 22:09:32 -06:00
Owner
Copy link

Originally created by @PedroHLC on GitHub (Oct 31, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/220

On 7496015d8d, when typing from Linux/wlroots (capture) to MacOS (emulates), if I enter two keys quickly (same second) some random key gets stuck instead, output on MacOS side starts repeating the following:

WARN  lan_mouse::server::ping_task] client not responding, releasing pointer!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `No route to host (os error 65)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`
WARN  lan_mouse::server::ping_task] device not responding, releasing keys!
WARN  lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)`

It only stops when I kill -KILL it, Ctrl+C shows INFO lan_mouse::server] terminating service but never exists.

The same does not happen if I invert the actors (MacOS captures, wlroots emulates), and I can keep the connection going for hours if I type very slowly.

I always need to restart it on the MacOS side.

On top of that, good work overall with this app, been using it sporadically since February!

NOTE: With the macOS, I only tested this commit and commit 9248007986. When I tried 9248007 in the macOS, the other machines couldn't connect to it at all, and I skipped directly to the last commit, this last commit connects, but I need to ssh machine -- killall -KILL lan-mouse when I forget about this issue.

Originally created by @PedroHLC on GitHub (Oct 31, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/220 On 7496015d8d36fe58cc2f915991e90d1acc1aa9cd, when typing from Linux/wlroots (capture) to MacOS (emulates), if I enter two keys quickly (same second) some random key gets stuck instead, output on MacOS side starts repeating the following: ``` WARN lan_mouse::server::ping_task] client not responding, releasing pointer! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `No route to host (os error 65)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` WARN lan_mouse::server::ping_task] device not responding, releasing keys! WARN lan_mouse::server::network_task] udp send failed: network error: `Host is down (os error 64)` ``` It only stops when I `kill -KILL` it, `Ctrl+C` shows `INFO lan_mouse::server] terminating service` but never exists. The same does not happen if I invert the actors (MacOS captures, wlroots emulates), and I can keep the connection going for hours if I type very slowly. I always need to restart it on the MacOS side. --- On top of that, good work overall with this app, been using it sporadically since February! NOTE: With the macOS, I only tested this commit and commit 9248007986ade8a0690ce37bccbf463927d2df6b. When I tried `9248007` in the macOS, the other machines couldn't connect to it at all, and I skipped directly to the last commit, this last commit connects, but I need to `ssh machine -- killall -KILL lan-mouse` when I forget about this issue.
gitea-mirror commented 2026-05-05 22:09:34 -06:00
Author
Owner
Copy link

@PedroHLC commented on GitHub (Nov 11, 2024):

I'm unable to reproduce this in the latest commit.

<!-- gh-comment-id:2468214013 --> @PedroHLC commented on GitHub (Nov 11, 2024): I'm unable to reproduce this in the latest commit.
gitea-mirror commented 2026-05-05 22:09:36 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Nov 11, 2024):

Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)

<!-- gh-comment-id:2468222044 --> @feschber commented on GitHub (Nov 11, 2024): Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)
gitea-mirror commented 2026-05-05 22:09:36 -06:00
Author
Owner
Copy link

@mechanicpanic commented on GitHub (Nov 26, 2024):

I have the same issue right now (installed 0.10 with cargo on both sides), Hyprland -> MacOS. Anything I could try? Because otherwise I love the app, using two machines is super useful for me - thanks!

<!-- gh-comment-id:2500507228 --> @mechanicpanic commented on GitHub (Nov 26, 2024): I have the same issue right now (installed 0.10 with cargo on both sides), Hyprland -> MacOS. Anything I could try? Because otherwise I love the app, using two machines is super useful for me - thanks!
gitea-mirror commented 2026-05-05 22:09:37 -06:00
Author
Owner
Copy link

@grodius commented on GitHub (Mar 19, 2025):

Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)

I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse

<!-- gh-comment-id:2737473083 --> @grodius commented on GitHub (Mar 19, 2025): > Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;) I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse
gitea-mirror commented 2026-05-05 22:09:38 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Mar 19, 2025):

Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)

I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse

It would be very helpful, if you could provide the logs from when this happens

<!-- gh-comment-id:2738475271 --> @feschber commented on GitHub (Mar 19, 2025): > > Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;) > > I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse It would be very helpful, if you could provide the logs from when this happens
gitea-mirror commented 2026-05-05 22:09:39 -06:00
Author
Owner
Copy link

@grodius commented on GitHub (Mar 19, 2025):

Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)

I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse

It would be very helpful, if you could provide the logs from when this happens

`

lan-mouse-error.log

`

sorry about that - here you go

<!-- gh-comment-id:2738560986 --> @grodius commented on GitHub (Mar 19, 2025): > > > Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;) > > > > > > I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse > > It would be very helpful, if you could provide the logs from when this happens ` [lan-mouse-error.log](https://github.com/user-attachments/files/19354809/lan-mouse-error.log) ` sorry about that - here you go
gitea-mirror commented 2026-05-05 22:09:39 -06:00
Author
Owner
Copy link

@grodius commented on GitHub (Mar 24, 2025):

Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;)

I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse

It would be very helpful, if you could provide the logs from when this happens

something I notice, is i've never seen anything involving fingerprint in either client's UI, should I?

and also - are both machines supposed to be "clients"?

<!-- gh-comment-id:2748595131 --> @grodius commented on GitHub (Mar 24, 2025): > > > Sorry I did not respond earlier. The whole response tracking / ping logic has changed with the encryption stuff, hopefully it's working better now ;) > > > > > > I am having an issue where the ping_task is failing, using hyprland -> macos like the above user. It works perfectly until the task fails then I have to kill the process on the mac to release the server's keyboard/mouse > > It would be very helpful, if you could provide the logs from when this happens something I notice, is i've never seen anything involving fingerprint in either client's UI, should I? and also - are both machines supposed to be "clients"?
gitea-mirror commented 2026-05-05 22:09:40 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Mar 24, 2025):

The fingerprint UI is going to come with version 0.11 soon™. Technically both machines are servers in <= 0.10 but this is now also going to change in that the controlling machine is now a client.

<!-- gh-comment-id:2748629944 --> @feschber commented on GitHub (Mar 24, 2025): The fingerprint UI is going to come with version 0.11 soon™. Technically both machines are servers in <= 0.10 but this is now also going to change in that the controlling machine is now a client.
gitea-mirror commented 2026-05-05 22:09:40 -06:00
Author
Owner
Copy link

@grodius commented on GitHub (Mar 24, 2025):

The fingerprint UI is going to come with version 0.11 soon™. Technically both machines are servers in <= 0.10 but this is now also going to change in that the controlling machine is now a client.

ok.. thought maybe a misconfig of both declaring each other as "clients" could be forcing some loop and breaking the ping...

i hate to push a generous and talented dev into user support... but any idea what is going on with my set up? I posted the trace above too big to paste.

my configs:

hyprland machine (keyboard/mouse)

release_bind = [ "KeyA", "KeyS", "KeyD", "KeyF" ]

port = 4242

frontend = "gtk"

[right]
hostname = "mbp.lan"
activate_on_startup = true
ips = ["192.168.8.186", "192.168.8.187"]

mac ("client")

port = 4242
frontend = "cli"

clients
position = "left"
hostname = "gn0.lan"
ips = ["192.168.9.96"]
activate_on_startup = true

edit for formatting

<!-- gh-comment-id:2749316121 --> @grodius commented on GitHub (Mar 24, 2025): > The fingerprint UI is going to come with version 0.11 soon™. Technically both machines are servers in <= 0.10 but this is now also going to change in that the controlling machine is now a client. ok.. thought maybe a misconfig of both declaring each other as "clients" could be forcing some loop and breaking the ping... i hate to push a generous and talented dev into user support... but any idea what is going on with my set up? I posted the trace above too big to paste. my configs: **hyprland machine (keyboard/mouse)** > release_bind = [ "KeyA", "KeyS", "KeyD", "KeyF" ] > > > port = 4242 > > frontend = "gtk" > > [right] > hostname = "mbp.lan" > activate_on_startup = true > ips = ["192.168.8.186", "192.168.8.187"] > > **mac ("client")** > port = 4242 > frontend = "cli" > > > [[clients]] > position = "left" > hostname = "gn0.lan" > ips = ["192.168.9.96"] > activate_on_startup = true edit for formatting
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
attach-dialog-to-window
windows-msi-installer
config-watcher
fix-ci
update-cachix-workflow
build-on-22.04
update-ci
save-config
macos-fix-scroll-capture
improve-connection-reliability
improve-macos-capture
macos-capture-modifier-keys
reset-double-click-on-move
fix-duplicate-key-release
emulate-double-click
fix-scrolling
prevent-authorization-request-spam
revert-scrolling-behaviour
up-deps
macos-cleanup-event-thread
macos-input-capture-fix
fix-gtk-widget-parent
fix-clippy-warnings
fix-mandatory-client-config
connection-accept-notification
change-config-syntax
rework-cli-frontend
feschber-patch-1
gtk-frontend-rework
dns-fix
remove-git-dep
encryption
fix-wl-object-recreation
macos-client-side-modifier-events
log-keypress
fix-key-repeat
cleanup-server
cleanup
extract-frontend
drop-hard-dep-shortcut-inhibit
include-commit-hash-in-version
capture-dummy-events
local-channel
lan-mouse-proto
cleanup-capture-task
derive-barrier-id-from-cursor
capture-error-handling
purge-anyhow
drop-dispatch-hack
split-crates
configurable-emulation-backend
configurable-capture-backend
hyprland-fix
fix-UB-transmute
fix-usize-assumed-8-bytes
enter-hook
display-util
fix-display-scaling
x11-event-producer
main
lan-mouse-proto-v0.2.0
lan-mouse-ipc-v0.2.0
lan-mouse-gtk-v0.2.0
lan-mouse-cli-v0.2.0
input-event-v0.3.0
input-emulation-v0.3.0
input-capture-v0.3.0
v0.10.0
v0.9.1
input-emulation-v0.2.1
v0.9.0
input-emulation-v0.2.0
input-capture-v0.2.0
input-event-v0.2.1
input-event-v0.2.0
input-emulation-v0.1.0
input-capture-v0.1.0
input-event-v0.1.0
v0.8.0
v0.7.3
v0.7.2
v0.7.0
v0.6.0
v0.5.1
v0.5.0
v0.4.0
v0.3.3
v0.3.2
v0.3.1
v0.3.0
v0.2.1
v0.2.0
v0.1.1
v0.1.1-alpha.1
0.1.1-alpha.1
Labels
Clear labels   
Xorg

   
documentation

   
enhancement

   
macos

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
windows
No labels
Xorg
documentation
enhancement
macos
pull-request
question
windows
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/lan-mouse#103
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?