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 #46] Host peripherals that move to Windows from Linux cannot move back #13

New issue
Closed
opened 2026-05-05 22:03:35 -06:00 by gitea-mirror · 42 comments
gitea-mirror commented 2026-05-05 22:03:35 -06:00
Owner
Copy link

Originally created by @MulverineX on GitHub (Dec 14, 2023).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/46

The magic edge appears to be broken on Windows, to work around it the connection must be deactivated.

Environments:
Sending

Latest KDE Plasma on Arch Linux
lan-mouse@010db79

frontend = "cli"

[left]
host_name = "zhulong"
ips = ["192.168.77.74"]
port = 4242

cargo run --release --no-default-features --features wayland,xdg_desktop_portal,x11

Receiving

Latest Windows 11
lan-mouse@v0.4.0

frontend = "cli"

[right]
host_name = "haixiong"
ips = ["192.168.77.117"]
port = 4242
Originally created by @MulverineX on GitHub (Dec 14, 2023). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/46 The magic edge appears to be broken on Windows, to work around it the connection must be deactivated. Environments: Sending > Latest KDE Plasma on Arch Linux > lan-mouse@010db79 > ```toml > frontend = "cli" > > [left] > host_name = "zhulong" > ips = ["192.168.77.74"] > port = 4242 > ``` > `cargo run --release --no-default-features --features wayland,xdg_desktop_portal,x11` Receiving > Latest Windows 11 > lan-mouse@v0.4.0 > ```toml > frontend = "cli" > > [right] > host_name = "haixiong" > ips = ["192.168.77.117"] > port = 4242 > ```
gitea-mirror 2026-05-05 22:03:35 -06:00
  • closed this issue
  • added the
    windows
         label
gitea-mirror commented 2026-05-05 22:03:39 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Dec 14, 2023):

Yes, input capture is not yet implemented in Windows so this is expected. For now, you can release the mouse by pressing Ctrl+alt+shift+super (on the Linux machine)

<!-- gh-comment-id:1855488076 --> @feschber commented on GitHub (Dec 14, 2023): Yes, input capture is not yet implemented in Windows so this is expected. For now, you can release the mouse by pressing Ctrl+alt+shift+super (on the Linux machine)
gitea-mirror commented 2026-05-05 22:03:41 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Dec 14, 2023):

I'm not sure I understand, the input is happening on Linux

<!-- gh-comment-id:1855511659 --> @MulverineX commented on GitHub (Dec 14, 2023): I'm not sure I understand, the input is happening on Linux
gitea-mirror commented 2026-05-05 22:03:42 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Dec 14, 2023):

There is no magic edge (=input capture) on windows yet. That's why it's not working. But you can press the key combination on the sending machine (Linux) to release the mouse there.

<!-- gh-comment-id:1855639190 --> @feschber commented on GitHub (Dec 14, 2023): There is no magic edge (=input capture) on windows yet. That's why it's not working. But you can press the key combination on the sending machine (Linux) to release the mouse there.
gitea-mirror commented 2026-05-05 22:03:44 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Dec 31, 2023):

This appears to persist in 0.5.0

<!-- gh-comment-id:1872652653 --> @MulverineX commented on GitHub (Dec 31, 2023): This appears to persist in 0.5.0
gitea-mirror commented 2026-05-05 22:03:45 -06:00
Author
Owner
Copy link

@beyertom commented on GitHub (Jan 23, 2024):

I didnt read anything in the readme or the commit logs, but for me the magic-edge on windows works now with v0.5.1 (Server wlroots / Client Windows).

Thank you very much, awesome project!

<!-- gh-comment-id:1905715876 --> @beyertom commented on GitHub (Jan 23, 2024): I didnt read anything in the readme or the commit logs, but for me the magic-edge on windows works now with v0.5.1 (Server wlroots / Client Windows). Thank you very much, awesome project!
gitea-mirror commented 2026-05-05 22:03:46 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Jan 23, 2024):

I didnt read anything in the readme or the commit logs, but for me the magic-edge on windows works now with v0.5.1 (Server wlroots / Client Windows).

