[GH-ISSUE #134] After upgrade lan mouse version to 0.8.0, Windows side can't access Linux side input

gitea-mirror commented

2026-05-05 22:06:51 -06:00

Owner

Originally created by @Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm on GitHub (May 18, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/134

Before upgrade to 0.8.0 everything is work perfectly, but after upgrade to 0.8.0 only Linux side can access windows side mouse input, even plug in mouse to linux pc, when access windows side mouse input can't back to linux side.

I've tried to downgrade to 0.7.3 or 0.7.2, but still not working, so i'm thinking maybe is linux upgrade something break lan mouse.

My linux system is fedora 40 KDE Plasma 6.0.4 Wayland, windows version is 26120.670.

Windows side logs:

May 18 18:23:23 fedoraremix systemd[1]: Started lan-mouse.service - Lan Mouse.
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse::config] using config: "C:\Users\username\AppData\Local\lan-mouse\config.toml"
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt]
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse] Press Ctrl+Alt+Shift+Super to release the mouse
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse::server] running service
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse::dns] resolving 192.168.8.37 ...
May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO  lan_mouse::dns] 192.168.8.37: adding ip 192.168.8.37

Linux side logs:

May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::server] running service
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::emulate] wayland backend not available: the requested global was not found in the registry
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::dns] resolving 192.168.8.159 ...
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::dns] 192.168.8.159: adding ip 192.168.8.159
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::capture] libei input capture not available: ZBus Error: org.freedesktop.DBus.Error.UnknownMethod: No such interface "org.freedesktop.portal.InputCapture" on object at path /org/freedesktop/portal/desktop
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::capture] using layer-shell input capture
May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO  lan_mouse::emulate::libei] requesting permission for input emulation
May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO  lan_mouse::emulate] libei not available: Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'ConnectToEIS' in interface 'org.freedesktop.impl.portal.RemoteDesktop' at object path '/org/freedesktop/portal/desktop' (signature 'osa{sv}')
May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO  lan_mouse::emulate::xdg_desktop_portal] requesting permission for input emulation
May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO  lan_mouse::emulate] using xdg-remote-desktop-portal input emulation

