gitea-mirror commented

Owner

Originally created by @simonm on GitHub (Aug 2, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/166

Hello....

Summary:

After configuring each side as per the README.md I cannot seem to get any results at all. No packets on the wire, nothing udp 4242.

Background:

Trying to connect work laptop (macOS on left) and workstation (Arch Linux on right).

Why I am interested in lan-mouse:

I can use waynergy (on wayland) to barrier / synergy1 on macOS but the macOS client processes crash frequently on macOS causing problems.
I can use Synergy3 on both sides with i3 (i.e. X11) and it works perfectly, but I want to use Hyprland (or Sway) on Wayland.

So I would be very happy to use lan-mouse. I don't care which is primary (i.e. where the mouse and keyboard are connected).

Detail:

Trying with domain names:

Arch (name "xenon"):

lan-mouse > list
client 0: simon-laptop-wired:4242 (left), ips: [] active: true, dns: {192.168.8.99}

macOS (name "simon-laptop-wired":

lan-mouse > list
client 0: xenon:4242 (right), ips: [] active: true, dns: {192.168.8.5}

Trying just with IPs:

On Arch:

lan-mouse> list
client 0: 192.168.8.99:4242 (left), ips: [] active: true, dns: {192.168.8.99}

On macOS:

lan-mouse> list
client 0: 192.168.8.5:4242 (right), ips: [] active: true, dns: {192.168.8.5}

Name resolution is fine:

❯ dig A +short xenon
192.168.8.5

❯ dig A +short simon-laptop-wired
192.168.8.99

On Xenon (Linux Wayland) I am packet capturing on all interfaces for anything UDP on port 4242. I get nothing at all. ( sudo tcpdump -i any 'udp port 4242)

All host-based firewalls are disabled.

I've also tried the different options on Wayland for --capture-backend.

I get an error on from lan-mouse on start under Wayland:

[2024-08-02T12:20:22Z WARN  input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `A portal frontend implementing `org.freedesktop.portal.InputCapture` was not found``

However:

❯ ps -ef | grep  xdg
simonm    178501  172988  0 14:22       00:00:00 /usr/lib/xdg-desktop-portal-hyprland
simonm    178698    1116  0 14:22 ?        00:00:00 /usr/lib/xdg-desktop-portal
simonm    178704    1116  0 14:22 ?        00:00:00 /usr/lib/xdg-document-portal
simonm    178708    1116  0 14:22 ?        00:00:00 /usr/lib/xdg-permission-store
simonm    178719    1116  1 14:22 ?        00:00:00 /usr/lib/xdg-desktop-portal-gtk

Is this error expected with Hyprland?

Have I correctly understood that if I want the Linux "hosting" the real keyboard and mouse, that macOS supports "input emulation" and Wayland support "input capture" so we should be ok?

Final thought. Maybe this is related to the xdg error. If no input is captured then there's nothing to send over the wire... Right?

Does anyone have any suggestions to troubleshoot further? I'm sure it's something I am doing incorrectly.

Originally created by @simonm on GitHub (Aug 2, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/166 Hello.... ## Summary: After configuring each side as per the README.md I cannot seem to get any results at all. No packets on the wire, nothing udp 4242. ## Background: Trying to connect work laptop (macOS on left) and workstation (Arch Linux on right). Why I am interested in lan-mouse: - I can use waynergy (on wayland) to barrier / synergy1 on macOS but the macOS client processes crash frequently on macOS causing problems. - I can use Synergy3 on both sides with i3 (i.e. X11) and it works perfectly, but I want to use Hyprland (or Sway) on Wayland. So I would be very happy to use lan-mouse. I don't care which is primary (i.e. where the mouse and keyboard are connected). # Detail: ## Trying with domain names: Arch (name "xenon"): ``` lan-mouse > list client 0: simon-laptop-wired:4242 (left), ips: [] active: true, dns: {192.168.8.99} ``` macOS (name "simon-laptop-wired": ``` lan-mouse > list client 0: xenon:4242 (right), ips: [] active: true, dns: {192.168.8.5} ``` ## Trying just with IPs: On Arch: ``` lan-mouse> list client 0: 192.168.8.99:4242 (left), ips: [] active: true, dns: {192.168.8.99} ``` On macOS: ``` lan-mouse> list client 0: 192.168.8.5:4242 (right), ips: [] active: true, dns: {192.168.8.5} ``` # Name resolution is fine: ``` ❯ dig A +short xenon 192.168.8.5 ❯ dig A +short simon-laptop-wired 192.168.8.99 ``` On Xenon (Linux Wayland) I am packet capturing on all interfaces for anything UDP on port 4242. I get nothing at all. (` sudo tcpdump -i any 'udp port 4242`) All host-based firewalls are disabled. I've also tried the different options on Wayland for `--capture-backend.` I get an error on from lan-mouse on start under Wayland: ``` [2024-08-02T12:20:22Z WARN input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `A portal frontend implementing `org.freedesktop.portal.InputCapture` was not found`` ``` However: ``` ❯ ps -ef | grep xdg simonm 178501 172988 0 14:22 00:00:00 /usr/lib/xdg-desktop-portal-hyprland simonm 178698 1116 0 14:22 ? 00:00:00 /usr/lib/xdg-desktop-portal simonm 178704 1116 0 14:22 ? 00:00:00 /usr/lib/xdg-document-portal simonm 178708 1116 0 14:22 ? 00:00:00 /usr/lib/xdg-permission-store simonm 178719 1116 1 14:22 ? 00:00:00 /usr/lib/xdg-desktop-portal-gtk ``` Is this error expected with Hyprland? Have I correctly understood that if I want the Linux "hosting" the real keyboard and mouse, that macOS supports "input emulation" and Wayland support "input capture" so we should be ok? Final thought. Maybe this is related to the xdg error. If no input is captured then there's nothing to send over the wire... Right? Does anyone have any suggestions to troubleshoot further? I'm sure it's something I am doing incorrectly.

gitea-mirror closed this issue

2026-05-05 22:07:58 -06:00

gitea-mirror commented

2026-05-05 22:07:59 -06:00

Author

Owner

@feschber commented on GitHub (Aug 2, 2024):

Yes, Hyprland does not yet support the input capture portal thats why you're seeing the error with --capture-backend input-capture-portal.

For some trouble shooting:
Could you check, if you're getting events logged to the terminal with

lan-mouse --test-capture

on the hyprland side and

lan-mouse --test-emulation

on the macos side?
(--test-emulation should move the cursor)

This should rule out any not network related issues.

And note that you should only see packets on the wire upon actually moving your mouse on the other device.

@feschber commented on GitHub (Aug 2, 2024): Yes, Hyprland does [not yet support the input capture portal](https://github.com/hyprwm/xdg-desktop-portal-hyprland/issues/64) thats why you're seeing the error with `--capture-backend input-capture-portal`. For some trouble shooting: Could you check, if you're getting events logged to the terminal with ```sh lan-mouse --test-capture ``` on the hyprland side and ```sh lan-mouse --test-emulation ``` on the macos side? (`--test-emulation` should move the cursor) This should rule out any not network related issues. And note that you should only see packets on the wire upon actually moving your mouse on the other device.

gitea-mirror commented

2026-05-05 22:08:01 -06:00

Author

Owner

@simonm commented on GitHub (Aug 5, 2024):

EDIT - I may have misunderstood the purpose of the --test-capture and --test-emulation. You're saying this would rule out any non-network issue? So, my testing was actually useful maybe? Haha!

---- Original response below ----

(sorry.. this turned out longer than I expected).

This is weird and I don't understand...

I have three systems I can easily test with within arms reach:

1- macOS laptop (macOS)
2 - Manjaro (i.e. almost Arch) Linux laptop (Zen)
3 - Arch Linux workstation (Xenon)

The Arch Linux devices have the same dotfiles for most things. I'm running Hyprland, fish shell etc.

Trying what you requested:
--test-emulation on macOS
--test-capture on Xenon
I see mouse movement on macOS in a figure-of-eight shape, as expected. After a short wait (10 or 20sec?) I start to see lots of log messages on Xenon showing the mouse and keyboard activity from Xenon.
That is, me using the keyboard and mouse on Xenon shows in the window where I am running --test-capture, which is on the same host. It doesn't seem that the remote --test-emulation is doing anything at all..

I run the same test in each direction on the two Hyprland devices: i.e. --test-capture on one and --test-capture on the other. Same behaviour as when testing with macOS: I see logs on the device where I run --test-capture which are unrelated to the movement on the device with --test-emulation.

This is the opposite of what I would expect:

I think that I should see the movement from --test-emulation being sent on the network and displayed on the device running --test-capture.
But I don't! I see movement and keys from the device running --test-capture on the same device.

Each of the devices has what I think is a valid config in ~/.config/lan-mouse/config.toml

Here is an example from Xenon:

# cat ~/.config/lan-mouse/config.toml | grep -v '^\s*$\|^\s*#'
release_bind = [ "KeyA", "KeyS", "KeyD", "KeyF" ]
port = 4242
frontend = "Cli"
[right]
hostname = "zen"
ips = ["192.168.11.70"]
port = 4242

In all cases, I see zero network traffic between the two.

tcpdump filters tried:
'port 4242' => i.e. TCP or UDP, SRC or DST.
'host 192.168.11.70' => when run from Xenon should show anything originating from or going to Zen.
'ether multicast' and 'ip broadcast' => Getting desperate here! :-)

Nothing. Nada. Not a sausage.

I'm at a loss. I can only think that I have hugely misunderstood this or made an incorrect assumption...

Maybe I can state what I think is true and then we can educate me a bit more!
My belief is that lan-mouse is a bidirectional mouse and keyboard sharing app that support macOS as a "client" and Hyprland as either a "host" or a "client" which listen on the port configured in ~/.config/lan-mouse/config.toml. If you want Hyprland as a "client" then you need another Hyprland system to be the "host". If supported by the host and client, the keyboard and mouse sharing will work in both directions when the configs are set up.

If I run both process with LAN_MOUSE_LOG_LEVEL=debug then I don't see anything related to connections on either and when I see all of the INFO logging of my local keystrokes on the machine on which I run --test-capture, I see nothing at all being logged on the --test-emulation machine.

Do you have any ideas on how to troubleshoot further?

Question: what is "release_bind"? It's in my config as it was in the default / suggested config. I don't see any notes or docs about what it does in the repo (other than the commit adding it to default config).

I am more than happy to help troubleshoot this, so let me know where to go next! :-)

@simonm commented on GitHub (Aug 5, 2024): EDIT - I may have misunderstood the purpose of the `--test-capture` and `--test-emulation`. You're saying this would rule out any non-network issue? So, my testing was actually useful maybe? Haha! ---- Original response below ---- (sorry.. this turned out longer than I expected). This is weird and I don't understand... I have three systems I can easily test with within arms reach: 1- macOS laptop (macOS) 2 - Manjaro (i.e. almost Arch) Linux laptop (Zen) 3 - Arch Linux workstation (Xenon) The Arch Linux devices have the same dotfiles for most things. I'm running Hyprland, fish shell etc. Trying what you requested: `--test-emulation` on macOS `--test-capture` on Xenon I see mouse movement on macOS in a figure-of-eight shape, as expected. After a short wait (10 or 20sec?) I start to see lots of log messages on Xenon showing the mouse and keyboard activity from Xenon. That is, me using the keyboard and mouse on Xenon shows in the window where I am running `--test-capture`, which is on the same host. It doesn't seem that the remote `--test-emulation` is doing anything at all.. I run the same test in each direction on the two Hyprland devices: i.e. --test-capture on one and --test-capture on the other. Same behaviour as when testing with macOS: I see logs on the device where I run `--test-capture` which are unrelated to the movement on the device with `--test-emulation`. This is the opposite of what I would expect: - I think that I should see the movement from `--test-emulation` being sent on the network and displayed on the device running `--test-capture`. - But I don't! I see movement and keys from the device running `--test-capture` on the same device. Each of the devices has what I think is a valid config in `~/.config/lan-mouse/config.toml` Here is an example from Xenon: ``` # cat ~/.config/lan-mouse/config.toml | grep -v '^\s*$\|^\s*#' release_bind = [ "KeyA", "KeyS", "KeyD", "KeyF" ] port = 4242 frontend = "Cli" [right] hostname = "zen" ips = ["192.168.11.70"] port = 4242 ``` In all cases, I see zero network traffic between the two. tcpdump filters tried: 'port 4242' => i.e. TCP or UDP, SRC or DST. 'host 192.168.11.70' => when run from Xenon should show anything originating from or going to Zen. 'ether multicast' and 'ip broadcast' => Getting desperate here! :-) Nothing. Nada. Not a sausage. I'm at a loss. I can only think that I have hugely misunderstood this or made an incorrect assumption... Maybe I can state what I think is true and then we can educate me a bit more! My belief is that lan-mouse is a bidirectional mouse and keyboard sharing app that support macOS as a "client" and Hyprland as either a "host" or a "client" which listen on the port configured in `~/.config/lan-mouse/config.toml`. If you want Hyprland as a "client" then you need another Hyprland system to be the "host". If supported by the host and client, the keyboard and mouse sharing will work in both directions when the configs are set up. If I run both process with `LAN_MOUSE_LOG_LEVEL=debug` then I don't see anything related to connections on either and when I see all of the INFO logging of my local keystrokes on the machine on which I run `--test-capture`, I see nothing at all being logged on the `--test-emulation machine`. Do you have any ideas on how to troubleshoot further? Question: what is "release_bind"? It's in my config as it was in the default / suggested config. I don't see any notes or docs about what it does in the repo (other than the commit adding it to default config). I am more than happy to help troubleshoot this, so let me know where to go next! :-)

gitea-mirror commented

2026-05-05 22:08:01 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

Sorry, that last update was a monster. Let me try to simplify what I am asking to make it easy for anyone to respond.

What network traffic should I expect to see between - for example - a Linux machine running Hyprland and a macOS device.

I guess, it should be as simple as:

Make sure each machine is in the same L3 network, with no ACLs, port blocking or host-based firewalling.
Start the service on each device with correct config (Name resolution working and IPs reachable.)
Start moving mouse / using keyboard on Hyprland machine.
On either the macOS laptop NIC or on the Hypland machine NIC, I should see traffic on dst port 4242/udp (as per config).

Is this correct?

Do you have any suggestions on what else can I do to try to troubleshoot this issue?

Many thanks in advance and again, apologies for my obvious confusion about this.

I will spend some time looking at this again now. I will report any progress and will try not to write a novel for my next update... :-)

@simonm commented on GitHub (Aug 15, 2024): Sorry, that last update was a monster. Let me try to simplify what I am asking to make it easy for anyone to respond. 1. What network traffic should I expect to see between - for example - a Linux machine running Hyprland and a macOS device. I guess, it should be as simple as: - Make sure each machine is in the same L3 network, with no ACLs, port blocking or host-based firewalling. - Start the service on each device with correct config (Name resolution working and IPs reachable.) - Start moving mouse / using keyboard on Hyprland machine. - On either the macOS laptop NIC or on the Hypland machine NIC, I should see traffic on dst port 4242/udp (as per config). Is this correct? 2. Do you have any suggestions on what else can I do to try to troubleshoot this issue? Many thanks in advance and again, apologies for my obvious confusion about this. I will spend some time looking at this again now. I will report any progress and will try not to write a novel for my next update... :-)

gitea-mirror commented

2026-05-05 22:08:03 -06:00

Author

Owner

@feschber commented on GitHub (Aug 15, 2024):

Sorry, I wanted to get back to you!

--test-capture can be used to see if input can be grabbed from the sending device and should log events to the console when moving the mouse into one of the screen borders.

--test-emulation can be used on the receiving end to verify that input can be emulated.

Both have nothing to do with the actual network functionality.

Your configuration does look correct to me, you can check the assigned IP addresses by hovering over the button next to a host (it should be green if at least one IP is assigned).

You should see traffic on port 4242/udp as soon, as you move your mouse to the other device and the cursor should also get stuck for a moment.

@feschber commented on GitHub (Aug 15, 2024): Sorry, I wanted to get back to you! `--test-capture` can be used to see if input can be grabbed from the sending device and should log events to the console when moving the mouse into one of the screen borders. `--test-emulation` can be used on the receiving end to verify that input can be emulated. Both have nothing to do with the actual network functionality. Your configuration does look correct to me, you can check the assigned IP addresses by hovering over the button next to a host (it should be green if at least one IP is assigned). You should see traffic on port 4242/udp as soon, as you move your mouse to the other device and the cursor should also get stuck for a moment.

gitea-mirror commented

2026-05-05 22:08:05 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

Hi @feschber! No problem for the delay, completely understandable!

Trying again. I am using the UI now and trying to configure the most basic example. I have double-checked the IPs, name resolution etc. I have libadwaita installed on the macOS side (and also on Hyprland).

I'm getting the following logs on the macOS side when I moved the slider to enable the connection to "xenon":

[2024-08-15T11:36:48Z INFO  lan_mouse::server] running service
[2024-08-15T11:36:48Z WARN  input_capture] MacOS input capture backend unavailable: error creating macos capture backend: `MacOS input capture is not yet implemented :(`
[2024-08-15T11:36:48Z WARN  lan_mouse::server::capture_task] input capture exited: error creating input-capture: `no backend available`
[2024-08-15T11:36:48Z INFO  lan_mouse::server::emulation_task] creating input emulation...
[2024-08-15T11:36:48Z INFO  input_emulation] using emulation backend: macos
UNSUPPORTED (log once): POSSIBLE ISSUE: unit 1 GLD_TEXTURE_INDEX_2D is unloadable and bound to sampler type (Float) - using zero texture because texture unloadable
[2024-08-15T11:36:54Z INFO  lan_mouse::dns] resolving (0) `xenon` ...
[2024-08-15T11:36:54Z INFO  lan_mouse::dns] xenon: adding ip 192.168.8.5

(<unknown>:33971): Gdk-CRITICAL **: 13:36:55.006: _gdk_macos_surface_update_fullscreen_state: assertion 'GDK_IS_MACOS_SURFACE (self)' failed

(<unknown>:33971): Gdk-CRITICAL **: 13:36:58.609: _gdk_macos_surface_update_fullscreen_state: assertion 'GDK_IS_MACOS_SURFACE (self)' failed

Are these logs expected?

Again, I see no network traffic in either direction on 4242/udp.

Maybe it would be a better test to do Hyprland <-> Hyprland between a different laptop and the workstation?

@simonm commented on GitHub (Aug 15, 2024): Hi @feschber! No problem for the delay, completely understandable! Trying again. I am using the UI now and trying to configure the most basic example. I have double-checked the IPs, name resolution etc. I have libadwaita installed on the macOS side (and also on Hyprland). I'm getting the following logs on the macOS side when I moved the slider to enable the connection to "`xenon`": ``` [2024-08-15T11:36:48Z INFO lan_mouse::server] running service [2024-08-15T11:36:48Z WARN input_capture] MacOS input capture backend unavailable: error creating macos capture backend: `MacOS input capture is not yet implemented :(` [2024-08-15T11:36:48Z WARN lan_mouse::server::capture_task] input capture exited: error creating input-capture: `no backend available` [2024-08-15T11:36:48Z INFO lan_mouse::server::emulation_task] creating input emulation... [2024-08-15T11:36:48Z INFO input_emulation] using emulation backend: macos UNSUPPORTED (log once): POSSIBLE ISSUE: unit 1 GLD_TEXTURE_INDEX_2D is unloadable and bound to sampler type (Float) - using zero texture because texture unloadable [2024-08-15T11:36:54Z INFO lan_mouse::dns] resolving (0) `xenon` ... [2024-08-15T11:36:54Z INFO lan_mouse::dns] xenon: adding ip 192.168.8.5 (<unknown>:33971): Gdk-CRITICAL **: 13:36:55.006: _gdk_macos_surface_update_fullscreen_state: assertion 'GDK_IS_MACOS_SURFACE (self)' failed (<unknown>:33971): Gdk-CRITICAL **: 13:36:58.609: _gdk_macos_surface_update_fullscreen_state: assertion 'GDK_IS_MACOS_SURFACE (self)' failed ``` Are these logs expected? Again, I see no network traffic in either direction on 4242/udp. Maybe it would be a better test to do Hyprland <-> Hyprland between a different laptop and the workstation?

gitea-mirror commented

2026-05-05 22:08:05 -06:00

Author

Owner

@feschber commented on GitHub (Aug 15, 2024):

The logs seem fine here. The gtk warnings should not matter.

What do the logs on the hyprland side say if you move the cursor into the border?

@feschber commented on GitHub (Aug 15, 2024): The logs seem fine here. The gtk warnings should not matter. What do the logs on the hyprland side say if you move the cursor into the border?

gitea-mirror commented

2026-05-05 22:08:06 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

Hi - I get no logs when I move the mouse to the edge of the screen on the Hyprland side.

Here are logs on startup:

❯ lan-mouse
[2024-08-15T12:04:59Z INFO  lan_mouse::config] using config: "/home/simonm/.config/lan-mouse/config.toml"
[2024-08-15T12:04:59Z INFO  lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt]

(lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:46:1-6: Unknown name of pseudo-class

(lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:96:1-6: Unknown name of pseudo-class

(lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:124:1-6: Unknown name of pseudo-class
[2024-08-15T12:04:59Z INFO  lan_mouse::config] using config: "/home/simonm/.config/lan-mouse/config.toml"
[2024-08-15T12:04:59Z INFO  lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt]
[2024-08-15T12:04:59Z INFO  lan_mouse] Press [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] to release the mouse
[2024-08-15T12:04:59Z INFO  lan_mouse::server] running service
[2024-08-15T12:04:59Z INFO  lan_mouse::server::emulation_task] creating input emulation...
[2024-08-15T12:04:59Z INFO  input_emulation] using emulation backend: wlroots
[2024-08-15T12:04:59Z WARN  input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `A portal frontend implementing `org.freedesktop.portal.InputCapture` was not found``
[2024-08-15T12:04:59Z INFO  input_capture] using capture backend: layer-shell
[2024-08-15T12:04:59Z INFO  lan_mouse::server::capture_task] [(0, (ClientConfig { hostname: None, fix_ips: [192.168.10.172], port: 4242, pos: Left, cmd: None }, ClientState { active: false, active_addr: None, alive: false, dns_ips: [], ips: {192.168.10.172}, pressed_keys: {}, resolving: false }))]
[2024-08-15T12:05:37Z INFO  lan_mouse::dns] resolving (0) `192.168.10.172` ...
[2024-08-15T12:05:37Z INFO  lan_mouse::dns] 192.168.10.172: adding ip 192.168.10.172

Here's some details of the displays on each side.

From Hyprland (on the right of the macOS laptop):

Monitor DP-2 (ID 1):
	3840x2160@59.99700 at 3840x0
	description: BNQ BenQ EW3280U S2M03886019
	make: BNQ
	model: BenQ EW3280U
	serial: S2M03886019
	active workspace: 6 (6)
	special workspace: 0 ()
	reserved: 0 36 0 0
	scale: 1.00
	transform: 0
	focused: no
	dpmsStatus: 1
	vrr: 0
	activelyTearing: false
	disabled: false
	currentFormat: XRGB8888
	availableModes: 3840x2160@60.00Hz 3840x2160@60.00Hz 3840x2160@59.94Hz 3840x2160@50.00Hz 3840x2160@30.00Hz 3840x2160@30.00Hz 3840x2160@29.97Hz 3840x2160@25.00Hz 3840x2160@24.00Hz 3840x2160@23.98Hz 2560x1440@59.95Hz 1920x1200@60.00Hz 1920x1080@60.00Hz 1920x1080@60.00Hz 1920x1080@59.94Hz 1920x1080@50.00Hz 1920x1080@30.00Hz 1920x1080@29.97Hz 1920x1080@25.00Hz 1920x1080@24.00Hz 1920x1080@23.98Hz 1600x1200@60.00Hz 1680x1050@59.95Hz 1600x900@60.00Hz 1280x1024@75.03Hz 1280x1024@60.02Hz 1440x900@60.00Hz 1280x800@59.81Hz 1152x864@75.00Hz 1280x720@60.00Hz 1280x720@60.00Hz 1280x720@59.94Hz 1280x720@50.00Hz 1024x768@75.03Hz 1024x768@60.00Hz 832x624@74.55Hz 800x600@75.00Hz 800x600@60.32Hz 720x576@50.00Hz 720x480@60.00Hz 720x480@59.94Hz 640x480@75.00Hz 640x480@60.00Hz 640x480@59.94Hz 640x480@59.94Hz 720x400@70.08Hz

Monitor DP-1 (ID 0):
	3840x2160@59.99700 at 0x0
	description: BNQ BenQ EW3280U XBM00578019
	make: BNQ
	model: BenQ EW3280U
	serial: XBM00578019
	active workspace: 1 (1)
	special workspace: 0 ()
	reserved: 0 36 0 0
	scale: 1.00
	transform: 0
	focused: yes
	dpmsStatus: 1
	vrr: 0
	activelyTearing: false
	disabled: false
	currentFormat: XRGB8888
	availableModes: 3840x2160@60.00Hz 3840x2160@60.00Hz 3840x2160@59.94Hz 3840x2160@50.00Hz 3840x2160@30.00Hz 3840x2160@30.00Hz 3840x2160@29.97Hz 3840x2160@25.00Hz 3840x2160@24.00Hz 3840x2160@23.98Hz 2560x1440@59.95Hz 1920x1200@60.00Hz 1920x1080@60.00Hz 1920x1080@60.00Hz 1920x1080@59.94Hz 1920x1080@50.00Hz 1920x1080@30.00Hz 1920x1080@29.97Hz 1920x1080@25.00Hz 1920x1080@24.00Hz 1920x1080@23.98Hz 1600x1200@60.00Hz 1680x1050@59.95Hz 1600x900@60.00Hz 1280x1024@75.03Hz 1280x1024@60.02Hz 1440x900@60.00Hz 1280x800@59.81Hz 1152x864@75.00Hz 1280x720@60.00Hz 1280x720@60.00Hz 1280x720@59.94Hz 1280x720@50.00Hz 1024x768@75.03Hz 1024x768@60.00Hz 832x624@74.55Hz 800x600@75.00Hz 800x600@60.32Hz 720x576@50.00Hz 720x480@60.00Hz 720x480@59.94Hz 640x480@75.00Hz 640x480@60.00Hz 640x480@59.94Hz 640x480@59.94Hz 720x400@70.08Hz

And from the macOS side (which is left of the Hyprland workstation):

❯ system_profiler SPDisplaysDataType
Graphics/Displays:

    Apple M1:

      Chipset Model: Apple M1
      Type: GPU
      Bus: Built-In
      Total Number of Cores: 8
      Vendor: Apple (0x106b)
      Metal Support: Metal 3
      Displays:
        Color LCD:
          Display Type: Built-In Retina LCD
          Resolution: 2560 x 1600 Retina
          Main Display: Yes
          Mirror: Off
          Online: Yes
          Automatically Adjust Brightness: Yes
          Connection Type: Internal

@simonm commented on GitHub (Aug 15, 2024): Hi - I get no logs when I move the mouse to the edge of the screen on the Hyprland side. Here are logs on startup: ``` ❯ lan-mouse [2024-08-15T12:04:59Z INFO lan_mouse::config] using config: "/home/simonm/.config/lan-mouse/config.toml" [2024-08-15T12:04:59Z INFO lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] (lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:46:1-6: Unknown name of pseudo-class (lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:96:1-6: Unknown name of pseudo-class (lan-mouse:1121373): Gtk-WARNING **: 14:04:59.235: Theme parser error: gtk.css:124:1-6: Unknown name of pseudo-class [2024-08-15T12:04:59Z INFO lan_mouse::config] using config: "/home/simonm/.config/lan-mouse/config.toml" [2024-08-15T12:04:59Z INFO lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] [2024-08-15T12:04:59Z INFO lan_mouse] Press [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] to release the mouse [2024-08-15T12:04:59Z INFO lan_mouse::server] running service [2024-08-15T12:04:59Z INFO lan_mouse::server::emulation_task] creating input emulation... [2024-08-15T12:04:59Z INFO input_emulation] using emulation backend: wlroots [2024-08-15T12:04:59Z WARN input_capture] input-capture-portal input capture backend unavailable: error creating input-capture-portal backend: `xdg-desktop-portal: `A portal frontend implementing `org.freedesktop.portal.InputCapture` was not found`` [2024-08-15T12:04:59Z INFO input_capture] using capture backend: layer-shell [2024-08-15T12:04:59Z INFO lan_mouse::server::capture_task] [(0, (ClientConfig { hostname: None, fix_ips: [192.168.10.172], port: 4242, pos: Left, cmd: None }, ClientState { active: false, active_addr: None, alive: false, dns_ips: [], ips: {192.168.10.172}, pressed_keys: {}, resolving: false }))] [2024-08-15T12:05:37Z INFO lan_mouse::dns] resolving (0) `192.168.10.172` ... [2024-08-15T12:05:37Z INFO lan_mouse::dns] 192.168.10.172: adding ip 192.168.10.172 ``` Here's some details of the displays on each side. From Hyprland (on the right of the macOS laptop): ``` Monitor DP-2 (ID 1): 3840x2160@59.99700 at 3840x0 description: BNQ BenQ EW3280U S2M03886019 make: BNQ model: BenQ EW3280U serial: S2M03886019 active workspace: 6 (6) special workspace: 0 () reserved: 0 36 0 0 scale: 1.00 transform: 0 focused: no dpmsStatus: 1 vrr: 0 activelyTearing: false disabled: false currentFormat: XRGB8888 availableModes: 3840x2160@60.00Hz 3840x2160@60.00Hz 3840x2160@59.94Hz 3840x2160@50.00Hz 3840x2160@30.00Hz 3840x2160@30.00Hz 3840x2160@29.97Hz 3840x2160@25.00Hz 3840x2160@24.00Hz 3840x2160@23.98Hz 2560x1440@59.95Hz 1920x1200@60.00Hz 1920x1080@60.00Hz 1920x1080@60.00Hz 1920x1080@59.94Hz 1920x1080@50.00Hz 1920x1080@30.00Hz 1920x1080@29.97Hz 1920x1080@25.00Hz 1920x1080@24.00Hz 1920x1080@23.98Hz 1600x1200@60.00Hz 1680x1050@59.95Hz 1600x900@60.00Hz 1280x1024@75.03Hz 1280x1024@60.02Hz 1440x900@60.00Hz 1280x800@59.81Hz 1152x864@75.00Hz 1280x720@60.00Hz 1280x720@60.00Hz 1280x720@59.94Hz 1280x720@50.00Hz 1024x768@75.03Hz 1024x768@60.00Hz 832x624@74.55Hz 800x600@75.00Hz 800x600@60.32Hz 720x576@50.00Hz 720x480@60.00Hz 720x480@59.94Hz 640x480@75.00Hz 640x480@60.00Hz 640x480@59.94Hz 640x480@59.94Hz 720x400@70.08Hz Monitor DP-1 (ID 0): 3840x2160@59.99700 at 0x0 description: BNQ BenQ EW3280U XBM00578019 make: BNQ model: BenQ EW3280U serial: XBM00578019 active workspace: 1 (1) special workspace: 0 () reserved: 0 36 0 0 scale: 1.00 transform: 0 focused: yes dpmsStatus: 1 vrr: 0 activelyTearing: false disabled: false currentFormat: XRGB8888 availableModes: 3840x2160@60.00Hz 3840x2160@60.00Hz 3840x2160@59.94Hz 3840x2160@50.00Hz 3840x2160@30.00Hz 3840x2160@30.00Hz 3840x2160@29.97Hz 3840x2160@25.00Hz 3840x2160@24.00Hz 3840x2160@23.98Hz 2560x1440@59.95Hz 1920x1200@60.00Hz 1920x1080@60.00Hz 1920x1080@60.00Hz 1920x1080@59.94Hz 1920x1080@50.00Hz 1920x1080@30.00Hz 1920x1080@29.97Hz 1920x1080@25.00Hz 1920x1080@24.00Hz 1920x1080@23.98Hz 1600x1200@60.00Hz 1680x1050@59.95Hz 1600x900@60.00Hz 1280x1024@75.03Hz 1280x1024@60.02Hz 1440x900@60.00Hz 1280x800@59.81Hz 1152x864@75.00Hz 1280x720@60.00Hz 1280x720@60.00Hz 1280x720@59.94Hz 1280x720@50.00Hz 1024x768@75.03Hz 1024x768@60.00Hz 832x624@74.55Hz 800x600@75.00Hz 800x600@60.32Hz 720x576@50.00Hz 720x480@60.00Hz 720x480@59.94Hz 640x480@75.00Hz 640x480@60.00Hz 640x480@59.94Hz 640x480@59.94Hz 720x400@70.08Hz ``` And from the macOS side (which is left of the Hyprland workstation): ``` ❯ system_profiler SPDisplaysDataType Graphics/Displays: Apple M1: Chipset Model: Apple M1 Type: GPU Bus: Built-In Total Number of Cores: 8 Vendor: Apple (0x106b) Metal Support: Metal 3 Displays: Color LCD: Display Type: Built-In Retina LCD Resolution: 2560 x 1600 Retina Main Display: Yes Mirror: Off Online: Yes Automatically Adjust Brightness: Yes Connection Type: Internal ```

gitea-mirror commented

2026-05-05 22:08:07 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

OK! Some progress!

I got it working Hyprland to Hyprland! Woohoo!

Linux laptop on right, Linux workstation on left.

I see UDP traffic.
Mouse moves as smooth as butter from the left edge of the latptop to the right edge of the workstation.

The problem is with macOS.

I will do some more testing and follow exactly the same approach as with the linux laptop. i.e. no external monitors, NICs etc.

I will report back.

@simonm commented on GitHub (Aug 15, 2024): OK! Some progress! I got it working Hyprland to Hyprland! Woohoo! Linux laptop on right, Linux workstation on left. I see UDP traffic. Mouse moves as smooth as butter from the left edge of the latptop to the right edge of the workstation. The problem is with macOS. I will do some more testing and follow exactly the same approach as with the linux laptop. i.e. no external monitors, NICs etc. I will report back.

gitea-mirror commented

2026-05-05 22:08:07 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

Additional testing (still Hyprland to Hyprland):

Workstation Left <-> Laptop Right

Works fine in both directions. When I move the mouse on either device to the edge next to the partner machine, then mouse and keyboard control is working on the partner machine.

Laptop Left <-> Workstation Right

I can use the laptop trackpad and keyboard to move the mouse to the right, to then control the workstation.

However!

When I try to move the mouse with the laptop trackpad back to the laptop screen, it just stops at the edge of hte workstation monitor and doesn't carry over.
Moving the workstation mouse to the left edge of the left screen does not then move mouse on the laptop.

So, it works in one direction only. There's a problem with the left edge of the workstation.

Aaah! Just had an idea: I'm using fractional scaling! Maybe this is the cause? The edges are not being detected as a consequence?

On workstation:

❯ grep ^monitor ~/.config/hypr/conf.d/monitors.conf
monitor=DP-1,3840x2160,0x0,1
monitor=DP-2,3840x2160,3840x0,1

On the Hyprland laptop:

❯ ssh simonm@zen grep ^monitor ~/.config/hypr/conf.d/monitors.conf 2>/dev/null
monitor=eDP-1,preferred,auto,1.33

Testing again with scaling on laptop set to 1.0 and I do not see any change in behavior so not sure any more!

Also, I have not tried the macbook on the right of the workstation yet.

Anything I can do do troubleshoot display resolution detection?

@simonm commented on GitHub (Aug 15, 2024): Additional testing (still Hyprland to Hyprland): ### Workstation Left <-> Laptop Right - Works fine in both directions. When I move the mouse on either device to the edge next to the partner machine, then mouse and keyboard control is working on the partner machine. ### Laptop Left <-> Workstation Right - I can use the laptop trackpad and keyboard to move the mouse to the right, to then control the workstation. However! - When I try to move the mouse with the laptop trackpad back to the laptop screen, it just stops at the edge of hte workstation monitor and doesn't carry over. - Moving the workstation mouse to the left edge of the left screen does not then move mouse on the laptop. So, it works in one direction only. There's a problem with the left edge of the workstation. Aaah! Just had an idea: I'm using fractional scaling! Maybe this is the cause? The edges are not being detected as a consequence? On workstation: ``` ❯ grep ^monitor ~/.config/hypr/conf.d/monitors.conf monitor=DP-1,3840x2160,0x0,1 monitor=DP-2,3840x2160,3840x0,1 ``` On the Hyprland laptop: ``` ❯ ssh simonm@zen grep ^monitor ~/.config/hypr/conf.d/monitors.conf 2>/dev/null monitor=eDP-1,preferred,auto,1.33 ``` Testing again with scaling on laptop set to 1.0 and I do not see any change in behavior so not sure any more! Also, I have not tried the macbook on the right of the workstation yet. Anything I can do do troubleshoot display resolution detection?

gitea-mirror commented

2026-05-05 22:08:08 -06:00

Author

Owner

@simonm commented on GitHub (Aug 15, 2024):

Could this be related? #46

@simonm commented on GitHub (Aug 15, 2024): Could this be related? #46

gitea-mirror commented

2026-05-05 22:08:09 -06:00

Author

Owner

@feschber commented on GitHub (Aug 15, 2024):

There have been several issues with Hyprland before and I would not be surprised if the wlroots removal caused new issues.

The --test-capture flag is essentially there to debug such issues.

Additionally you could set

LAN_MOUSE_LOG_LEVEL=trace

to enable more verbose logging

LM_DEBUG_LAYER_SHELL=1

to show the capture surfaces in green (on Hyprland that is).

And test using --test-capture to find out if there are any Hyprland related issues.

Other than that it might be useful to check if sway works as a reference.

On the MacOS side, if --test-emulation works it is either an issue on the host side or network / firewall related

@feschber commented on GitHub (Aug 15, 2024): There have been several issues with Hyprland before and I would not be surprised if the wlroots removal caused new issues. The `--test-capture` flag is essentially there to debug such issues. Additionally you could set ```sh LAN_MOUSE_LOG_LEVEL=trace ``` to enable more verbose logging ```sh LM_DEBUG_LAYER_SHELL=1 ``` to show the capture surfaces in green (on Hyprland that is). And test using `--test-capture` to find out if there are any Hyprland related issues. Other than that it might be useful to check if sway works as a reference. On the MacOS side, if `--test-emulation` works it is either an issue on the host side or network / firewall related

gitea-mirror commented

2026-05-05 22:08:09 -06:00

Author

Owner

@simonm commented on GitHub (Sep 11, 2024):

Hello - I will close this ticket. I got things working Hyprland <-> Hyprland so no need for the macOS laptop now. It was probably a config error on my part.

@simonm commented on GitHub (Sep 11, 2024): Hello - I will close this ticket. I got things working Hyprland <-> Hyprland so no need for the macOS laptop now. It was probably a config error on my part.

gitea-mirror referenced this issue

2026-05-05 22:15:31 -06:00

[PR #71] [MERGED] ignore double press / release events #267