Thank you very much, awesome project!

Are you by any chance using Hyprland on the server side?

<!-- gh-comment-id:1905750556 --> @feschber commented on GitHub (Jan 23, 2024): > I didnt read anything in the readme or the commit logs, but for me the magic-edge on windows works now with v0.5.1 (Server wlroots / Client Windows). > > Thank you very much, awesome project! Are you by any chance using Hyprland on the server side?
gitea-mirror commented 2026-05-05 22:03:46 -06:00
Author
Owner
Copy link

@beyertom commented on GitHub (Jan 23, 2024):

yes i do

this gets logged on the server when i move the mouse from client to server:
2024-01-23T10:31:49Z WARN lan_mouse::backend::producer::wayland] compositor released mouse

<!-- gh-comment-id:1905751788 --> @beyertom commented on GitHub (Jan 23, 2024): yes i do this gets logged on the server when i move the mouse from client to server: `2024-01-23T10:31:49Z WARN lan_mouse::backend::producer::wayland] compositor released mouse`
gitea-mirror commented 2026-05-05 22:03:47 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Jan 23, 2024):

Okay because this is really a bug with Hyprland rather than a feature in LanMouse.

In my testing, the pointer is released when it is moved on a second screen on Hyprland. (In the invisible locked state).

Do you have multiple monitors on the server side? And is your windows monitor the same resolution as those two?

<!-- gh-comment-id:1905758746 --> @feschber commented on GitHub (Jan 23, 2024): Okay because this is really a bug with Hyprland rather than a feature in LanMouse. In my testing, the pointer is released when it is moved on a second screen on Hyprland. (In the invisible locked state). Do you have multiple monitors on the server side? And is your windows monitor the same resolution as those two?
gitea-mirror commented 2026-05-05 22:03:50 -06:00
Author
Owner
Copy link

@beyertom commented on GitHub (Jan 23, 2024):

what a conicidence, i actually added a second screen to my server since i tested lan-mouse the last time.

The resolution of windows is not the same as the main monitor of the Server (the one "right" of Windows).

I am not complaining, though. It works exactly how I wanted it to be. :-)

<!-- gh-comment-id:1905847412 --> @beyertom commented on GitHub (Jan 23, 2024): what a conicidence, i actually added a second screen to my server since i tested lan-mouse the last time. The resolution of windows is not the same as the main monitor of the Server (the one "right" of Windows). I am not complaining, though. It works exactly how I wanted it to be. :-)
gitea-mirror commented 2026-05-05 22:03:51 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Jan 23, 2024):

Whatever works for you I guess!
I will see that I can add proper support for at least detecting when the screen is exited on the windows side soon.

<!-- gh-comment-id:1905854349 --> @feschber commented on GitHub (Jan 23, 2024): Whatever works for you I guess! I will see that I can add proper support for at least detecting when the screen is exited on the windows side soon.
gitea-mirror commented 2026-05-05 22:03:51 -06:00
Author
Owner
Copy link

@beyertom commented on GitHub (Feb 12, 2024):

yesterday i upgraded to Hyprland 0.35.0 and now unfortuneately its not working anymore.

The client screen is on the left, and i can move the mouse there only more to the left. unti iam at the very left edge of the screen

<!-- gh-comment-id:1938172852 --> @beyertom commented on GitHub (Feb 12, 2024): yesterday i upgraded to Hyprland 0.35.0 and now unfortuneately its not working anymore. The client screen is on the left, and i can move the mouse there only more to the left. unti iam at the very left edge of the screen
gitea-mirror commented 2026-05-05 22:03:52 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Feb 12, 2024):

yesterday i upgraded to Hyprland 0.35.0 and now unfortuneately its not working anymore.

The client screen is on the left, and i can move the mouse there only more to the left. unti iam at the very left edge of the screen

Jup - See readme. There was a regression.