Originally created by @Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm on GitHub (May 18, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/134 Before upgrade to 0.8.0 everything is work perfectly, but after upgrade to 0.8.0 only Linux side can access windows side mouse input, even plug in mouse to linux pc, when access windows side mouse input can't back to linux side. I've tried to downgrade to 0.7.3 or 0.7.2, but still not working, so i'm thinking maybe is linux upgrade something break lan mouse. My linux system is fedora 40 KDE Plasma 6.0.4 Wayland, windows version is 26120.670. Windows side logs: ``` May 18 18:23:23 fedoraremix systemd[1]: Started lan-mouse.service - Lan Mouse. May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse::config] using config: "C:\Users\username\AppData\Local\lan-mouse\config.toml" May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse] release bind: [KeyLeftCtrl, KeyLeftShift, KeyLeftMeta, KeyLeftAlt] May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse] Press Ctrl+Alt+Shift+Super to release the mouse May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse::server] running service May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse::dns] resolving 192.168.8.37 ... May 18 18:23:24 fedoraremix lan-mouse.exe[9877]: [2024-05-18T10:23:24Z INFO lan_mouse::dns] 192.168.8.37: adding ip 192.168.8.37 ``` Linux side logs: ``` May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::server] running service May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::emulate] wayland backend not available: the requested global was not found in the registry May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::dns] resolving 192.168.8.159 ... May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::dns] 192.168.8.159: adding ip 192.168.8.159 May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::capture] libei input capture not available: ZBus Error: org.freedesktop.DBus.Error.UnknownMethod: No such interface "org.freedesktop.portal.InputCapture" on object at path /org/freedesktop/portal/desktop May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::capture] using layer-shell input capture May 18 18:25:28 fedora lan-mouse[8244]: [2024-05-18T10:25:28Z INFO lan_mouse::emulate::libei] requesting permission for input emulation May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO lan_mouse::emulate] libei not available: Portal request failed: org.freedesktop.zbus.Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'ConnectToEIS' in interface 'org.freedesktop.impl.portal.RemoteDesktop' at object path '/org/freedesktop/portal/desktop' (signature 'osa{sv}') May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO lan_mouse::emulate::xdg_desktop_portal] requesting permission for input emulation May 18 18:25:30 fedora lan-mouse[8244]: [2024-05-18T10:25:30Z INFO lan_mouse::emulate] using xdg-remote-desktop-portal input emulation ```

gitea-mirror closed this issue

2026-05-05 22:06:52 -06:00

gitea-mirror commented

2026-05-05 22:06:54 -06:00

Author

Owner

@feschber commented on GitHub (May 18, 2024):

Just to be sure: Did you upgrade both devices and restart the service?

@feschber commented on GitHub (May 18, 2024): Just to be sure: Did you upgrade both devices and restart the service?

gitea-mirror commented

2026-05-05 22:06:56 -06:00

Author

Owner

@Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm commented on GitHub (May 18, 2024):

Yes, I did it.

@Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm commented on GitHub (May 18, 2024): Yes, I did it.

gitea-mirror commented

2026-05-05 22:06:57 -06:00

Author

Owner

@Vesek commented on GitHub (May 18, 2024):

Same happening here, the Linux PC can control Windows but on Windows the mouse cannot leave the screen.

@Vesek commented on GitHub (May 18, 2024): Same happening here, the Linux PC can control Windows but on Windows the mouse cannot leave the screen.

gitea-mirror commented

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

Author

Owner

@neur1n commented on GitHub (May 22, 2024):

~~Same here.~~ The only version that worked for me (I just started using lan-mouse a couple of weeks ago) on two Windows 11 machines was the prerelease I downloaded on 2024-05-08, but I forgot the commit hash.

@neur1n commented on GitHub (May 22, 2024): ~Same here.~ The only version that worked for me (I just started using lan-mouse a couple of weeks ago) on two Windows 11 machines was the prerelease I downloaded on 2024-05-08, but I forgot the commit hash.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (May 22, 2024):

Same here. The only version that worked for me (I just started using lan-mouse a couple of weeks ago) on two Windows 11 machines was the prerelease I downloaded on 2024-05-08, but I forgot the commit hash.

Thank you, that is very helpful!

@feschber commented on GitHub (May 22, 2024): > Same here. The only version that worked for me (I just started using lan-mouse a couple of weeks ago) on two Windows 11 machines was the prerelease I downloaded on 2024-05-08, but I forgot the commit hash. Thank you, that is very helpful!

gitea-mirror commented

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

Author

Owner

@omgcem commented on GitHub (Jun 20, 2024):

I am also experiencing this issue with the release versions on Windows & Wayland (0.8.0).

The cursor is able to enter the windows client but not able to return to the Wayland client.

It is working with the debug version built from source on Windows (although other issues are then present on windows side) and no changes on the Wayland side.

The release version built from source experiences the same issue as the release download.

@omgcem commented on GitHub (Jun 20, 2024): I am also experiencing this issue with the release versions on Windows & Wayland (0.8.0). The cursor is able to enter the windows client but not able to return to the Wayland client. It is working with the debug version built from source on Windows (although other issues are then present on windows side) and no changes on the Wayland side. The release version built from source experiences the same issue as the release download.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Jun 20, 2024):

Okay this is interesting. I will hopefully get to take a look this weekend.

@feschber commented on GitHub (Jun 20, 2024): Okay this is interesting. I will hopefully get to take a look this weekend.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Jun 20, 2024):

Could you check if maybe the "barriers" are just on the wrong side? As in the position is set to right but it's actually on the left side?

@feschber commented on GitHub (Jun 20, 2024): Could you check if maybe the "barriers" are just on the wrong side? As in the position is set to right but it's actually on the left side?

gitea-mirror commented

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

Author

Owner

@omgcem commented on GitHub (Jun 21, 2024):

I retested with the source built release version on windows (also dropped down to just 1 monitor) and was not able to exit the screen from any screen edge despite the left being configured as the barrier to the Wayland client.

Reverting back to the source built debug version allowed me to exit from the left screen edge as expected.

@omgcem commented on GitHub (Jun 21, 2024): I retested with the source built release version on windows (also dropped down to just 1 monitor) and was not able to exit the screen from any screen edge despite the left being configured as the barrier to the Wayland client. Reverting back to the source built debug version allowed me to exit from the left screen edge as expected.

gitea-mirror commented

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

Author

Owner

@miroslav-suvada commented on GitHub (Jun 25, 2024):

I am experiencing a similar problem. I am running version 0.8.0 on both Windows 11 and Ubuntu 22.04.

@miroslav-suvada commented on GitHub (Jun 25, 2024): I am experiencing a similar problem. I am running version 0.8.0 on both Windows 11 and Ubuntu 22.04.

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Jun 25, 2024):

now this is a very interesting bug. It looks to me like a compiler bug:

