search

feschber / lan-mouse

mouse & keyboard sharing via LAN
GNU General Public License v3.0
2.34k stars 64 forks source link

Hyprland -> macOS problem #166

Closed simonm closed 1 day ago

simonm commented 1 month ago

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:

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.

feschber commented 1 month ago

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.

simonm commented 1 month ago

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:

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 4 weeks ago

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... :-)

feschber commented 4 weeks ago

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.

simonm commented 4 weeks ago

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?

feschber commented 4 weeks ago

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?

simonm commented 4 weeks ago

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 4 weeks ago

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 4 weeks ago

Additional testing (still Hyprland to Hyprland):

Workstation Left <-> Laptop Right

Laptop Left <-> Workstation Right

However!

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 4 weeks ago

Could this be related? #46

feschber commented 4 weeks ago

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

simonm commented 1 day ago

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.