<!-- gh-comment-id:1938188969 --> @feschber commented on GitHub (Feb 12, 2024): > yesterday i upgraded to Hyprland 0.35.0 and now unfortuneately its not working anymore. > > The client screen is on the left, and i can move the mouse there only more to the left. unti iam at the very left edge of the screen Jup - See readme. There was a regression.
gitea-mirror commented 2026-05-05 22:03:52 -06:00
Author
Owner
Copy link

@fecet commented on GitHub (Mar 15, 2024):

Problem persist by using hyprland a01949dd28

<!-- gh-comment-id:1999005994 --> @fecet commented on GitHub (Mar 15, 2024): Problem persist by using hyprland https://github.com/hyprwm/Hyprland/commit/a01949dd286ba67f8026aeec38b44b61e20be412
gitea-mirror commented 2026-05-05 22:03:53 -06:00
Author
Owner
Copy link

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

Problem persist by using hyprland a01949dd28

Windows input capture support is next on the list ;)

<!-- gh-comment-id:2010775990 --> @feschber commented on GitHub (Mar 20, 2024): > Problem persist by using hyprland https://github.com/hyprwm/Hyprland/commit/a01949dd286ba67f8026aeec38b44b61e20be412 Windows input capture support is next on the list ;)
gitea-mirror commented 2026-05-05 22:03:53 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

uhhh, @feschber this still isn't working afaict. I'm using the 0.7.3 release. I'm guessing that https://github.com/feschber/lan-mouse/pull/99 broke it

<!-- gh-comment-id:2076075276 --> @MulverineX commented on GitHub (Apr 25, 2024): uhhh, @feschber this still isn't working afaict. I'm using the 0.7.3 release. I'm guessing that https://github.com/feschber/lan-mouse/pull/99 broke it
gitea-mirror commented 2026-05-05 22:03:54 -06:00
Author
Owner
Copy link

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

uhhh, @feschber this still isn't working afaict. I'm using the 0.7.3 release. I'm guessing that https://github.com/feschber/lan-mouse/pull/99 broke it

What exactly is not working? Did you get the latest pre-release binary and restart lan-mouse?

<!-- gh-comment-id:2076079848 --> @feschber commented on GitHub (Apr 25, 2024): > uhhh, @feschber this still isn't working afaict. I'm using the 0.7.3 release. I'm guessing that https://github.com/feschber/lan-mouse/pull/99 broke it What exactly is not working? Did you get the latest pre-release binary and restart lan-mouse?
gitea-mirror commented 2026-05-05 22:03:55 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

@feschber Previously I was on 0.5.0. I've tried 0.7.3 & 0.5.1, neither let me move the cursor back. Also, it appears there was a regression on remote input in Windows on both versions, where every mouse click is duplicated very quickly, causing bugs in several applications and highlighting a whole word in text editors, curiously Windows Explorer is not effected. The latest pre-release doesn't change code that should effect linux or windows. And yes, I'm actually running these versions of the software. I've double checked process managers on both machines and there isn't duplicates running either.

<!-- gh-comment-id:2076086483 --> @MulverineX commented on GitHub (Apr 25, 2024): @feschber Previously I was on 0.5.0. I've tried 0.7.3 & 0.5.1, neither let me move the cursor back. Also, it appears there was a regression on remote input in Windows on both versions, where every mouse click is duplicated **very** quickly, causing bugs in several applications and highlighting a whole word in text editors, curiously Windows Explorer is not effected. The latest pre-release doesn't change code that should effect linux or windows. And yes, I'm actually running these versions of the software. I've double checked process managers on both machines and there isn't duplicates running either.
gitea-mirror commented 2026-05-05 22:03:57 -06:00
Author
Owner
Copy link

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

@MulverineX Please try the pre release. It does not show all changes since 0.7.3 in the release notes until I update to 0.8

<!-- gh-comment-id:2076099507 --> @feschber commented on GitHub (Apr 25, 2024): @MulverineX Please try the pre release. It does not show all changes since 0.7.3 in the release notes until I update to 0.8
gitea-mirror commented 2026-05-05 22:04:00 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