log::debug!("{}", wparam.0 != WM_MOUSEMOVE as usize);
log::debug!("{}, {}, {}", wparam.0, WM_MOUSEMOVE as usize, wparam.0 == WM_MOUSEMOVE as usize);

This prints

[2024-06-25T09:57:36Z DEBUG lan_mouse::capture::windows] true
[2024-06-25T09:57:36Z DEBUG lan_mouse::capture::windows] 512, 512, true

@feschber commented on GitHub (Jun 25, 2024): now this is a very interesting bug. It looks to me like a compiler bug: ```rust log::debug!("{}", wparam.0 != WM_MOUSEMOVE as usize); log::debug!("{}, {}, {}", wparam.0, WM_MOUSEMOVE as usize, wparam.0 == WM_MOUSEMOVE as usize); ``` This prints ``` [2024-06-25T09:57:36Z DEBUG lan_mouse::capture::windows] true [2024-06-25T09:57:36Z DEBUG lan_mouse::capture::windows] 512, 512, true ```

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Jun 25, 2024):

use std::hint::black_box;
use std::ptr::addr_of;
use windows::Win32::Foundation::{LPARAM, WPARAM};
use windows::Win32::UI::WindowsAndMessaging::{MSLLHOOKSTRUCT, WM_MOUSEMOVE};

fn main() {
    let msll = MSLLHOOKSTRUCT::default();
    let wparam = WPARAM(512);
    let lparam = LPARAM(addr_of!(msll) as *const _ as isize);
    unsafe { check_client_activation(wparam, lparam) };
}

pub unsafe fn check_client_activation(wparam: WPARAM, lparam: LPARAM) -> bool {
    eprintln!("{wparam:?}, {lparam:?}");
    if wparam.0 != WM_MOUSEMOVE as usize {
        black_box(wparam.0);
        assert_ne!(wparam.0, WM_MOUSEMOVE as usize);
        return true;
    }
    let mouse_low_level: MSLLHOOKSTRUCT =
        unsafe { *std::mem::transmute::<LPARAM, *const MSLLHOOKSTRUCT>(lparam) };
    black_box(mouse_low_level.pt);

    true
}

reduced example... very very strange

@feschber commented on GitHub (Jun 25, 2024): ```rust use std::hint::black_box; use std::ptr::addr_of; use windows::Win32::Foundation::{LPARAM, WPARAM}; use windows::Win32::UI::WindowsAndMessaging::{MSLLHOOKSTRUCT, WM_MOUSEMOVE}; fn main() { let msll = MSLLHOOKSTRUCT::default(); let wparam = WPARAM(512); let lparam = LPARAM(addr_of!(msll) as *const _ as isize); unsafe { check_client_activation(wparam, lparam) }; } pub unsafe fn check_client_activation(wparam: WPARAM, lparam: LPARAM) -> bool { eprintln!("{wparam:?}, {lparam:?}"); if wparam.0 != WM_MOUSEMOVE as usize { black_box(wparam.0); assert_ne!(wparam.0, WM_MOUSEMOVE as usize); return true; } let mouse_low_level: MSLLHOOKSTRUCT = unsafe { *std::mem::transmute::<LPARAM, *const MSLLHOOKSTRUCT>(lparam) }; black_box(mouse_low_level.pt); true } ``` reduced example... very very strange

gitea-mirror commented

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

Author

Owner

@feschber commented on GitHub (Jun 25, 2024):

Okay turns out, its actually UB... I should not be using transmute here

@feschber commented on GitHub (Jun 25, 2024): Okay turns out, its actually UB... I should not be using transmute here

gitea-mirror commented

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

Author

Owner

@Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm commented on GitHub (Jun 25, 2024):

I have tested the dev build of lan mouse, from windows to linux is fine, but when back to windows the mouse seem to be frozen, and I can't do anything about this.

@Mzyhe3n6jmFqkYQyFKzFW3kGRGMok8xTYySN4Tm commented on GitHub (Jun 25, 2024): I have tested the dev build of lan mouse, from windows to linux is fine, but when back to windows the mouse seem to be frozen, and I can't do anything about this.

gitea-mirror commented

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

Author

Owner

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

I just squashed another bug with windows.

Please report back if anyone is still having issues now!

@feschber commented on GitHub (Jul 2, 2024): I just squashed another bug with windows. Please report back if anyone is still having issues now!

gitea-mirror referenced this issue

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

[PR #52] [MERGED] Add a dummy backend #253

Rows
Columns

[GH-ISSUE #134] After upgrade lan mouse version to 0.8.0, Windows side can't access Linux side input #52