Aha! Yep, I realized this after I sent that message, there hasn't been a build for a while. I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed, but the "edge" of my screen is being calculated incorrectly. I have a 2560x1440p display, but it appears to think that my screen on Windows ends at 1920 and jumps over to linux early. I can provide a video if you need.

<!-- gh-comment-id:2076104115 --> @MulverineX commented on GitHub (Apr 25, 2024): Aha! Yep, I realized this after I sent that message, there hasn't been a build for a while. I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed, but the "edge" of my screen is being calculated incorrectly. I have a 2560x1440p display, but it appears to think that my screen on Windows ends at 1920 and jumps over to linux early. I can provide a video if you need.
gitea-mirror commented 2026-05-05 22:04:00 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

@feschber also, scrolling is way slower on the client device, and using the Ctrl+Shift+Alt+Super fallback for releasing the cursor causes those keys to be locked again in the client device.

<!-- gh-comment-id:2076107405 --> @MulverineX commented on GitHub (Apr 25, 2024): @feschber also, scrolling is way slower on the client device, and using the Ctrl+Shift+Alt+Super fallback for releasing the cursor causes those keys to be locked again in the client device.
gitea-mirror commented 2026-05-05 22:04:02 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

Would display Scale effect it?
image

Also, I have a bit of a weird setup, My windows machine is a laptop that traditionally has a 1080p screen attached, but has since been removed. Perhaps the API you're using is giving you details for that non-existent display, rather than the external monitor my mouse is actually on?

<!-- gh-comment-id:2076109659 --> @MulverineX commented on GitHub (Apr 25, 2024): Would display Scale effect it? ![image](https://github.com/feschber/lan-mouse/assets/12068027/03c2f6f1-f869-4121-bf25-dc44671c7ab7) Also, I have a bit of a weird setup, My windows machine is a laptop that traditionally has a 1080p screen attached, but has since been removed. Perhaps the API you're using is giving you details for that non-existent display, rather than the external monitor my mouse is actually on?
gitea-mirror commented 2026-05-05 22:04:05 -06:00
Author
Owner
Copy link

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

@feschber also, scrolling is way slower on the client device, and using the Ctrl+Shift+Alt+Super fallback for releasing the cursor causes those keys to be locked again in the client device.

This is intentional (sort of, will need to fix this of course) and one reason I have not made a new release yet.

<!-- gh-comment-id:2076117343 --> @feschber commented on GitHub (Apr 25, 2024): > @feschber also, scrolling is way slower on the client device, and using the Ctrl+Shift+Alt+Super fallback for releasing the cursor causes those keys to be locked again in the client device. This is intentional (sort of, will need to fix this of course) and one reason I have not made a new release yet.
gitea-mirror commented 2026-05-05 22:04:07 -06:00
Author
Owner
Copy link

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

Would display Scale effect it?
image

Also, I have a bit of a weird setup, My windows machine is a laptop that traditionally has a 1080p screen attached, but has since been removed. Perhaps the API you're using is giving you details for that non-existent display, rather than the external monitor my mouse is actually on?

Could you run it with $env:LAN_MOUSE_LOG_LEVEL='debug' and paste the output? That should show what displays are detected. And scale is something I have not tested so yeah that could be an issue.

<!-- gh-comment-id:2076118354 --> @feschber commented on GitHub (Apr 25, 2024): > Would display Scale effect it? > ![image](https://github.com/feschber/lan-mouse/assets/12068027/03c2f6f1-f869-4121-bf25-dc44671c7ab7) > > Also, I have a bit of a weird setup, My windows machine is a laptop that traditionally has a 1080p screen attached, but has since been removed. Perhaps the API you're using is giving you details for that non-existent display, rather than the external monitor my mouse is actually on? Could you run it with $env:LAN_MOUSE_LOG_LEVEL='debug' and paste the output? That should show what displays are detected. And scale is something I have not tested so yeah that could be an issue.
gitea-mirror commented 2026-05-05 22:04:08 -06:00
Author
Owner
Copy link

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

full command should be

$env:LAN_MOUSE_LOG_LEVEL='debug'; lan-mouse

(powershell)

<!-- gh-comment-id:2076900971 --> @feschber commented on GitHub (Apr 25, 2024): full command should be ```powershell $env:LAN_MOUSE_LOG_LEVEL='debug'; lan-mouse ``` (powershell)
gitea-mirror commented 2026-05-05 22:04:09 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 25, 2024):

Forgot to test this last night, will test later today

<!-- gh-comment-id:2077585983 --> @MulverineX commented on GitHub (Apr 25, 2024): Forgot to test this last night, will test later today
gitea-mirror commented 2026-05-05 22:04:10 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 26, 2024):

@feschber alright here you go. (should've provided all of this information already, apologies)

Windows client debug log
Arch Linux server debug log

Lol this is wrong. Looks like scale definitely is affecting it, my KDE Plasma environment is also set to 125% scale.
image
(this is on the linux side, doesn't look like there's any useful debug in the windows log)

Here's my current Windows lan-mouse config:

[right]
# hostname
host_name = "haixiong"
# activate this client immediately when lan-mouse is started
activate_on_startup = true
# optional list of (known) ip addresses
ips = ["192.168.79.54"]
# , "100.64.0.1"

And my current Arch Linux config:

# example configuration

# optional port (defaults to 4242)
port = 4242
# # optional frontend -> defaults to gtk if available
# # possible values are "cli" and "gtk" 
frontend = "cli"

# define a client on the left side with IP address 192.168.178.189
[left]
# The hostname is optional: When no hostname is specified,
# at least one ip address needs to be specified.
host_name = "zhulong"
activate_on_startup = true
# ips for ethernet and wifi
ips = ["192.168.79.55", "192.168.77.69"]
# "100.64.0.2",
# optional port
port = 4242
<!-- gh-comment-id:2078415356 --> @MulverineX commented on GitHub (Apr 26, 2024): @feschber alright here you go. (should've provided all of this information already, apologies) [Windows client debug log](https://pastebin.com/tqDFNqMr) [Arch Linux server debug log](https://pastebin.com/ebyTXaaG) Lol this is wrong. Looks like scale definitely is affecting it, my KDE Plasma environment is also set to 125% scale. ![image](https://github.com/feschber/lan-mouse/assets/12068027/2d1fd8d0-59f9-4501-a7be-7dd301c0624a) (this is on the linux side, doesn't look like there's any useful debug in the windows log) Here's my current Windows lan-mouse config: ```toml [right] # hostname host_name = "haixiong" # activate this client immediately when lan-mouse is started activate_on_startup = true # optional list of (known) ip addresses ips = ["192.168.79.54"] # , "100.64.0.1" ``` And my current Arch Linux config: ```toml # example configuration # optional port (defaults to 4242) port = 4242 # # optional frontend -> defaults to gtk if available # # possible values are "cli" and "gtk" frontend = "cli" # define a client on the left side with IP address 192.168.178.189 [left] # The hostname is optional: When no hostname is specified, # at least one ip address needs to be specified. host_name = "zhulong" activate_on_startup = true # ips for ethernet and wifi ips = ["192.168.79.55", "192.168.77.69"] # "100.64.0.2", # optional port port = 4242 ```
gitea-mirror commented 2026-05-05 22:04:11 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 26, 2024):

Alright I tried changing display scales while lan-mouse was not running. Changing the linux side to 100% did nothing, however, changing windows to 100% solved the problem. If linux was the left monitor I'd probably have the reverse of this issue.

🤞 you can find APIs on both platforms for getting real display resolution.

<!-- gh-comment-id:2078462771 --> @MulverineX commented on GitHub (Apr 26, 2024): Alright I tried changing display scales while lan-mouse was not running. Changing the linux side to 100% did nothing, however, changing windows to 100% solved the problem. If linux was the left monitor I'd probably have the reverse of this issue. :crossed_fingers: you can find APIs on both platforms for getting real display resolution.
gitea-mirror commented 2026-05-05 22:04:11 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 26, 2024):

There is another issue on windows - DNS resolution is extremely slow: https://github.com/hickory-dns/hickory-dns/issues/1968

In your logfile on the windows side, it's still trying to resolve the host (this can take like 30 seconds).
I'm in the process of adding this information to the UI.

I will test how exactly scaling effects things, thank you for catching that.

<!-- gh-comment-id:2078983622 --> @feschber commented on GitHub (Apr 26, 2024): There is another issue on windows - DNS resolution is extremely slow: https://github.com/hickory-dns/hickory-dns/issues/1968 In your logfile on the windows side, it's still trying to resolve the host (this can take like 30 seconds). I'm in the process of adding this information to the UI. I will test how exactly scaling effects things, thank you for catching that.
gitea-mirror commented 2026-05-05 22:04:12 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 26, 2024):

Also, it appears there was a regression on remote input in Windows on both versions, where every mouse click is duplicated very quickly, causing bugs in several applications and highlighting a whole word in text editors, curiously Windows Explorer is not effected.

Could #91 have been the issue? Did you test a recent version?

<!-- gh-comment-id:2079009074 --> @feschber commented on GitHub (Apr 26, 2024): > Also, it appears there was a regression on remote input in Windows on both versions, where every mouse click is duplicated **very** quickly, causing bugs in several applications and highlighting a whole word in text editors, curiously Windows Explorer is not effected. Could #91 have been the issue? Did you test a recent version?
gitea-mirror commented 2026-05-05 22:04:12 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 26, 2024):

I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed

That's no longer happening

<!-- gh-comment-id:2079662150 --> @MulverineX commented on GitHub (Apr 26, 2024): > I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed That's no longer happening
gitea-mirror commented 2026-05-05 22:04:13 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 26, 2024):

I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed

That's no longer happening

Ah I missed that part. I assume it must have been that issue then.

<!-- gh-comment-id:2079666357 --> @feschber commented on GitHub (Apr 26, 2024): > > I'm on the 0.8 pre-release now, the duplicated mouse clicks are fixed > > That's no longer happening Ah I missed that part. I assume it must have been that issue then.
gitea-mirror commented 2026-05-05 22:04:13 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 26, 2024):

I'm in the process of adding this information to the UI.

I will test how exactly scaling effects things, thank you for catching that.

The slow DNS hasn't caused any problems for me btw, the connection always opens immediately

Thank you!!! Please mention me here or in the release when you've got that fixed, I appreciate it! Thanks for all your work on this tool.

<!-- gh-comment-id:2079669968 --> @MulverineX commented on GitHub (Apr 26, 2024): > I'm in the process of adding this information to the UI. > > I will test how exactly scaling effects things, thank you for catching that. The slow DNS hasn't caused any problems for me btw, the connection always opens immediately Thank you!!! Please mention me here or in the release when you've got that fixed, I appreciate it! Thanks for all your work on this tool.
gitea-mirror commented 2026-05-05 22:04:13 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 29, 2024):

@feschber I think I found the problem, https://stackoverflow.com/a/26097858

Your program does not declare itself to be high dpi aware. And so it is subject to a compatibility mode known as DPI virtualization. The system will supply your program with fake screen dimensions and coordinates, and then scale your program's display to the true dimensions.
...
If you wish to avoid DPI virtualization, and have your program obtain true screen dimensions, then you should mark your program as being high DPI aware. This is best done with the high DPI aware application manifest.

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" 
    xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
  <asmv3:application>
  <asmv3:windowsSettings 
      xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
  </asmv3:application>
</assembly>
<!-- gh-comment-id:2081945573 --> @MulverineX commented on GitHub (Apr 29, 2024): @feschber I think I found the problem, https://stackoverflow.com/a/26097858 > Your program does not declare itself to be high dpi aware. And so it is subject to a compatibility mode known as DPI virtualization. The system will supply your program with fake screen dimensions and coordinates, and then scale your program's display to the true dimensions. > ... > If you wish to avoid DPI virtualization, and have your program obtain true screen dimensions, then you should mark your program as being high DPI aware. This is best done with the high DPI aware application manifest. ```xml <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>true</dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly> ```
gitea-mirror commented 2026-05-05 22:04:14 -06:00
Author
Owner
Copy link

@feschber commented on GitHub (Apr 29, 2024):

Imo it's probably best to not be DPI aware and rather retrieve the actual display resolution via EnumDisplaySettings.
This way I dont have to rely on an application manifest (which currently does not exist)

<!-- gh-comment-id:2081969480 --> @feschber commented on GitHub (Apr 29, 2024): Imo it's probably best to not be DPI aware and rather retrieve the actual display resolution via `EnumDisplaySettings`. This way I dont have to rely on an application manifest (which currently does not exist)
gitea-mirror commented 2026-05-05 22:04:14 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (Apr 29, 2024):

Did some digging, this appears to be the method most are using to add a manifest to their Rust binaries https://github.com/nabijaczleweli/rust-embed-resource

If EnumDisplaySettings works though that'd be fine probably

<!-- gh-comment-id:2081972201 --> @MulverineX commented on GitHub (Apr 29, 2024): Did some digging, this appears to be the method most are using to add a manifest to their Rust binaries https://github.com/nabijaczleweli/rust-embed-resource If `EnumDisplaySettings` works though that'd be fine probably
gitea-mirror commented 2026-05-05 22:04:15 -06:00
Author
Owner
Copy link

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

could you confirm that the latest commit works?

<!-- gh-comment-id:2097007833 --> @feschber commented on GitHub (May 6, 2024): could you confirm that the latest commit works?
gitea-mirror commented 2026-05-05 22:04:15 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (May 6, 2024):

@feschber It works perfectly! Thank you so much! If my situation was reversed though I would still have an issue, because Linux scaling isn't being taken into account either. Luckily, its my right-side monitor

<!-- gh-comment-id:2097033960 --> @MulverineX commented on GitHub (May 6, 2024): @feschber It works perfectly! Thank you so much! If my situation was reversed though I would still have an issue, because Linux scaling isn't being taken into account either. Luckily, its my right-side monitor
gitea-mirror commented 2026-05-05 22:04:16 -06:00
Author
Owner
Copy link

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

@MulverineX are you sure about that? Because the scaling does not have any influence on the window position or size in wayland (layer-shell only wants to know on what edge to display the window).

You can verify the position of the "entry zones" via

export LM_DEBUG_LAYER_SHELL=1
lan-mouse

(assuming you are still using KDE)

<!-- gh-comment-id:2102341922 --> @feschber commented on GitHub (May 9, 2024): @MulverineX are you sure about that? Because the scaling does not have any influence on the window position or size in wayland (layer-shell only wants to know on what edge to display the window). You can verify the position of the "entry zones" via ```sh export LM_DEBUG_LAYER_SHELL=1 lan-mouse ``` (assuming you are still using KDE)
gitea-mirror commented 2026-05-05 22:04:16 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (May 9, 2024):

Will look into this for ya later today

<!-- gh-comment-id:2102863765 --> @MulverineX commented on GitHub (May 9, 2024): Will look into this for ya later today
gitea-mirror commented 2026-05-05 22:04:17 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (May 10, 2024):

finally got around to testing this, its not an issue, everything works as it should :)

<!-- gh-comment-id:2105373212 --> @MulverineX commented on GitHub (May 10, 2024): finally got around to testing this, its not an issue, everything works as it should :)
gitea-mirror commented 2026-05-05 22:04:17 -06:00
Author
Owner
Copy link

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

Thanks for testing, appreciate it!

<!-- gh-comment-id:2105414575 --> @feschber commented on GitHub (May 11, 2024): Thanks for testing, appreciate it!
gitea-mirror commented 2026-05-05 22:04:17 -06:00
Author
Owner
Copy link

@MulverineX commented on GitHub (May 12, 2024):

@feschber edit: #132

<!-- gh-comment-id:2106145913 --> @MulverineX commented on GitHub (May 12, 2024): @feschber edit: #132
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#13
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?